Якія порты 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 незалежна ад вашага фаера. Перш чым зачыніць заяўку, пацвердзіце, што правіла адпавядае порту ў канфігурацыі сервера, што поле пратакола ўсталявана там, дзе сям'я яго патрабуе, і што пункт прызначэння — гэта шлюз, а не любы адрас.