WireGuard-peer onbereikbaar terwijl een andere werkt: checklist

Eén WireGuard-peer laat verkeer door en een tweede doorloopt de handshake maar bereikt nooit iets achter de tunnel. De werkende peer vertelt u dat de interface, de UDP-poort en de serversleutel waarschijnlijk in orde zijn. Hij vertelt u niets over de AllowedIPs van de tweede peer, het interne bronadres of de doorstuurregels ertussen. Werk de lijst op volgorde af en stop bij de eerste stap waarvan de voorwaarde niet klopt.

Stap 1: Schrijf het pad op dat het pakket moet volgen

Twee clients op dezelfde hub bereiken elkaar niet automatisch. In een hub-en-spoke-ontwerp ontvangt de server het pakket op wg0 en moet het er weer uit wg0 sturen naar de andere peer, wat IP-doorsturing en een doorstuurregel vereist. In een direct peer-tot-peer-ontwerp heeft elke kant het eindpunt van de ander nodig en het tunneladres van de ander binnen de AllowedIPs. Bepaal welk ontwerp u debugt voordat u enige configuratie leest.

Het verwachte pad vertelt u ook waar u moet kijken. Als het pakket de hub moet passeren, is de mislukte hop ofwel de AllowedIPs van de afzender, ofwel de doorsturing op de hub, ofwel de AllowedIPs van de ontvanger. Als het rechtstreeks moet gaan, is de hub irrelevant en zijn de eindpuntvelden op beide peers van belang.

Stap 2: Vergelijk de AllowedIPs aan beide kanten, niet maar één

WireGuard gebruikt AllowedIPs zowel als routetabel als als toegangslijst. Bij verzenden wordt het bestemmingsadres in de AllowedIPs van de peer opgezocht om de tunnel te kiezen; bij ontvangen moet het interne bronadres binnen de AllowedIPs van de verzendende peer vallen, anders wordt het pakket weggegooid. Een ontbrekend bereik aan een van beide kanten geeft hetzelfde symptoom: transport werkt, de lading verdwijnt.

Lees de live status in plaats van het bestand, want een herlaad kan stil zijn mislukt: sudo wg show wg0 allowed-ips. Op de server moet de vermelding van de mislukte peer zijn tunneladres bevatten, bijvoorbeeld 10.90.0.3/32. Op de client moet de vermelding van de serverpeer de bestemming bevatten die u test, of dat nu het tunneladres van de hub is of het externe subnet. Overlappende bereiken maken het opzoeken dubbelzinnig en kunnen een peer kiezen die u niet bedoelde, dus houd ze gescheiden.

Stap 3: Controleer het interne bronadres

Een client die 10.90.0.3 via wg0 routeert maar pakketten vanaf zijn Wi-Fi-adres verstuurt, wordt door de ontvanger geweigerd, omdat de bron niet overeenkomt met de AllowedIPs van de peer. Controleer wat de kernel werkelijk kiest met ip route get 10.90.0.3 from 10.90.0.2, en controleer het adres dat aan de tunnelinterface is toegewezen met ip -brief addr show wg0.

Op de ontvangende Linux-host is reverse-path-filtering een tweede poort. Een strikte rp_filter op de interface die de terugroute bezit, kan tunnelverkeer weggooien waarvan de terugweg niet overeenkomt met de interface waarop het aankwam. Controleer de effectieve waarde voordat u die uitschakelt; in veel topologyen is de juiste oplossing een route, geen versoepeld filter.

Stap 4: Bekijk de doorsturing op de hub en de terugweg

Als de hub tussen peers moet doorsturen, heeft de kernel net.ipv4.ip_forward=1 nodig, en de firewall moet de doorgestuurde stroom accepteren: in op wg0, uit op wg0, van het tunneladres van de afzender naar dat van de ontvanger. Een veelvoorkomende fout is een invoerregel die UDP 51820 accepteert maar geen doorstuurregel], zodat de handshake lukt en de lading sterft. Som de geldende regels op met sudo nft list ruleset of het equivalent voor uw firewallbeheerder.

Controleer daarna het antwoord. De bestemmingshost moet een route terug naar de afzender hebben, hetzij via de hub, hetzij via zijn eigen gateway. Als de hub ook NAT doet op het tunnelsubnet, controleer dan dat de vertaling geldt voor de doorgestuurde stroom en dat het antwoord de hub bereikt voordat de status verloopt. Een eenrichtingsfout die op een sleutelprobleem lijkt, is vaak precies deze terugroute.

Scheid ten slotte de handshake van de data. Een peer die de handshake voltooit maar vastloopt bij grote overdrachten heeft meestal een MTU- of MSS-probleem op dat specifieke pad, geen AllowedIPs-probleem. Test eerst met een kleine ping, daarna met een van volledige grootte, en vergelijk de twee peers.

Stap 5: Verander één ding en houd de werkende peer intact

Breng één enkele wijziging aan op het mislukte pad en test beide peers opnieuw. De AllowedIPs van elke peer vervangen door 0.0.0.0/0 is de snelste manier om de peer te breken die al werkte, omdat het de routingbeslissing voor al het verkeer op die interface verandert. Bewerk die ene vermelding, herlaad en lees de live status terug.

Noteer welk pad slaagde, welk pad faalde en de exacte commando-uitvoer voor elk. Die vergelijking is meer waard dan een algemeen rapport dat de VPN kapot is, en het is het eerste waar de volgende persoon om zal vragen.