Кои портове на 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“ не значи нищо, докато не кажете откъде до къде, а правило, което е правилно за роуминг клиент, обикновено е грешно за партньор сайт-към-сайт.

Проверете всеки път със запис

Пуснете записа на шлюза, не на клиента: клиентът записва само това, което е пристигнало. Тези филтри покриват семействата по-горе и показват кой етап липсва:

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 независимо от вашата защитна стена. Преди да затворите заявката, потвърдете, че правилото съвпада с порта в конфигурацията на сървъра, че полето за протокол е зададено там, където семейството го изисква, и че дестинацията е шлюзът, а не произволен адрес.