To særskilte regler afgør, om en VPN-tunnel overlever en firewall: den port, klienten ringer til, og den protokol, der bærer nyttelasten. Åbn kun den første, så godkendes tunnelen, og derefter flyttes ingen data. Minimum er én TCP-port plus GRE til PPTP, to UDP-porte plus ESP til L2TP/IPsec og IKEv2, og en enkelt port til SSTP, OpenVPN og WireGuard. Retning, tilstandssporing og NAT afgør resten.

Begynd ved den port, klienten ringer til

Hver familie har et indgangspunkt, som klienten kontakter først, og det indgangspunkt er, hvad din tilladelsesregel skal navngive. PPTP-klienter forbinder til TCP 1723. L2TP/IPsec starter IKE på UDP 500 og skifter til UDP 4500, når NAT-gennemføring er i brug, mens selve L2TP-rammen ligger på UDP 1701 inde i tunnelen. SSTP pakker sessionen ind i TLS på TCP 443, IKEv2 forhandler på UDP 500 og 4500, OpenVPN bruger som standard UDP 1194 men flyttes ofte til TCP 443, og WireGuard lytter på UDP 51820.

FamilyRule to add on the gatewayTypical mistake
WireGuardUDP port from ListenPort, for the peer addressAssuming 51820 when the config says otherwise
OpenVPNThe configured UDP or TCP port, often 443Opening 1194 after the server moved
SSTPTCP 443 limited to the gateway IPAllowing 443 to any destination
IKEv2UDP 500 and UDP 4500, plus ESPAllowing only 500 and losing NAT-T
L2TP/IPsecUDP 500, 4500, ESP, and 1701 inside the tunnelExposing 1701 to the internet
PPTPTCP 1723 and IP protocol 47Writing a rule for TCP 47

Behandl de tal som standardværdier frem for faste egenskaber. Et WireGuard-interface bruger den lytteport, dets konfiguration angiver, og en OpenVPN-server kan sidde på enhver port, administratoren har valgt. Læs serverkonfigurationen, før du skriver reglen, for en firewall åbnet for 1194 gør intet for en server, der er flyttet til 443.

Den tredje kolonne er, hvor de fleste ændringsbillet går galt. Reglen findes, men den peger på det forkerte mål, den forkerte retning eller den forkerte transport.

GRE og ESP er protokolnavne, ikke porte

GRE og ESP har slet ingen porte, så en firewall-formular, der kun accepterer portnumre, kan ikke udtrykke dem. GRE er IP-protokol 47, og ESP er IP-protokol 50, og begge matches via protokolfeltet i IP-headeren. En regel skrevet som TCP-port 47 matcher intet, og det er derfor en PPTP-politik ser korrekt ud og alligevel dropper hver pakke efter håndtrykket.

Forbrugerroutere skjuler dette bag et gennemløbsflueben, der installerer protokolreglen og for GRE den NAT-hjælper, der skal til for at kortlægge flowet. På en rigtig firewall tilføjer du selv protokollen: tillad IP-protokol 47 til PPTP-serveren, tillad IP-protokol 50 til IPsec-gatewayen. Hvor platformen ikke tilbyder et protokolfelt, er indkapsling vejen ud, og derfor kan IKEv2 falde tilbage til UDP 4500, og derfor rammer OpenVPN og WireGuard aldrig problemet.

Kontrollér, hvad reglen faktisk matcher, før du bebrejder klienten. En pakketæller, der bliver på nul på gatewayen, siger, at reglen aldrig blev udløst, og ingen mængde geninstallation på klientsiden ændrer det.

Retning, tilstand og NAT ændrer svaret

En klient, der ringer ud, og en gateway, der lytter ind, er forskellige krav, og den samme portliste kan være rigtig i den ene retning og forkert i den anden. En stateful firewall sporer UDP-flowet på 500 og 4500 og lukker svar tilbage uden en anden regel. ESP og GRE bærer ingen porte, så en NAT-enhed har intet at hægte sig på og har brug for en hjælper eller en indkapsling for at følge sessionen.

NAT-gennemføring er den del, der bliver overset. IKEv2 starter på UDP 500, registrerer en NAT-enhed og fortsætter på UDP 4500, så en politik, der kun tillader 500, giver en tunnel, der etableres og derefter bliver tavs. L2TP/IPsec gør det samme træk. Hvis din optagelse viser den første udveksling men ikke vedvarende trafik, så led efter en regel, der stopper ved 500.

Notér retningen med hver regel. »Tillad UDP 4500« betyder intet, før du siger hvorfra og hvortil, og en regel, der er rigtig for en roamingklient, er normalt forkert for en site-til-site-peer.

Kontrollér hver vej med en optagelse

Kør optagelsen på gatewayen, ikke på klienten: en klient registrerer kun det, der ankom. Disse filtre dækker familierne ovenfor og viser, hvilket trin der mangler:

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 outputtet som en sekvens. Når forhandlingen vises, men nyttelastprotokollen ikke gør, sker tabet et sted mellem klient og gateway. Når begge vises, og siden stadig fejler, er firewallen ikke længere den mistænkte; se på routing, DNS eller den adressepulje, klienten fik.

På en boks uden tcpdump kommer de samme beviser fra interface- og regeltællere. Bytes ind men ikke ud på tunnelinterfacet peger på returvejen frem for på den oprindelige tilladelsesregel.

Efterlad et regelsæt, du kan forsvare

SSTP på TCP 443 kan ikke skelnes fra almindelig HTTPS for noget portbaseret filter, og det er meningen, når et netværk kun tillader webtrafik. Det er også grunden til, at 443-reglen bør navngive gatewayen som mål i stedet for hele internettet. Slet midlertidige regler fra hvad-som-helst-til-hvad-som-helst, så snart tunnelen virker. Skriv ned, hvilken regel der matchede, protokolnummeret hvor der er et, og retningen, så den næste person starter med beviser.

Cloud-gateways af typen punkt-til-site gør valget synligt: den downloadede profil bruger enten SSTP på 443 eller IKEv2 på 500 og 4500, og du bør kun åbne den, profilen faktisk vælger. PPTP er ikke GRE-undtagelsen værd på et moderne netværk, da mobiloperatører ofte dropper protokol 47 uanset din firewall. Før du lukker billetten, skal du bekræfte, at reglen matcher porten i serverkonfigurationen, at protokolfeltet er sat, hvor familien har brug for det, og at målet er gatewayen frem for enhver adresse.

Relaterede artikler