Hokker VPN-poarten op in firewall iepenje: protokol foar protokol

Twa aparte regels beslisse oft in VPN-tunnel in firewall oerlibbet: de poarte dy't de klant kiest en it protokol dat de lading draacht. Iepenje allinnich de earste en de tunnel ferifiearret, mar ferpleatst dêrnei gjin gegevens. It minimum is ien TCP-poarte plus GRE foar PPTP, twa UDP-poarten plus ESP foar L2TP/IPsec en IKEv2, en ien poarte foar SSTP, OpenVPN en WireGuard. Rjochting, tastânbewekking en NAT beslisse de rest.

Begjin by de poarte dy't de klant kiest

Elke famylje hat in yngongspunt dat de klant earst kontaktet, en dat yngongspunt is wat jo tastieningsregel neame moat. PPTP-klanten ferbine mei TCP 1723. L2TP/IPsec begjint IKE op UDP 500 en giet oer nei UDP 4500 sadree't NAT-trochgong brûkt wurdt, wylst it L2TP-ram sels op UDP 1701 yn 'e tunnel sit. SSTP wikkelt de sesje yn TLS op TCP 443, IKEv2 ûnderhannelt op UDP 500 en 4500, OpenVPN brûkt standert UDP 1194 mar wurdt faak nei TCP 443 ferpleatst, en WireGuard harket op UDP 51820.

Behannelje dy getallen as standertwearden en net as fêste eigenskippen. In WireGuard-ynterface brûkt eltse harkpoarte dy't syn konfiguraasje oankundiget, en in OpenVPN-tsjinner kin op eltse poarte sitte dy't de behearder keas. Lês de tsjinnerkonfiguraasje foardat jo de regel skriuwe, want in firewall iepene foar 1194 docht neat foar in tsjinner dy't nei 443 ferhuze is.

De tredde kolom is wêr't de measte feroaringskaarten misgeane. De regel bestiet, mar hy wiist nei de ferkearde bestimming, de ferkearde rjochting of it ferkearde ferfier.

GRE en ESP binne protokolnûmers, gjin poarten

GRE en ESP hawwe hielendal gjin poarten, dus in firewallformulier dat allinnich poartenûmers akseptearret kin se net útdrukke. GRE is IP-protokol 47 en ESP is IP-protokol 50, beide wurde besjoen fia it protokolfjild fan 'e IP-kop. In regel skreaun as TCP-poarte 47 past nergens by, en sa liket in PPTP-belied korrekt en dochs lit it elk pakket nei de hânskodding falle.

Ferbrûkersrouters ferbergje dit efter in trochgongfakje dat de protokolregel ynstallearret en, foar GRE, de NAT-helper dy't nedich is om de stream te mappen. Op in echte firewall foegje jo it protokol sels ta: tastean IP-protokol 47 nei de PPTP-tsjinner, tastean IP-protokol 50 nei de IPsec-gateway. Wêr't it platfoarm gjin protokolfjild biedt, is ynkapseling de útwyk, dêrom kin IKEv2 weromfalle op UDP 4500 en dêrom treffe OpenVPN en WireGuard it probleem nea.

Kontrolearje wêr't de regel eins by past foardat jo de klant de skuld jouwe. In pakketteller dy't op 'e gateway op nul bliuwt seit dat de regel nea ôfgie, en gjin hoemannichte weromynstallaasje oan 'e klantkant feroaret dat.

Rjochting, tastân en NAT feroarje it antwurd

In klant dy't nei bûten kiest en in gateway dy't nei binnen harket binne ferskillende easken, en deselde poartelist kin yn 'e iene rjochting goed wêze en yn 'e oare ferkeard. In firewall mei tastân folget de UDP-stream op 500 en 4500 en lit antwurden werom sûnder in twadde regel. ESP en GRE drage gjin poarten, dus in NAT-apparaat hat neat om op te heakjen en hat in helper of in ynkapseling nedich om de sesje te folgjen.

NAT-trochgong is it diel dat fergetten wurdt. IKEv2 begjint op UDP 500, ûntdekt in NAT-apparaat en giet troch op UDP 4500, dus in belied dat allinnich 500 tastiet jout in tunnel dy't him festiget en dan stil wurdt. L2TP/IPsec makket deselde beweging. As jo opname de earste útwikseling sjen lit mar gjin oanhâldend ferkear, sykje dan in regel dy't by 500 ophâldt.

Skriuw de rjochting by elke regel. "Tastean UDP 4500" betsjut neat oant jo sizze fan wêr nei wêr, en in regel dy't goed is foar in omswalkjende klant is meastentiids ferkeard foar in side-oant-side-pear.

Kontrolearje elk paad mei in opname

Rin de opname op 'e gateway, net op 'e klant: in klant registrearret allinnich wat oankaam. Dizze filters dekke de famyljes hjirboppe en litte sjen hokker etappe ûntbrekt:

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

Lês de útfier as in searje. As de ûnderhanneling ferskynt mar it ladingprotokol net, bart it falle earne tusken klant en gateway. As beide ferskine en de side dochs mislearret, is de firewall net langer de fertochte; sjoch nei routing, DNS of de adresgroep dy't de klant kriget.

Op in masine sûnder tcpdump komme deselde bewizen fan ynterface- en regeltellers. Bytes komme yn mar geane net út op 'e tunnelinterface — dat wiist nei it werompaad en net nei de earste tastieningsregel.

Lit in regelset efter dy't jo ferdigenje kinne

SSTP op TCP 443 is foar elk poartebasearre filter net te ûnderskieden fan gewoane HTTPS, en dat is it punt as in netwurk allinnich webferkear tastiet. Dêrom moat de 443-regel de gateway as bestimming neame ynstee fan it hiele ynternet. Wiskje tydlike regels fan alles-nei-alles sa gau't de tunnel wurket. Skriuw op hokker regel past, it protokolnûmer wêr't dat der is, en de rjochting, sadat de folgjende persoan fan bewiis begjint.

Cloud-gateways fan punt-nei-side meitsje de kar sichtber: it downloadde profyl brûkt of SSTP op 443 of IKEv2 op 500 en 4500, en jo moatte allinnich dy iepenje dy't it profyl echt kiest. PPTP is de GRE-útsûndering op in modern netwurk net wurdich, om't mobile operators protokol 47 faak falle litte, hokker firewall jo ek hawwe. Foardat jo de kaart slute, befêstigje dat de regel oerienkomt mei de poarte yn 'e tsjinnerkonfiguraasje, dat it protokolfjild ynsteld is wêr't de famylje it nedich hat, en dat de bestimming de gateway is en net elk adres.