Tilkoblet OpenVPN, men ingenting lastes: en gjennomgang fra klienten

Klientvinduet sier Connected, tunneladressen er der, og nettleseren spinner fortsatt. Den kombinasjonen er normal, fordi et vellykket håndtrykk beviser bare at tunnelen ble bygget; det sier ingenting om serveren vil videresende pakkene dine, skrive om kilden deres eller svare på DNS-spørringene dine. Feilen de fleste gjør, er å åpne serverkonfigurasjonen først. Arbeid deg i stedet utover fra klienten, fordi hvert trinn nedenfor forteller deg om det neste i det hele tatt er verdt å sjekke.

Begynn på klienten og arbeid deg utover

Kjør tre tester i denne rekkefølgen og skriv ned hvor den første feiler. Ping serverens tunneladresse, noe som beviser at tunnelen selv bærer trafikk. Ping en offentlig adresse etter nummer, noe som beviser videresending og oversettelse uten å involvere navneoppslag. Prøv deretter å slå opp et vertsnavn, som er den eneste testen som bruker DNS. Hvert resultat fjerner et helt lag fra mistanken.

Ikke hopp til den tredje testen fordi en nettleser føles raskere. En mislykket sideinnlasting dekker alle tre lagene på én gang, og det er der folk begynner og deretter bygger opp en tunnel som virket på nytt. En side som feiler sier ikke hvilket av de tre lagene som er ødelagt.

To opptak viser hvor pakkene stopper

Mens en ping til en offentlig adresse går fra klienten, ta ett opptak på tunnelegrensesnittet og ett på oppstrømslenken som skal nå internett. Kjør begge samtidig slik at tidsstemplene stemmer.

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

Hvis forespørslene vises på tunnelen og aldri på oppstrømslenken, har serveren droppet dem mellom tunnelen og kabelen, og årsaken er videresending eller brannmurpolicyen for videresending, ikke NAT. Hvis de vises på begge, gjorde serveren sin del, og svaret mangler lenger ute, noe som peker på oversettelse, et filter ovenfor eller en begrensning fra leverandøren.

Hent navnet på oppstrømslenken fra rutetabellen, ikke fra en veiledning. Skybilder og omdøpte adaptere samsvarer sjelden med eksempelgrensesnittet i en guide, og et opptak på feil enhet ser nøyaktig ut som en server som ikke videresender:

ip -4 route get 9.9.9.9

Feltet dev i den utskriften er navnet NAT-regelen trenger senere, så ta vare på det.

Videresending er en kjernebryter og en brannmurpolicy

Kjernen må i det hele tatt samtykke til å videresende. Les gjeldende verdi, og gjør deretter innstillingen varig i stedet for å skrive den bare inn i den kjørende kjernen:

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

Videresending er bare halvparten. På en vert med UFW settes videresendingspolicyen i /etc/default/ufw og må være ACCEPT før en omlasting trer i kraft. Et standard drop på videresendingsveien lar håndtrykket være helt sunt mens det stille forkaster hver pakke som prøver å forlate tunnelen, og det er nøyaktig symptomet du startet med.

Verter som styrer nftables direkte, har det samme spørsmålet i en annen syntaks. Se på tellerne på videresendingskjeden mens en klienttest kjører, fordi en kjede som konsulteres og en kjede som dropper ser like ut i en konfigurasjonsfil.

Navngi det virkelige utgangsgrensesnittet i NAT-regelen

Kildeoversettelse hører hjemme på grensesnittet som faktisk forlater verten, med det utvalget serveren deler ut. Begge halvdelene av den regelen må beskrive virkeligheten, og ingen av dem er valgfri.

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

Den klassiske feilen er en regel kopiert fra en guide som sier -o eth0 på en maskin hvis adapter heter noe annet. Regelen installeres uten advarsel, passer på ingenting, og klienten har fortsatt ikke internett. Utvalget er den andre halvparten av samme feil: hvis serveren deler ut 10.44.0.0/24 og regelen dekker 10.8.0.0/24, vil ingenting noen gang passe.

Se på tellerne i stedet for å stole på regelteksten. Oppføringen rapporterer pakker per regel, og en regel som aldri passerer blir stående på null uansett hvor riktig den ser ut. Gi den et minutts ekte klienttrafikk før du leser noe inn i det tallet:

iptables -t nat -L POSTROUTING -v -n

Null pakketall etter en ekte klienttest betyr at treffet er feil, ikke at tunnelen er ødelagt. Når den passerer, lagre regelsettet slik at det overlever en omstart; en retting som bare lever i skallhistorikken din forsvinner ved første omstart.

Hvis serveren også er en sky-NAT-instans, har plattformen også en stemme. En instans som oversetter adresser trenger vanligvis kilde- og destinasjonskontrollen deaktivert der leverandøren tilbyr den innstillingen, og selve VPN-porten må være tilgjengelig utenfra.

DNS er den andre feilen bak den første

Ping etter adresse som virker mens navn feiler, er et resolverproblem, og det har sin egen årsak. En klient som beholder sin lokale resolver, sender disse spørringene inn i en full tunnel og venter på et svar som aldri kommer, fordi den lokale resolveren nå er på feil side av ruten.

Skyv en resolver fra serveren slik at klienten vet hvor den skal spørre. To oppføringer gir klienten en reserve hvis den første ikke er tilgjengelig, og begge bør være resolvere som tunnelen faktisk tillater.

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

Windows-klienter kan deretter falle tilbake til den lokale resolveren likevel, og det er nettopp det block-outside-dns finnes for å hindre, på bekostning av å miste navn som bare det lokale nettverket kan slå opp. Linux-klienter med systemd-resolved ignorerer ofte en skjøvet resolver med mindre et skript installerer den, så sjekk resolvectl status for tunneleenheten før du konkluderer med at skyvingen ble ignorert.

Avslutt gjennomgangen slik en bruker opplever den. Last en ekte side fra klienten, bekreft adressen den går ut fra, start serveren på nytt, koble til igjen og gjenta de tre testene. Bare den andre runden beviser at de lagrede reglene, brannmurpolicyen og den skjøvede resolveren alle overlevde sammen.