Watter VPN-poorte om op 'n firewall oop te maak: protokol vir protokol

Twee afsonderlike reëls bepaal of 'n VPN-tonnel deur 'n firewall kom: die poort wat die kliënt skakel, en die protokol wat die vrag dra. Maak net die eerste oop, dan verifieer die tonnel en stuur daarna geen data nie. Die minimum is een TCP-poort plus GRE vir PPTP, twee UDP-poorte plus ESP vir L2TP/IPsec en IKEv2, en 'n enkele poort vir SSTP, OpenVPN en WireGuard. Rigting, toestandopsporing en NAT bepaal die res.

Begin by die poort wat die kliënt skakel

Elke familie het 'n ingangspunt wat die kliënt eerste kontak, en daardie ingangspunt is wat jou toelaatreël moet noem. PPTP-kliënte verbind na TCP 1723. L2TP/IPsec begin IKE op UDP 500 en skuif na UDP 4500 sodra NAT-traversal in gebruik is, met die L2TP-raam self op UDP 1701 binne die tonnel. SSTP draai die sessie in TLS op TCP 443 toe, IKEv2 onderhandel op UDP 500 en 4500, OpenVPN verstek na UDP 1194 maar word dikwels na TCP 443 geskuif, en WireGuard luister op UDP 51820.

Behandel daardie getalle as verstekwaardes eerder as vaste eienskappe. 'n WireGuard-koppelvlak gebruik enige luisterpoort wat sy konfigurasie verklaar, en 'n OpenVPN-bediener kan op enige poort sit wat die administrateur gekies het. Lees die bedienerkonfigurasie voordat jy die reël skryf, want 'n firewall wat vir 1194 oopgemaak is, doen niks vir 'n bediener wat na 443 geskuif is nie.

Die derde kolom is waar die meeste veranderingstickets verkeerd gaan. Die reël bestaan, maar dit wys na die verkeerde bestemming, die verkeerde rigting of die verkeerde vervoer.

GRE en ESP is protokolnummers, nie poorte nie

GRE en ESP het glad geen poorte nie, so 'n firewallvorm wat net poortnommers aanvaar, kan hulle nie uitdruk nie. GRE is IP-protokol 47 en ESP is IP-protokol 50, albei deur die protokolveld van die IP-kop geëien. 'n Reël wat as TCP-poort 47 geskryf is, pas niks, en dit is hoe 'n PPTP-beleid korrek lyk en tog elke pakket ná die handdruk laat val.

Verbruikersroeteerders verberg dit agter 'n deurlaat-blokkiesmerk wat die protokolreël installeer en, vir GRE, die NAT-hulpmiddel wat nodig is om die vloei te karteer. Op 'n regte firewall voeg jy die protokol self by: laat IP-protokol 47 na die PPTP-bediener toe, laat IP-protokol 50 na die IPsec-grendel toe. Waar die platform geen protokolveld bied nie, is inkapseling die uitweg, en dit is waarom IKEv2 na UDP 4500 kan terugval en waarom OpenVPN en WireGuard nooit die probleem tref nie.

Kyk wat die reël werklik pas voordat jy die kliënt blameer. 'n Pakketteller wat op die grendel op nul bly, sê die reël het nooit gevuur nie, en geen hoeveelheid herinstallasie aan die kliëntkant verander dit nie.

Rigting, toestand en NAT verander die antwoord

'n Kliënt wat uit skakel en 'n grendel wat inkomend luister, is verskillende vereistes, en dieselfde poortlys kan in die een rigting reg en in die ander verkeerd wees. 'n Toestandvolle firewall volg die UDP-vloei op 500 en 4500 en laat antwoorde terug sonder 'n tweede reël. ESP en GRE dra geen poorte nie, so 'n NAT-toestel het niks om op te sleutel nie en het 'n hulpmiddel of 'n inkapseling nodig om die sessie te volg.

NAT-traversal is die deel wat gemis word. IKEv2 begin op UDP 500, bespeur 'n NAT-toestel en gaan voort op UDP 4500, so 'n beleid wat net 500 toelaat, gee 'n tonnel wat vestig en dan stil word. L2TP/IPsec maak dieselfde skuif. As jou opname die eerste uitruiling wys maar geen volgehoue verkeer nie, soek 'n reël wat by 500 stop.

Teken die rigting by elke reël aan. "Laat UDP 4500 toe" beteken niks tot jy sê van waar na waar nie, en 'n reël wat reg is vir 'n swerwende kliënt, is gewoonlik verkeerd vir 'n werf-tot-werf-eweknie.

Kontroleer elke pad met 'n opname

Voer die opname op die grendel uit, nie op die kliënt nie: 'n kliënt teken net op wat aangekom het. Hierdie filters dek die families hierbo en wys watter stadium ontbreek:

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

Lees die uitset as 'n reeks. Wanneer onderhandeling opduik maar die vragprotokol nie, gebeur die val iewers tussen kliënt en grendel. Wanneer albei verskyn en die bladsy steeds misluk, is die firewall nie meer die verdagte nie; kyk na roetering, DNS of die adrespoel wat aan die kliënt gegee is.

Op 'n boks sonder tcpdump kom dieselfde bewyse van koppelvlak- en reëltellers. Grepe in maar nie uit op die tonnelkoppelvlak wys na die terugpad eerder as na die aanvanklike toelaatreël.

Laat 'n reëlstel wat jy kan verdedig

SSTP op TCP 443 is vir enige poortgebaseerde filter nie van gewone HTTPS te onderskei nie, en dit is die punt wanneer 'n netwerk net webverkeer toelaat. Dit is ook waarom die 443-reël die grendel as bestemming moet noem eerder as die hele internet. Vee tydelike enige-na-enige reëls uit sodra die tonnel werk. Skryf neer watter reël gepas het, die protokolnummer waar daar een is, en die rigting, sodat die volgende persoon van bewyse begin.

Wolk-punt-tot-werf-grendels maak die keuse sigbaar: die afgelaaide profiel gebruik óf SSTP op 443 óf IKEv2 op 500 en 4500, en jy moet net die een oopmaak wat die profiel werklik kies. PPTP is nie die GRE-uitsondering op 'n moderne netwerk werd nie, want selfoonoperateurs laat protokol 47 dikwels val ongeag jou firewall. Voordat jy die ticket sluit, bevestig dat die reël by die poort in die bedienerkonfigurasie pas, dat die protokolveld gestel is waar die familie een nodig het, en dat die bestemming die grendel is eerder as enige adres.