Tilkopla OpenVPN, men ingenting lastar: ein gjennomgang frå klienten

Klientvindauget seier Connected, tunneladressa er der, og nettlesaren snurrar framleis. Den kombinasjonen er normal, fordi eit vellukka handtrykk beviser berre at tunnelen vart bygd; det seier ingenting om serveren vil vidaresenda pakkane dine, skrive om kjelda deira eller svare på DNS-spørjingane dine. Feilen dei fleste gjer, er å opne serverkonfigurasjonen fyrst. Arbeid deg i staden utover frå klienten, fordi kvart steg nedanfor fortel deg om det neste i det heile er verdt å sjekke.

Byrj på klienten og arbeid deg utover

Køyr tre testar i denne rekkjefølgja og skriv ned kvar den fyrste feilar. Ping tunneladressa til serveren, noko som beviser at tunnelen sjølv ber trafikk. Ping ei offentleg adresse etter nummer, noko som beviser vidaresending og omsetjing utan å blande inn namneoppslag. Prøv deretter å slå opp eit vertsnamn, som er den einaste testen som brukar DNS. Kvart resultat fjernar eit heilt lag frå mistanken.

Ikkje hopp til den tredje testen fordi ein nettlesar kjennest raskare. Ei mislukka sideinnlasting dekkjer alle tre laga på ein gong, og det er der folk byrjar og deretter byggjer opp att ein tunnel som verka. Ei side som feilar seier ikkje kva av dei tre laga som er øydelagt.

To opptak viser kvar pakkane stoppar

Medan ein ping til ei offentleg adresse går frå klienten, ta eitt opptak på tunnelegrensesnittet og eitt på oppstraumslenkja som skal nå internett. Køyr begge samtidig slik at tidsstempla stemmer.

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

Viss førespurnadene viser seg på tunnelen og aldri på oppstraumslenkja, har serveren sleppt dei mellom tunnelen og kabelen, og årsaka er vidaresending eller brannmurpolitikken for vidaresending, ikkje NAT. Viss dei viser seg på begge, gjorde serveren sin del, og svaret manglar lenger ute, noko som peikar på omsetjing, eit filter ovanfor eller ei avgrensing frå leverandøren.

Hent namnet på oppstraumslenkja frå rutetabellen, ikkje frå ein rettleiar. Skybilete og omdøypte adapterar samsvarar sjeldan med dømeegrensesnittet i ein guide, og eit opptak på feil eining ser nøyaktig ut som ein server som ikkje vidaresender:

ip -4 route get 9.9.9.9

Feltet dev i den utskrifta er namnet NAT-regelen treng seinare, så ta vare på det.

Vidaresending er ein kjernebrytar og ein brannmurpolitikk

Kjernen må i det heile samtykkje til å vidaresenda. Les gjeldande verdi, og gjer deretter innstillinga varig i staden for å skrive ho berre inn i den køyrande kjernen:

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

Vidaresending er berre halvparten. På ein vert med UFW vert vidaresendingspolitikken sett i /etc/default/ufw og må vere ACCEPT før ei omlasting tek til å gjelde. Eit standard drop på vidaresendingsvegen lèt handtrykket vere heilt sunt medan det stille kastar kvar pakke som prøver å forlate tunnelen, og det er nøyaktig symptomet du starta med.

Vertar som styrer nftables direkte, har det same spørsmålet i ein annan syntaks. Sjå på teljarane på vidaresendingskjeda medan ein klienttest køyrer, fordi ei kjede som vert konsultert og ei kjede som droppar ser like ut i ei konfigurasjonsfil.

Namngje det verkelege utgangsgrensesnittet i NAT-regelen

Kjeldomsætjing høyrer heime på grensesnittet som faktisk forlèt verten, med det utvalet serveren deler ut. Båe halvdelane av den regelen må skildre røynda, og ingen av dei er valfri.

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

Den klassiske feilen er ein regel kopiert frå ein guide som seier -o eth0 på ein maskin der adapteren heiter noko anna. Regelen vert installert utan åtvaring, passar på ingenting, og klienten har framleis ikkje internett. Utvalet er den andre halvparten av same feil: viss serveren deler ut 10.44.0.0/24 og regelen dekkjer 10.8.0.0/24, vil ingenting nokon gong passe.

Sjå på teljarane i staden for å stole på regelteksten. Oppføringa rapporterer pakkar per regel, og ein regel som aldri passar vert ståande på null uansett kor riktig han ser ut. Gje han eitt minutt ekte klienttrafikk før du les noko inn i det talet:

iptables -t nat -L POSTROUTING -v -n

Null pakketal etter ein ekte klienttest tyder på at treffet er feil, ikkje at tunnelen er øydelagd. Når han passar, lagre regelsettet slik at det overlever ein omstart; ei retting som berre lever i skallhistorikken din, forsvinn ved fyrste omstart.

Viss serveren òg er ein sky-NAT-instans, har plattforma òg ei stemme. Ein instans som omset adresser treng vanlegvis kjelde- og målkontrollen deaktivert der leverandøren tilbyr den innstillinga, og sjølve VPN-porten må vere tilgjengeleg utanfrå.

DNS er den andre feilen bak den fyrste

Ping etter adresse som verkar medan namn feilar, er eit resolverproblem, og det har si eiga årsak. Ein klient som held på sin lokale resolver, sender desse spørjingane inn i ein full tunnel og ventar på eit svar som aldri kjem, fordi den lokale resolveren no er på feil side av ruta.

Skyv ein resolver frå serveren slik at klienten veit kvar han skal spørje. To oppføringar gjev klienten ein reserve viss den fyrste ikkje er tilgjengeleg, og båe bør vere resolverar som tunnelen faktisk tillèt.

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

Windows-klientar kan deretter falle tilbake til den lokale resolveren likevel, og det er nettopp det block-outside-dns finst for å hindre, på kostnad av å miste namn som berre det lokale nettet kan slå opp. Linux-klientar med systemd-resolved ignorerer ofte ein skyvd resolver med mindre eit skript installerer han, så sjekk resolvectl status for tunneleininga før du konkluderer med at skyvinga vart ignorert.

Avslutt gjennomgangen slik ein brukar opplever han. Last ei ekte side frå klienten, stadfest adressa ho går ut frå, start serveren på nytt, kople til att og gjenta dei tre testane. Berre den andre runden beviser at dei lagra reglane, brannmurpolitikken og den skyvde resolveren alle overlevde saman.