WireGuard werkt op mobiele data, maar niet op dezelfde wifi

De tunnel komt op via mobiele data en blijft thuis vervolgens op verbinden staan, met hetzelfde profiel, dezelfde peersleutel en geen configuratiewijziging ertussen. Het verschil zit in de route: een verzoek van binnen het LAN naar het openbare adres van de router is niet dezelfde reis als een verzoek dat van internet binnenkomt. De meeste thuisgateways implementeren de retourweg helemaal niet of alleen voor bepaalde protocollen. Daardoor lijkt het symptoom op een kapotte sleutel terwijl er aan de sleutel niets is veranderd. Stel eerst vast welk pad heeft gefaald voordat u een sleutel, een port forward of een clientprofiel aanraakt.

Eén adres, twee verschillende paden

Van buitenaf bereikt een pakket het openbare adres van de router en een port-forwardregel geeft het door aan de WireGuard-listener op de interne host. Van binnenaf kiest de client hetzelfde openbare adres, dus het pakket verlaat de client, komt bij de router aan en moet weer richting het LAN worden teruggedraaid. Precies bij die terugdraaiing splitsen de twee paden zich, omdat de router een stroom moet vertalen die dezelfde interface zowel verlaat als weer binnenkomt. Veel implementaties laten hem vallen in plaats van hem te vertalen, en de client wacht dan op een handshake die nooit is verzonden.

Dat gedrag heet meestal NAT-loopback of hairpinning en het hoort bij de router, niet bij WireGuard; RFC 4787 beschrijft de vertaalgevallen waarin een gateway het wel of niet mag ondersteunen. WireGuard zelf heeft geen mening over het pad, omdat het alleen pakketten ziet die zijn interface bereiken. Als de router de stroom laat vallen, ontvangt de daemon nooit iets, meldt de client een handshake-time-out en blijft het serverlog leeg. Een leeg log is dus een aanwijzing waar het pakket is gestopt, geen bewijs dat de server plat ligt. Het is ook de reden waarom een herinstallatie niets verandert.

Het omgekeerde telt ook: een serverlog dat een handshakepoging vanaf het LAN-adres toont, bewijst dat het pakket is aangekomen en het pad in orde is, wat het onderzoek verschuift naar sleutels en toegestane adressen. Lees het log om wat het bewijst, niet om wat u hoopte te zien.

Reproduceer het voordat u iets wijzigt

Test vanuit een geautoriseerd extern netwerk met hetzelfde apparaat en hetzelfde profiel en herhaal de test daarna binnen het LAN zonder iets te bewerken. Een afgeronde handshake buiten en een client die binnen het apparaat nooit verlaat, reproduceren de toestand in plaats van ernaar te gissen. Beide pogingen moeten hetzelfde profiel gebruiken, anders bewijst de vergelijking niets.

Kijk dan waarnaar de eindpuntnaam voor dit apparaat verwijst. De volgende drie opdrachten laten ook zien welk adres de client werkelijk heeft gekozen:

wg show wg0 endpoints
dig +short vpn.example.net A
resolvectl query vpn.example.net

De eerste opdracht meldt het eindpunt dat de interface op dit moment gebruikt, en de andere twee laten zien waarnaar de naam op deze machine verwijst. Een client die een openbaar adres kiest terwijl hij op hetzelfde netwerk als de server zit, gebruikt het hairpin-pad. Een client die het LAN-adres kiest doet dat niet, en een storing daar hoort bij een ander onderzoek. Dat onderscheid bepaalt of de volgende paragraaf überhaupt van toepassing is.

Toegestane manieren om een nabije server te bereiken

De schoonste oplossing is een split-horizon-antwoord: de openbare naam verwijst voor internet naar het openbare adres en voor clients binnen naar het LAN-adres van de server. Het profiel houdt één eindpuntnaam en de resolver kiest het pad. Dat vereist controle over het interne DNS-antwoord, die een thuisrouter meestal biedt en een organisatie bewust kan regelen. Zonder die controle blijven alleen een routerfunctie of een tweede profiel over.

De routerfunctie is reflectie: de gateway vertaalt de stroom van binnen naar buiten en stuurt hem weer naar binnen. Waar het werkt, is geen clientwijziging nodig, en waar het niet werkt, redt geen enkele clientinstelling het. Test het door tijdens een interne poging het serverlog te bekijken in plaats van de functielijst van de router te lezen.

Het profiel naar een privéadres omzetten is een diagnose, geen ontwerp. Het bewijst dat de server op het LAN antwoordt, en het breekt hetzelfde profiel op het moment dat de laptop het huis verlaat.

Houd het profiel bruikbaar buiten huis

Welk pad u ook kiest, laat de identiteitscontrole met rust. Het eindpuntadres is niet de peer-identiteit, en een adreswijziging rechtvaardigt nooit het accepteren van een ongerelateerde openbare sleutel die toevallig antwoordt. WireGuard authenticeert via de sleutel, dus een verkeerde host faalt op de handshake in plaats van toegang tot iets onverwachts te geven.

Als het openbare adres verschuift, houdt dynamische DNS de naam bruikbaar, en het verversingsgedrag van de client bepaalt hoe snel de wijziging doorwerkt. Test dat na een adreswijziging van buitenaf, want het LAN-geval kan het niet bevestigen. Let op een resolver die het oude antwoord langer dan de levensduur van de record cachet. Een naam die nog naar het vorige adres wijst, ziet er precies zo uit als een server die is uitgevallen.

Schrijf op welke naam het profiel gebruikt en waarnaar die aan beide zijden van de grens verwijst. Een profiel dat afhangt van een routerfunctie die niemand heeft vastgelegd, is een supportoproep die op de volgende firmware-update wacht. De notitie vertelt ook de volgende persoon of een interne storing het bekende hairpin-geval is of iets nieuws.