Облачный межсетевой экран против межсетевого экрана хоста для VPN-сервера

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

Начните с края и двигайтесь внутрь

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

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

Прочитайте облачную политику, прежде чем трогать гостя

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

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

Подтвердите слушателя, затем цепочку входа

На инстансе проверьте, что процесс VPN привязан к ожидаемому адресу и порту, например с помощью ss -lntp 'sport = :1194'. Демон, привязанный только к 127.0.0.1, принимает локальных клиентов и ничего через туннель, а снаружи это выглядит точно как отфильтрованный порт.

Затем прочитайте локальные правила в том синтаксисе, который вы бы использовали для их изменения, например iptables -S INPUT или nft list chain inet filter input. Правило, записанное в файл, но так и не загруженное, или отбрасывание по умолчанию без подходящего разрешения тихо отбрасывает пакеты. Для шлюза с перенаправлением проверьте также настройки перенаправления и обратного пути. Именно они решают, что происходит с пакетами, маршрутизируемыми через инстанс, а не адресованными ему.

С состоянием на одном уровне, без состояния на следующем

Группы безопасности помнят разрешённые потоки и впускают ответы обратно. Списки контроля доступа подсетей и многие межсетевые экраны хоста такое состояние не хранят, поэтому правило, покрывающее только исходящее направление, пропускает запрос и отбрасывает ответ. Никогда не переносите допущение об обратном трафике между уровнями, не прочитав правило второго уровня (second layer's rule).

Счётчики решают это быстрее, чем чтение каждого правила в аккаунте. Растущий счётчик означает, что пакет дошёл и был отброшен там, а застывший на нуле — что он туда так и не добрался; iptables -vnL INPUT и nft list ruleset показывают эти числа, когда правила загружены со счётчиками.

Проверяйте новой сессией, а не живой

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

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