Почему результаты сканирования портов меняются за выходом VPN?

Запустите ту же проверку порта с офисной линии и с выхода VPN, и два ответа могут разойтись насчёт адреса, который никто не менял. Этот разрыв идёт от маршрута и от того, какой хост ответил, а не от того, работает ли служба. Три вопроса разделяют эти объяснения: что на самом деле спросила проба, какой хост ответил и что записал ваш собственный сервер. Пройдите их в этом порядке и запишите каждый ответ, прежде чем перейти к следующему.

Почините пробу, прежде чем сравнивать два запуска

Слово состояния можно сравнивать с другим словом состояния только тогда, когда оба вышли из одного эксперимента. Пять полей фиксируют это: адрес источника, который увидела дальняя сторона, разрешённый пункт назначения, порт, тип сканирования и время. Измените любое из них, и вы провели второй эксперимент вместо того, чтобы дважды измерить первый.

Проверьте источник прежде всего остального, потому что клиент VPN может быть запущен, а трафик всё ещё выходит через физический интерфейс. Спросите дальнюю сторону, что она видит, затем спросите ядро, какой интерфейс оно выбрало:

curl -s https://ifconfig.me
ip route get 203.0.113.20

Два адреса в разных сетях означают, что объяснение уже в руках, и остальные проверки лишь подтвердят его. Когда они совпадают, зафиксируйте пробу с включённым флагом причины, чтобы состояние возвращалось привязанным к объяснению, а не стояло одно как голое слово. Тип сканирования тоже относится к этой записи, потому что описывает, что спросили, а не что вернулось. Состояние без источника, без метода и без отметки времени нельзя сравнить ни с чем:

nmap -sT -p 443,8443 --reason 203.0.113.20

Держите этот вывод рядом с записью, а не в буфере прокрутки, который следующий человек не увидит. Два честных сканирования, которые расходятся, — это спор только тогда, когда никто не записал условия. Когда условия зафиксированы, либо результаты совпадают и вопрос закрыт, либо они различаются, и различие является фактом о пути.

Выясните, какой хост завершил рукопожатие

Завершённое рукопожатие доказывает, что его завершил какой-то хост, и этот хост не обязан быть тем процессом, который вы имеете в виду. Балансировщик нагрузки, обратный прокси или SYN-прокси могут ответить раньше, чем участвует настоящий сервер, и это обычная архитектура, а не симптом. Действительный сертификат на ожидаемое имя тоже не сужает это, потому что сертификат описывает отношение службы и ничего не говорит о том, какая машина завершила соединение.

Справочник Nmap по состояниям портов считает это базовым: состояние фиксирует то, что проба могла наблюдать с места отправки, а не свойство порта. Читайте слово состояния так, и два запуска, которые расходились, начинают выглядеть согласованными, а не противоречивыми, тогда как вопрос смещается с того, открыт ли порт, на то, кто стоял перед ним.

Отвечайте на второй вопрос на бэкенде, а не снаружи. Фронтенд, который принимает соединения и затем не достигает своего upstream, даёт ровно внешнюю картину здоровой службы с медленным приложением. Только собственная запись upstream разделяет два случая:

tail -n 5 /var/log/nginx/access.log
ss -ltnp 'sport = :443'

Строка журнала показывает адрес клиента, который приложение действительно увидело, а вторая команда показывает, ваше ли приложение держит порт 443 или что-то перед ним. Если эти двое расходятся насчёт того, какой адрес подключился, вы смотрите на две ноги одного запроса, и в тикете стоит это сказать.

Проверьте свои собственные правила, прежде чем винить туннель

Намеренная политика — самая частая причина, по которой порт отвечает в одной сети и не отвечает в другой, и это наименее интересное доступное объяснение. Правила доступа существуют, чтобы разрешить один источник и отбросить остальные, поэтому смена выхода — именно то событие, для которого их писали. Поэтому другое состояние через VPN не показывает, что провайдер проверяет трафик. Оно показывает, что ваш адрес источника теперь другой, а это гораздо меньшее утверждение.

Эти правила читаются на сервере, поэтому прочитайте их, а не гадайте о середине сети. Перечислите правила фильтрации, в которых упоминается любой из двух диапазонов адресов, затем проверьте, дошло ли соединение до демона вообще:

nft list ruleset | grep -n -e 203.0.113 -e 198.51.100
journalctl -u sshd -n 50 | grep 203.0.113

Пустой второй результат информативен, потому что до демона ничего не дошло и вопрос относится к фильтру, группе безопасности или самому пути. Попадание означает, что служба увидела ваш источник и выбрала свой ответ, и это решение обычно записано в правиле, которое можно прочитать. Ни один результат не поддерживает историю о провайдере, и оба дешевле проверить, чем перехватить пакеты.

Читайте транспорт, сертификат и ответ отдельно

Три слоя дают три наблюдения, и проба, проверяющая одно из них, не может сообщить о двух других. Держите их отдельными строками в записи, а не сворачивайте в один вердикт, потому что каждая строка отказывает по-своему, и режим отказа говорит, куда смотреть дальше.

Одна команда создаёт первые три строки против службы, которой вы управляете. Положите её вывод в запись рядом со сканированием, а не в сообщение чата:

curl -v --resolve office.example:443:203.0.113.20 https://office.example/

Читайте вывод по порядку: рукопожатие отвечает на вопрос транспорта, субъект сертификата — на вопрос имени, а тело ответа — на вопрос приложения. Когда строка рукопожатия успешна, а строка ответа нет, у вас фронтенд со сломанным upstream, а не заблокированный порт. Это другой тикет, чем тот, который вы открыли, и об этом стоит сказать прямо.

Закончите, записав в тикет четыре факта: адрес источника, тип сканирования, хост, который ответил, и время. Всё, что нужно более позднему сравнению, живёт в этих четырёх, и у того, кто возьмёт дело следующим, не будет истории вашего терминала. Если вы не можете заполнить все четыре, запуск не завершён.