VPN подключён, но межсетевой экран всё равно блокирует: как понять, что именно

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

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

Отделите путь от политики

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

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

Прочитайте путь за один проход

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

ip route get 10.20.4.15
ip -brief address show
wg show
sudo ipsec statusall

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

Одна ловушка, свойственная VPN, заслуживает отдельной проверки. В WireGuard AllowedIPs партнёра — это одновременно маршрут и криптографический фильтр: пакет, адрес источника которого не входит в разрешённый набор партнёра, отбрасывается до того, как будет рассмотрено хоть одно правило межсетевого экрана. Поэтому совершенно корректный хостовый межсетевой экран может стоять за тихим отбрасыванием, которое выглядит как политика, и исправление — это строка конфигурации ключа, а не правило.

Прочитайте политику на том уровне, который отвечает

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

ss -ltn | grep ':443'
sudo nft list ruleset
sudo iptables -S INPUT
sudo ufw status verbose

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

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

Прочитайте решение шлюза, когда туннель заканчивается там

На шлюзе «сайт-сайт» или удалённого доступа VPN аутентифицирует пользователя, а политика авторизует ресурс, и это отдельные разрешения. Пользователь, допущенный в туннель, не получает автоматически доступ к каждому внутреннему хосту, и отказ часто приходит от правила пересылки, пока сам туннель в порядке. То же разделение есть в IPsec, где политика безопасности, выбирающая трафик, отличается от фильтра, который его пропускает, и поэтому обе описаны как разные механизмы в RFC 4301.

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

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

Измените самый узкий уровень, затем проверьте

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

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

nc -vz 10.20.4.15 443
curl -v --max-time 5 https://10.20.4.15/

Прежде чем закрыть вопрос:

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

Похожие статьи