Какие порты VPN открывать в межсетевом экране: протокол за протоколом

Два отдельных правила решают, пройдёт ли VPN-туннель через межсетевой экран: порт, на который звонит клиент, и протокол, который несёт полезную нагрузку. Откройте только первое, и туннель пройдёт аутентификацию, но после этого данные не пойдут. Минимум — один порт TCP и GRE для PPTP, два порта UDP и ESP для L2TP/IPsec и IKEv2, и один порт для SSTP, OpenVPN и WireGuard. Направление, отслеживание состояния и NAT решают остальное.

Начните с порта, на который звонит клиент

У каждого семейства есть точка входа, к которой клиент обращается первой, и именно эту точку входа должно называть ваше правило разрешения. Клиенты PPTP подключаются к TCP 1723. L2TP/IPsec начинает IKE на UDP 500 и переходит на UDP 4500, когда используется обход NAT, а сам кадр L2TP находится на UDP 1701 внутри туннеля. SSTP заворачивает сеанс в TLS на TCP 443, IKEv2 договаривается на UDP 500 и 4500, OpenVPN по умолчанию использует UDP 1194, но часто переносится на TCP 443, а WireGuard слушает на UDP 51820.

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

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

GRE и ESP — это номера протоколов, а не порты

У GRE и ESP вообще нет портов, поэтому форма экрана, которая принимает только номера портов, не может их выразить. GRE — это протокол IP 47, а ESP — протокол IP 50, оба сопоставляются по полю протокола в заголовке IP. Правило, записанное как порт TCP 47, ни с чем не совпадает, и именно так политика PPTP выглядит правильной и всё равно отбрасывает каждый пакет после рукопожатия.

Домашние маршрутизаторы прячут это за флажком пропуска, который устанавливает правило протокола и, для GRE, помощник NAT, нужный для сопоставления потока. На настоящем экране протокол добавляете вы сами: разрешите протокол IP 47 к серверу PPTP, разрешите протокол IP 50 к шлюзу IPsec. Там, где платформа не предлагает поля протокола, выход — инкапсуляция, поэтому IKEv2 может откатиться на UDP 4500 и поэтому OpenVPN и WireGuard никогда не сталкиваются с этой проблемой.

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

Направление, состояние и NAT меняют ответ

Клиент, звонящий наружу, и шлюз, слушающий внутрь, — это разные требования, и один и тот же список портов может быть верным в одном направлении и неверным в другом. Экран с отслеживанием состояния следит за потоком UDP на 500 и 4500 и пропускает ответы обратно без второго правила. ESP и GRE не несут портов, поэтому устройству NAT не за что зацепиться, и ему нужен помощник или инкапсуляция, чтобы следить за сеансом.

Обход NAT — это та часть, которую пропускают. IKEv2 начинается на UDP 500, обнаруживает устройство NAT и продолжается на UDP 4500, поэтому политика, разрешающая только 500, даёт туннель, который устанавливается и затем замолкает. L2TP/IPsec делает то же движение. Если ваша запись показывает первый обмен, но не постоянный трафик, ищите правило, которое останавливается на 500.

Записывайте направление с каждым правилом. «Разрешить UDP 4500» ничего не значит, пока вы не скажете откуда и куда, а правило, верное для roaming-клиента, обычно неверно для партнёра «площадка — площадка».

Проверьте каждый путь записью

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

sudo tcpdump -ni any tcp port 1723
sudo tcpdump -ni any udp port 500 or udp port 4500
sudo tcpdump -ni any proto gre
sudo tcpdump -ni any proto 50

Читайте вывод как последовательность. Когда согласование появляется, а протокол полезной нагрузки нет, отбрасывание происходит где-то между клиентом и шлюзом. Когда появляются оба, а страница всё равно не открывается, экран больше не подозреваемый; смотрите маршрутизацию, DNS или пул адресов, выданный клиенту.

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

Оставьте набор правил, который сможете защитить

SSTP на TCP 443 неотличим от обычного HTTPS для любого фильтра по портам, и в этом весь смысл, когда сеть разрешает только веб-трафик. Поэтому правило для 443 должно называть шлюз назначением, а не весь интернет. Удаляйте временные правила «что угодно куда угодно», как только туннель заработает. Запишите, какое правило сработало, номер протокола там, где он есть, и направление, чтобы следующий человек начал с доказательств.

Облачные шлюзы «точка — площадка» делают выбор видимым: загруженный профиль использует либо SSTP на 443, либо IKEv2 на 500 и 4500, и открывать нужно только то, что профиль действительно выбирает. PPTP не стоит исключения для GRE в современной сети, поскольку мобильные операторы часто отбрасывают протокол 47 независимо от вашего экрана. Перед закрытием заявки подтвердите, что правило совпадает с портом в конфигурации сервера, что поле протокола задано там, где оно нужно семейству, и что назначение — шлюз, а не любой адрес.