Verbonden met OpenVPN maar er laadt niets: een wandeling vanaf de client

Het venster van de client zegt Connected, het tunneladres is er, en de browser draait nog steeds. Die combinatie is normaal, want een geslaagde handshake bewijst alleen dat de tunnel is opgebouwd; hij zegt niets over of de server je pakketten doorstuurt, hun bron herschrijft of je DNS-query's beantwoordt. De fout die de meeste mensen maken is eerst de serverconfiguratie openen. Werk in plaats daarvan van de client naar buiten, want elke stap hieronder vertelt je of de volgende überhaupt de moeite van het controleren waard is.

Begin bij de client en werk naar buiten

Voer drie tests in deze volgorde uit en schrijf op waar de eerste faalt. Ping het tunneladres van de server, wat bewijst dat de tunnel zelf verkeer draagt. Ping een openbaar adres op nummer, wat doorsturen en vertaling bewijst zonder naamresolutie erbij te betrekken. Probeer daarna een hostnaam op te lossen, de enige test die DNS gebruikt. Elk resultaat haalt een hele laag uit het vermoeden.

Sla de derde test niet over omdat een browser sneller voelt. Een mislukte paginalading dekt alle drie de lagen tegelijk af, en daar beginnen mensen en bouwen ze vervolgens een werkende tunnel opnieuw. Een pagina die faalt vertelt je niet welke van de drie is gebroken.

Twee opnamen laten zien waar de pakketten stoppen

Terwijl er vanaf de client een ping naar een openbaar adres loopt, maak je één opname op de tunnelinterface en één op de uplink die het internet zou moeten bereiken. Laat beide tegelijk lopen zodat de tijdstempels kloppen.

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

Als de verzoeken op de tunnel verschijnen en nooit op de uplink, heeft de server ze tussen de tunnel en de kabel laten vallen, en de oorzaak is doorsturen of het doorstuurbeleid van de firewall, niet NAT. Als ze op beide verschijnen, heeft de server zijn deel gedaan en ontbreekt het antwoord verder naar buiten, wat wijst op vertaling, een filter hogerop of een beperking van de provider.

Haal de naam van de uplink uit de routingtabel, niet uit een tutorial. Cloudimages en hernoemde adapters komen zelden overeen met de voorbeeldinterface in een gids, en een opname op het verkeerde apparaat ziet er precies uit als een server die niet doorstuurt:

ip -4 route get 9.9.9.9

Het veld dev in die uitvoer is de naam die de NAT-regel later nodig heeft, dus bewaar die.

Doorsturen is een kernschakelaar en een firewallbeleid

De kernel moet überhaupt instemmen met doorsturen. Lees de huidige waarde en maak de instelling daarna permanent in plaats van hem alleen in de draaiende kernel te schrijven:

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

Doorsturen is maar de helft. Op een host met UFW wordt het doorstuurbeleid in /etc/default/ufw gezet en moet het ACCEPT zijn voordat een herlaadbeurt effect heeft. Een standaard drop op het doorstuurpad laat de handshake volledig gezond terwijl elk pakket dat via de tunnel naar buiten wil stilzwijgend wordt weggegooid, en dat is precies het symptoom waarmee je begon.

Hosts die nftables rechtstreeks beheren hebben dezelfde vraag in een andere syntax. Kijk naar de tellers op de doorstuurketen terwijl een clienttest loopt, want een keten die wordt geraadpleegd en een keten die dropt zien er in een configuratiebestand hetzelfde uit.

Noem de echte uitgaande interface in de NAT-regel

Brontranslatie hoort op de interface die de host daadwerkelijk verlaat, met de pool die de server uitgeeft. Beide helften van die regel moeten de werkelijkheid beschrijven, en geen van beide is optioneel.

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

De klassieke fout is een regel die uit een gids is gekopieerd en -o eth0 zegt op een machine waarvan de adapter anders heet. De regel wordt zonder waarschuwing geïnstalleerd, matcht niets, en de client heeft nog steeds geen internet. De pool is de andere helft van dezelfde fout: als de server 10.44.0.0/24 uitgeeft en de regel 10.8.0.0/24 dekt, zal niets ooit matchen.

Kijk naar de tellers in plaats van de regeltekst te vertrouwen. De lijst meldt pakketten per regel, en een regel die nooit matcht blijft op nul staan hoe correct hij er ook uitziet. Geef hem een minuut echte clientverkeer voordat je iets in dat getal leest:

iptables -t nat -L POSTROUTING -v -n

Een pakketteller van nul na een echte clienttest betekent dat de match verkeerd is, niet dat de tunnel kapot is. Zodra hij matcht, sla de regelset op zodat die een herstart overleeft; een oplossing die alleen in je shellgeschiedenis leeft, verdwijnt bij de eerste herstart.

Als de server ook een cloud-NAT-instantie is, heeft het platform ook een stem. Een instantie die adressen vertaalt, heeft meestal de bron- en bestemmingscontrole uitgeschakeld nodig waar de provider die instelling biedt, en de VPN-poort zelf moet van buitenaf bereikbaar zijn.

DNS is de tweede fout achter de eerste

Ping op adres dat werkt terwijl namen falen is een resolverprobleem, en het heeft zijn eigen oorzaak. Een client die zijn lokale resolver houdt, stuurt die query's een volledige tunnel in en wacht op een antwoord dat nooit komt, omdat de lokale resolver nu aan de verkeerde kant van de route zit.

Stuur een resolver vanaf de server zodat de client weet waar hij moet vragen. Twee vermeldingen geven de client een terugval als de eerste niet bereikbaar is, en beide zouden resolvers moeten zijn die de tunnel echt toestaat.

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

Windows-clients kunnen daarna alsnog terugvallen op de lokale resolver, en dat is precies wat block-outside-dns bestaat om te voorkomen, ten koste van namen die alleen het lokale netwerk kan oplossen. Linux-clients met systemd-resolved negeren een gestuurde resolver vaak tenzij een script hem installeert, dus controleer resolvectl status voor het tunnelapparaat voordat je concludeert dat het sturen is genegeerd.

Rond de wandeling af zoals een gebruiker hem ervaart. Laad een echte pagina vanaf de client, bevestig het adres waar hij uit vertrekt, herstart de server, verbind opnieuw en herhaal de drie tests. Alleen die tweede ronde bewijst dat de opgeslagen regels, het firewallbeleid en de gestuurde resolver allemaal samen hebben overleefd.