Лучший способ выполнить это использует три блока сервера: один для перенаправления http к https, один для перенаправления www-имени https к не, и одно для фактического обрабатывания запросов. Причина использования дополнительных блоков сервера вместо IFS состоит в том, что выбор сервера выполняется с помощью хеш-таблицы и очень быстр. Используя уровень сервера, если средства, если выполняется для каждого запроса, который расточителен. Кроме того, получение требуемого uri в переписывании расточительно, поскольку nginx уже имеет эту информацию в переменных $uri и $request_uri (без и со строкой запроса, соответственно).
server {
server_name www.example.com example.com;
return 301 https://example.com$request_uri;
}
server {
listen 443 ssl;
ssl_certificate /path/to/server.cert;
ssl_certificate_key /path/to/server.key;
server_name www.example.com;
return 301 https://example.com$request_uri;
}
server {
listen 443 ssl;
ssl_certificate /path/to/server.cert;
ssl_certificate_key /path/to/server.key;
server_name example.com;
<locations for processing requests>
}
Я понял.
Оказалось, что это просто совпадение, что таблицы не отвечали.
Насколько я вижу, никакая политика IPSec или информация о туннеле не доступна по SNMP, пока туннель не станет активным, так же как и трафик, передаваемый через него. Это объясняет, почему я не получал ответа с OID, о которых я заботился, даже несмотря на то, что я добавлял политики, я просто не активировал туннели.
Спасибо за всю вашу помощь!
Это OID 1.3.6.1.4.1.9.9.171.1.3.3.1.4 (означает cipSecEndPtLocalAddr1) в вашем mib? (/usr/share/snmp/mibs/CISCO-IPSEC-FLOW-MONITOR-MIB.txt на моих серверах)
Как именно он себя ведет? Не могли бы вы вставить свой snmpget с выводом и версией snmpget?