Forbundet til OpenVPN, men intet indlæses: en gennemgang fra klienten

Klientvinduet siger Connected, tunneladressen er der, og browseren spinner stadig. Den kombination er normal, fordi et vellykket handshake beviser kun, at tunnelen blev bygget; det siger intet om, hvorvidt serveren vil videresende dine pakker, omskrive deres kilde eller besvare dine DNS-forespørgsler. Den fejl de fleste begår, er at åbne serverkonfigurationen først. Arbejd i stedet udefra klienten, for hvert trin nedenfor fortæller dig, om det næste overhovedet er værd at undersøge.

Begynd på klienten og arbejd udad

Kør tre tests i denne rækkefølge, og skriv ned, hvor den første fejler. Ping serverens tunneladresse, hvilket beviser, at tunnelen selv bærer trafik. Ping en offentlig adresse efter nummer, hvilket beviser videresendelse og oversættelse uden at inddrage navneopløsning. Prøv derefter at opløse et værtsnavn, hvilket er den eneste test, der bruger DNS. Hvert resultat fjerner et helt lag fra mistanke.

Spring ikke til den tredje test, fordi en browser føles hurtigere. En mislykket sideindlæsning dækker alle tre lag på én gang, og det er der, folk begynder og derefter genopbygger en tunnel, der virkede. En side, der fejler, fortæller dig ikke, hvilket af de tre lag der gik i stykker.

To optagelser viser, hvor pakkerne stopper

Mens der kører en ping til en offentlig adresse fra klienten, tag én optagelse på tunnelegrænsefladen og én på uplinket, som skal nå internettet. Kør begge samtidig, så tidsstemplerne passer sammen.

sudo tcpdump -ni tun0 -c 20 icmp
sudo tcpdump -ni enp1s0 -c 20 icmp

Hvis anmodningerne vises på tunnelen og aldrig på uplinket, har serveren droppet dem mellem tunnelen og kablet, og årsagen er videresendelse eller firewallpolitikken for videresendelse, ikke NAT. Hvis de vises på begge, gjorde serveren sin del, og svaret mangler længere ude, hvilket peger på oversættelse, et filter længere oppe eller en begrænsning fra udbyderens side.

Hent uplinkets navn fra routingtabellen, ikke fra en vejledning. Cloudbilleder og omdøbte adaptere matcher sjældent eksempelgrænsefladen i en guide, og en optagelse på den forkerte enhed ligner præcis en server, der ikke videresender:

ip -4 route get 9.9.9.9

Feltet dev i det output er det navn, NAT-reglen får brug for senere, så gem det.

Videresendelse er en kerneomskifter og en firewallpolitik

Kernen skal overhovedet acceptere at videresende. Læs den aktuelle værdi, og gør derefter indstillingen permanent i stedet for kun at skrive den i den kørende kerne:

sysctl net.ipv4.ip_forward
printf 'net.ipv4.ip_forward=1\n' > /etc/sysctl.d/70-vpn-forward.conf
sysctl --system

Videresendelse er kun halvdelen. På en vært med UFW sættes videresendelsespolitikken i /etc/default/ufw og skal være ACCEPT, før en genindlæsning får effekt. Et standard-drop på videresendelsesvejen lader handshaket være helt sundt, mens det lydløst kasserer hver pakke, der prøver at forlade tunnelen, hvilket er præcis det symptom, du startede med.

Værter, der styrer nftables direkte, har det samme spørgsmål i en anden syntaks. Se på tællerne på videresendelseskæden, mens en klienttest kører, for en kæde, der bliver konsulteret, og en kæde, der dropper, ser ens ud i en konfigurationsfil.

Navngiv den rigtige udgangsgrænseflade i NAT-reglen

Kildeoversættelse hører på den grænseflade, der faktisk forlader værten, med det pool, serveren uddeler. Begge halvdele af den regel skal beskrive virkeligheden, og ingen af dem er valgfri.

iptables -t nat -A POSTROUTING -s 10.44.0.0/24 -o enp1s0 -j MASQUERADE

Den klassiske fejl er en regel kopieret fra en guide, der siger -o eth0 på en maskine, hvis adapter hedder noget andet. Reglen installeres uden advarsel, matcher intet, og klienten har stadig intet internet. Poolen er den anden halvdel af samme fejl: hvis serveren uddeler 10.44.0.0/24, og reglen dækker 10.8.0.0/24, vil intet nogensinde matche.

Se på tællerne i stedet for at stole på reglens tekst. Lister viser pakker pr. regel, og en regel, der aldrig matcher, bliver på nul, uanset hvor korrekt den ser ud. Giv den et minut med rigtig klienttrafik, før du læser noget ind i det tal:

iptables -t nat -L POSTROUTING -v -n

Et pakketal på nul efter en rigtig klienttest betyder, at matchningen er forkert, ikke at tunnelen er brudt. Når den matcher, gem regelsættet, så det overlever en genstart; en rettelse, der kun lever i din shell-historik, forsvinder ved første genstart.

Hvis serveren også er en cloud-NAT-instans, har platformen også en stemme. En instans, der oversætter adresser, har normalt brug for deaktiveret kilde- og destinationskontrol, hvor udbyderen tilbyder den indstilling, og selve VPN-porten skal kunne nås udefra.

DNS er den anden fejl bag den første

Ping efter adresse, der virker, mens navne fejler, er et resolverproblem, og det har sin egen årsag. En klient, der beholder sin lokale resolver, sender disse forespørgsler ind i en fuld tunnel og venter på et svar, der aldrig kommer, fordi den lokale resolver nu er på den forkerte side af ruten.

Skub en resolver ud fra serveren, så klienten ved, hvor den skal spørge. To poster giver klienten en fallback, hvis den første ikke kan nås, og begge bør være resolvere, som tunnelen faktisk tillader.

push "dhcp-option DNS 9.9.9.9"
push "dhcp-option DNS 149.112.112.112"

Windowsklienter kan derefter alligevel falde tilbage til den lokale resolver, og det er netop, hvad block-outside-dns findes for at forhindre, på bekostning af at miste navne, som kun det lokale netværk kan opløse. Linuxklienter med systemd-resolved ignorerer ofte en skubbet resolver, medmindre et script installerer den, så tjek resolvectl status for tunneleenheden, før du konkluderer, at skubbet blev ignoreret.

Afslut gennemgangen, som en bruger oplever den. Indlæs en rigtig side fra klienten, bekræft den adresse, den forlader fra, genstart serveren, forbind igen, og gentag de tre tests. Den anden runde er den eneste, der beviser, at de gemte regler, firewallpolitikken og den skubbede resolver alle overlevede sammen.