WireGuard-handshake werkt, maar geen internet: volg het pakket

De tunnel staat, wg show meldt een recente handshake, je kunt het tunneladres van de server pingen, en niets daarvoorbij antwoordt. De eerste ingeving is sleutels opnieuw genereren of de configuratie opnieuw delen. Dat verandert precies het deel van het pad dat al bewezen werkt.

Een voltooide handshake zegt dat beide peers het over de sleutels eens zijn, dat UDP het eindpunt bereikt en dat de crypto-routering het pakket accepteert. Het zegt niets over de vraag of het pakket daarna de server kan verlaten.

Volg dus één pakket in plaats van te gissen. Er zijn vier plekken waar het kan sterven, en elk laat een ander spoor achter.

Wat de handshake werkelijk bewijst

WireGuard is een UDP-protocol dat een sessie opzet met een Noise-handshake en daarna pakketten voor een peer versleutelt. Wanneer wg show een handshake van een paar seconden en een stijgende overdrachtsteller toont, zijn het eindpunt, de sleutels en de publieke sleutel van de peer allemaal correct.

Wat het niet bewijst, is dat je client überhaupt internetverkeer de interface in stuurt, dat de server bereid is het door te sturen, of dat een antwoord de weg terug vindt. Dat zijn routerings- en firewallbeslissingen van de kernel, en ze worden buiten de tunnel genomen.

Daarom is pingen naar het tunneladres van de server zo’n misleidende test. Dat pakket is aan de server zelf geadresseerd, dus het eindigt lokaal. Het heeft nooit doorsturen nodig, nooit vertaling en nooit een retourroute van internet.

AllowedIPs is een routeringsbeslissing

Op de client doet AllowedIPs twee taken. Het is de cryptosleutel-routeringstabel die bepaalt welke bestemmingsadressen de tunnel van deze peer in gaan, en het is de lijst met bronadressen die de peer van jou accepteert. Als de clientconfiguratie alleen 10.8.0.0/24 vermeldt, komen publieke bestemmingen nooit in de interface en voert je normale standaardroute ze buiten de tunnel. Dan werkt de tunnel perfect en doet hij niets van wat je wilde.

Kijk naar wat de client daadwerkelijk heeft geïnstalleerd in plaats van wat het configuratiebestand zegt:

wg show wg0 allowed-ips
ip route get 1.1.1.1

Het tweede commando is het beslissende. Als het antwoord je fysieke interface en de gebruikelijke gateway noemt, wordt het pakket niet getunneld en geen enkele wijziging aan de serverkant lost dat op. Voeg 0.0.0.0/0 toe voor IPv4 en ::/0 voor IPv6 apart; een regel die alles voor de ene familie vangt, laat de andere op zijn oorspronkelijke pad, en dat is een veelvoorkomende oorzaak van een werkende IPv4-tunnel en een vastgelopen IPv6-opzoeking.

Waar het pakket sterft op de gateway

Als de route correct is en het pakket gaat nog steeds nergens heen, komt het aan op de server en stopt daar. Vier controles dekken de meeste gateways.

Doorsturen. sysctl net.ipv4.ip_forward die 0 teruggeeft is het klassieke antwoord, en veel distributies staan standaard nog op 0. Het moet 1 zijn, en permanent in een sysctl-bestand worden gezet in plaats van met een commando dat bij een herstart verdwijnt. Doorsturen van IPv6 is een aparte schakelaar.

Het filterbeleid. Een FORWARD-keten met een standaard drop-beleid gooit getunneld verkeer weg terwijl het verkeer naar de host zelf toestaat, wat precies bij het symptoom past. Lees de levende regelset, niet een opgeslagen bestand: nft list ruleset of iptables -S.

Vertaling of routering. Clients met privé-tunneladressen hebben ofwel bron-NAT nodig op de uitgaande interface van de server, ofwel een gerouteerd prefix dat het bovenliggende netwerk terug kan sturen. De keuze daartussen volgt het adresplan. MASQUERADE toevoegen aan een netwerk dat je prefix al terugrouteert is onschadelijk maar zinloos, en het weglaten waar geen route bestaat laat antwoorden geadresseerd aan een niet-routeerbaar privébereik.

De retourweg. In gerouteerde ontwerpen heeft de bovenliggende router een route nodig die naar je server wijst. Het netwerk van de provider kan het ook blokkeren: verschillende clouds zetten een bron- en bestemmingscontrole aan op de instantie, die pakketten stil laat vallen waarvan de bron niet het eigen adres van de instantie is, tot die controle wordt uitgeschakeld.

DNS faalt anders dan routering

Een pakket naar een bekend adres en een naamopzoeking zijn twee verschillende fouten, en de foutmeldingen misleiden in tegengestelde richtingen. Als ping 1.1.1.1 werkt en een browser laadt niets, is de route in orde en de naamresolutie niet. Als de ping zelf faalt, is DNS irrelevant en ben je terug bij de vorige sectie.

wg-quick kan een resolver instellen vanuit de regel DNS = in de configuratie, en systemd-resolved heeft zijn eigen gedrag per link. Een VPN die de resolver overschrijft met een adres dat alleen binnen de tunnel bereikbaar is, laat elke opzoeking mislukken op het moment dat de tunnel wegvalt, wat lijkt alsof de tunnel internet stukmaakt.

Een volgorde die bewijs oplevert

Voer eerst de controle aan de clientkant uit, want het is één commando en het elimineert de helft van de mogelijkheden. Bevestig daarna of de server überhaupt bedoeld is als internetuitgang; een gateway die voor privétoegang is gebouwd, is niet kapot wanneer publieke bestemmingen falen.

Op de server, kijk naar de interface terwijl je een ping vanaf de client stuurt: tcpdump -ni wg0 icmp zou het verzoek moeten tonen, en tcpdump -ni eth0 icmp zou moeten tonen dat het naar buiten gaat, vertaald of niet. Als het op de eerste verschijnt en nooit op de tweede, is de stop lokaal op de server. Als het naar buiten gaat en er komt geen antwoord terug, zit het probleem verderop, en dat is een ander gesprek.

Zorg er ten slotte voor dat de oplossing een herstart overleeft. Doorsturen hoort in een sysctl-bestand, firewallregels horen in de dienst die ze laadt, en clientroutes horen in de configuratie die de interface opzet in plaats van in een shell die je zult vergeten. Verbind opnieuw, herhaal dezelfde twee tests en bevestig dat de tellers bewegen.