Ansluten till OpenVPN men inget laddas: en genomgång från klienten

Klientfönstret säger Connected, tunneladressen finns, och webbläsaren snurrar fortfarande. Den kombinationen är normal, eftersom ett lyckat handskakning bevisar bara att tunneln byggdes; det säger inget om servern kommer att vidarebefordra dina paket, skriva om deras källa eller svara på dina DNS-frågor. Misstaget de flesta gör är att öppna serverns konfiguration först. Arbeta i stället utåt från klienten, eftersom varje steg nedan säger om nästa ens är värt att kontrollera.

Börja på klienten och arbeta utåt

Kör tre tester i den här ordningen och skriv ned var det första fallerar. Pinga serverns tunneladress, vilket bevisar att tunneln själv bär trafik. Pinga en offentlig adress med nummer, vilket bevisar vidarebefordran och översättning utan att blanda in namnuppslagning. Försök sedan lösa upp ett värdnamn, vilket är det enda testet som använder DNS. Varje resultat tar bort ett helt lager från misstankarna.

Hoppa inte till det tredje testet för att webbläsaren känns snabbare. En misslyckad sidladdning täcker alla tre lagren på en gång, och det är där folk börjar och sedan bygger om en tunnel som fungerade. En sida som misslyckas säger inte vilket av de tre lagren som gick sönder.

Två avlyssningar visar var paketen stannar

Medan en ping till en offentlig adress körs från klienten, ta en avlyssning på tunnelgränssnittet och en på upplänken som ska nå internet. Kör båda samtidigt så att tidsstämplarna stämmer.

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

Om förfrågningarna syns på tunneln och aldrig på upplänken har servern släppt dem mellan tunneln och kabeln, och orsaken är vidarebefordran eller brandväggspolicyn för vidarebefordran, inte NAT. Om de syns på båda gjorde servern sin del, och svaret saknas längre ut, vilket pekar på översättning, ett filter högre upp eller en begränsning från leverantören.

Hämta upplänkens namn från routingtabellen, inte från en guide. Molnbilder och omdöpta adaptrar matchar sällan exempelgränssnittet i en handledning, och en avlyssning på fel enhet ser exakt ut som en server som inte vidarebefordrar:

ip -4 route get 9.9.9.9

Fältet dev i den utskriften är namnet som NAT-regeln behöver senare, så behåll det.

Vidarebefordran är en kärnomkopplare och en brandväggspolicy

Kärnan måste överhuvudtaget samtycka till att vidarebefordra. Läs det aktuella värdet och gör sedan inställningen beständig i stället för att bara skriva den i den körande kärnan:

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

Vidarebefordran är bara halva. På en värd med UFW sätts vidarebefordringspolicyn i /etc/default/ufw och måste vara ACCEPT innan en omladdning får effekt. Ett standard-drop på vidarebefordringsvägen lämnar handskakningen helt frisk men kastar tyst varje paket som försöker lämna tunneln, och det är precis det symtom du började med.

Värdar som hanterar nftables direkt har samma fråga i en annan syntax. Titta på räknarna på vidarebefordringskedjan medan ett klienttest körs, eftersom en kedja som konsulteras och en kedja som droppar ser likadana ut i en konfigurationsfil.

Namnge det verkliga utgångsgränssnittet i NAT-regeln

Källöversättning hör hemma på gränssnittet som faktiskt lämnar värden, med den pool som servern delar ut. Båda halvorna av den regeln måste beskriva verkligheten, och ingen av dem är valfri.

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

Det klassiska felet är en regel kopierad från en guide som säger -o eth0 på en maskin vars adapter heter något annat. Regeln installeras utan varning, matchar ingenting, och klienten har fortfarande inget internet. Poolen är den andra halvan av samma misstag: om servern delar ut 10.44.0.0/24 och regeln täcker 10.8.0.0/24 kommer ingenting någonsin att matcha.

Titta på räknarna i stället för att lita på regeltexten. Listningen rapporterar paket per regel, och en regel som aldrig matchar stannar på noll hur korrekt den än ser ut. Ge den en minut riktig klienttrafik innan du läser något i den siffran:

iptables -t nat -L POSTROUTING -v -n

Noll paket efter ett riktigt klienttest betyder att matchningen är fel, inte att tunneln är trasig. När den matchar, spara regeluppsättningen så att den överlever en omstart; en rättelse som bara lever i ditt skalshistorik försvinner vid första omstarten.

Om servern också är en moln-NAT-instans har plattformen också ett ord. En instans som översätter adresser behöver vanligtvis käll- och målkontrollen avstängd där leverantören erbjuder den inställningen, och själva VPN-porten måste vara nåbar utifrån.

DNS är det andra felet bakom det första

Ping på adress som fungerar medan namn misslyckas är ett resolverproblem, och det har sin egen orsak. En klient som behåller sin lokala resolver skickar de frågorna in i en full tunnel och väntar på ett svar som aldrig kommer, eftersom den lokala resolvern nu är på fel sida av rutten.

Skjut en resolver från servern så att klienten vet var den ska fråga. Två poster ger klienten en reserv om den första inte går att nå, och båda bör vara resolvrar som tunneln faktiskt tillåter.

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

Windows-klienter kan sedan ändå falla tillbaka på den lokala resolvern, och det är precis vad block-outside-dns finns för att förhindra, till priset av att namn som bara det lokala nätet kan lösa går förlorade. Linux-klienter med systemd-resolved ignorerar ofta en påskjuten resolver om inte ett skript installerar den, så kontrollera resolvectl status för tunnelenheten innan du drar slutsatsen att påskjutningen ignorerades.

Avsluta genomgången som en användare upplever den. Ladda en riktig sida från klienten, bekräfta adressen den går ut ifrån, starta om servern, anslut igen och upprepa de tre testerna. Bara den andra omgången bevisar att de sparade reglerna, brandväggspolicyn och den påskjutna resolvern alla överlevde tillsammans.