Добавили адрес VPN в белый список, а блокировка осталась? Проследите его

Добавление в белый список адреса, который показывает приложение VPN, редко исправляет заблокированный порт, и пакет объясняет почему. Межсетевой экран не игнорирует ваше правило; он оценивает адрес источника, который ничто на экране клиента не показывает. Пока назначение не сообщит это значение, любое изменение правила — догадка.

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

Адрес в приложении — не тот, что приходит

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

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

Проследите один запрос до границы фильтрации

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

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

iptables -vnL INPUT --line-numbers
iptables -S INPUT | head -n 40
ss -ltnp | grep -E ':(443|9443)\b'

Укажите в заявке номер соответствующего правила. Без него следующий читатель не поймёт, какое изменение повлияло на результат. Номер правила без отметки времени всё ещё неоднозначен.

Проверьте путь одной ограниченной записью

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

tcpdump -ni any 'tcp dst port 9443' -c 20

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

Читайте порядок цепочки, а не только правило

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

Удаление правила, чтобы посмотреть, что произойдёт, — это изменение, а не наблюдение. Прочитайте счётчики, запишите номер правила и сохраните исходную политику в журнале изменений. Если тест неизбежен, выполните его на копии цепочки.

Измените правило, которым управляет его владелец

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

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