WireGuard-handshake werkt, maar het kantoorsubnet antwoordt niet

De handshake rondt af, wg show meldt recente overdracht, en het tunneladres van de server antwoordt op een ping. Een host op het LAN van de server niet. Drie voorwaarden moeten tegelijk gelden: de client moet het LAN-prefix in de tunnel routeren, de server moet de pakketten doorsturen, en het antwoord heeft een weg terug nodig. Ontbreekt een van de drie, dan is het symptoom identiek.

AllowedIPs is zowel een toegangslijst als een routingtabel

Op de client bepaalt de lijst AllowedIPs zowel wat naar die peer mag worden gestuurd als welke routes WireGuard installeert. Een peer-item dat alleen het tunneladres van de server noemt, installeert één hostroute, zodat LAN-bestemmingen nooit in de tunnel komen. Het LAN-prefix toevoegen is het eerste dat je moet controleren, en het is ook de wijziging die na een gekopieerde configuratie het vaakst ontbreekt. Een peer die is verbreed naar een standaardroute is een ander ontwerp, en die verplaatst ook het internetverkeer van de client.

Houd de hostroute en het LAN-prefix als afzonderlijke items. Heeft het kantoor twee subnetten, dan horen beide in de lijst, en het ontbrekende tweede prefix levert een storing op die selectief lijkt in plaats van totaal.

[Peer]
PublicKey = <server public key>
Endpoint = vpn.example.net:51820
AllowedIPs = 10.66.0.1/32, 192.168.50.0/24

Doorsturen en vertalen horen op de server

De server heeft IP-doorsturing ingeschakeld nodig, een doorstuurregel die verkeer uit de tunnel accepteert, en een vertaalregel richting zijn LAN-interface. De vertaling is wat het ontwerp laat werken zonder elke host op het kantoor netwerk aan te raken. Antwoorden keren dan terug naar de server in plaats van naar een adres waar het LAN nooit van heeft gehoord. Zonder die vertaling heeft elke host een route naar het tunnelsubnet en een firewallregel die dat toestaat nodig, wat zelden acceptabel is op een netwerk dat iemand anders beheert.

sysctl -w net.ipv4.ip_forward=1
iptables -A FORWARD -i wg0 -j ACCEPT
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

Regels die met de hand zijn toegevoegd verdwijnen bij een herstart, dus bind ze met de hook-opdrachten in de serverconfiguratie aan de interface. Een regelset die zijn interface overleeft, is hoe een machine uiteindelijk verkeer vertaalt voor een tunnel die niet meer bestaat.

Toen het LAN verhuisde en de regel niet

Het vervangen van een router die het kantoorsubnet hernummert is de klassieke versie van deze storing. De tunnel blijft aan, de handshake blijft vers, en niets achter de server antwoordt, omdat de vertaalregel nog steeds het oude adres noemt. Installatiescripts bakken het LAN-adres van de server vaak in een POSTROUTING-regel, en na een hernummering bestaat dat adres op geen enkele interface. Pakketten worden dan herschreven naar een bestemming die niet kan antwoorden.

iptables -t nat -n -L POSTROUTING
ip -br addr show

Vergelijk de twee uitvoer. Een vertaaldoel dat niet in de interfacelijst verschijnt, is de fout, en die herstellen is een wijziging van één regel zodra je hem hebt gezien. De regel kan in een gegenereerde unit staan in plaats van in de WireGuard-configuratie, dus herlaad die unit na het bewerken en bevestig dat de volgende start je wijziging niet overschrijft.

Twee locaties achter NAT hebben een ontmoetingsplek nodig

Wanneer geen van beide kanten inkomende verbindingen accepteert, is het praktische antwoord een kleine host met een openbaar adres en twee WireGuard-interfaces. Elke locatie verbindt naar buiten, de middelste host noemt het LAN van elke peer in zijn eigen AllowedIPs, en doorsturing draagt pakketten tussen de twee tunnels. Niets in de firewall van beide locaties hoeft te veranderen, en daarom verspreidt dit ontwerp zich gemakkelijk.

Routing tussen de locaties behoudt de oorspronkelijke bronadressen en houdt daardoor logging per host zinvol. Vertalen op de middelste host is eenvoudiger wanneer de twee LAN's overlappen, maar ten koste van het verliezen van de bronidentiteit in de logs. Beslis welke eigenschap telt voordat je kiest.

Scheid de lagen met vier controles

Voer één controle per laag uit in plaats van drie dingen te wijzigen en te hopen. De eerste toont de leeftijd van de handshake en tellers per peer. De tweede toont of de client die bestemming echt in de tunnel routeert. De derde en vierde vertellen je of het verzoek aankwam en of een beleid het na aankomst heeft laten vallen.

wg show
ip route get 192.168.50.20
tcpdump -ni wg0 icmp
iptables -vnL FORWARD --line-numbers

Een verzoek dat aankomt en geen antwoord oplevert, wijst op het antwoordpad of op de LAN-host. Een verzoek dat nooit aankomt, wijst op AllowedIPs of op de route van de client. Die twee uitkomsten vragen verschillende correcties, en de opname is wat ze onderscheidt.