WireGuard wurket op mobile data, mar net op itselde wifi
In oanfraach fan binnen it LAN nei it iepenbiere adres fan ’e router nimt in oar paad as ien fan mobile data. Test bûten en kies dan in lokaal paad.
De tunnel komt op by mobile data en bliuwt thús dan by ferbinen stean, mei itselde profyl, deselde peer-kaai en gjin konfiguraasjewizing dertusken. It ferskil sit yn ’e reis: in oanfraach fan binnen it LAN nei it iepenbiere adres fan ’e router is net deselde reis as in oanfraach dy’t fan it ynternet komt. De measte thúsgateways ymplementearje de weromweis net, of allinnich foar beskate protokollen. Dêrtroch liket it symptoom op in stikken kaai wylst der oan ’e kaai neat feroare is. Stel earst fêst hokker paad mislearre is foardat jo in kaai, in poartetrochferwizing of in kliïntprofyl oanreitsje.
Ien adres, twa ferskillende paden
Fan bûten berikt in pakket it iepenbiere adres fan ’e router en in poartetrochferwizingsregel jout it oan ’e WireGuard-listener op ’e ynterne host. Fan binnen kiest de kliïnt itselde iepenbiere adres, sadat it pakket de kliïnt ferlit, by de router oankomt en wer nei it LAN taomdraaid wurde moat. Krekt by dy weromdraaiing skiede de twa paden, om’t de router in stream oersette moat dy’t itselde ynterface sawol ferlit as wer ynkomt. In protte ymplemintaasjes litte him falle ynstee fan him oer te setten, en de kliïnt wachtet dan op in handshake dy’t nea ferstjoerd is.
It gedrach wurdt meastentiids NAT-loopback of hairpinning neamd, en it heart by de router ynstee fan by WireGuard; RFC 4787 beskriuwt de oersettingsgefallen wêryn’t in gateway it wol of net stypje mei. WireGuard sels hat gjin miening oer it paad, om’t it allinnich pakketten sjocht dy’t syn ynterface berikke. As de router de stream lit falle, ûntfangt de daemon nea eat, meldt de kliïnt in handshake-timeout en bliuwt it serverlog leech. In leech log is dêrom in oanwizing wêr’t it pakket stoppe is, gjin bewiis dat de server del is. It is ek de reden wêrom’t in weromsetten neat feroaret.
It omkearde jildt ek: in serverlog dat in handshake-poging fan it LAN-adres sjen lit, bewissiget dat it pakket oankaam is en it paad goed is, wat it ûndersyk ferpleatst nei kaaien en tastiene adressen. Lês it log om wat it bewissiget, net om wat jo hope te sjen.
Reprodusearje it foardat jo eat feroarje
Test fan in autorisearre ekstern netwurk mei itselde apparaat en itselde profyl, en werhelje de test dêrnei binnen it LAN sûnder eat te bewurkjen. In foltôge handshake bûten en in kliïnt dy’t binnen nea it apparaat ferlit, reprodusearje de tastân ynstee fan dernei te rieden. Beide pogingen moatte itselde profyl brûke, oars bewissiget de ferliking neat.
Sjen dan wêrop’t de einpuntnamme foar dit apparaat oplost. De folgjende trije opdrachten litte ek sjen hokker adres de kliïnt eins keazen hat:
wg show wg0 endpoints
dig +short vpn.example.net A
resolvectl query vpn.example.netDe earste opdracht meldt it einpunt dat it ynterface op dit stuit brûkt, en de oare twa litte sjen wêrop’t de namme op dizze masine oplost. In kliïnt dy’t in iepenbier adres kiest wylst er op itselde netwurk as de server sit, brûkt it hairpin-paad. In kliïnt dy’t it LAN-adres kiest docht dat net, en in flater dêre heart by in oar ûndersyk. Dat ûnderskie beslút oft de folgjende paragraaf wol jildt.
Stipe manieren om in tichtby lizzende server te berikken
De skjinste oplossing is in split-horizon-antwurd: de iepenbiere namme lost foar it ynternet op it iepenbiere adres op en foar kliïnten binnen op it LAN-adres fan ’e server. It profyl hâldt ien einpuntnamme en de resolver kiest it paad. Dat freget kontrôle oer it ynterne DNS-antwurd, dy’t in thúsrouter meastentiids biedt en in organisaasje bewust regelje kin. Sûnder dy kontrôle bliuwe de karren in routerfunksje of in twadde profyl.
De routerfunksje is refleksje: de gateway set de stream fan binnen nei bûten oer en stjoert him wer nei binnen. Wêr’t it wurket, freget it gjin kliïntwizing, en wêr’t it net wurket, rêdt gjin inkelde kliïntynstelling it. Test it troch it serverlog by in ynterne poging te folgjen ynstee fan ’e funksjelist fan ’e router te lêzen.
It profyl nei in privee adres bewurkje is in diagnoaze, gjin ûntwerp. It bewissiget dat de server op it LAN antwurdet, en it brekt itselde profyl op it stuit dat de laptop it hûs ferlit.
| Approach | What it depends on | Where it fails |
|---|---|---|
| Split-horizon name | Control of the internal DNS answer | Clients that resolve through a server outside the zone |
| Router reflection | Gateway support for hairpin translation | Routers that drop the flow silently |
| Private address in the profile | Nothing beyond the LAN | Every network except the one at home |
Hâld it profyl brûkber bûten hûs
Hokker paad jo ek kieze, lit de identiteitskontrôle gewurde. It einpuntadres is net de peer-identiteit, en in adreswiziging rjochtfeardiget nea it akseptearjen fan in net besibbe iepenbiere kaai dy’t tafallich antwurdet. WireGuard autentisearret fia de kaai, dus in ferkearde host mislearret de handshake ynstee fan tagong ta wat ûnferwachts te jaan.
As it iepenbiere adres ferskoot, hâldt dynamyske DNS de namme brûkber, en it ferfarskingsgedrach fan ’e kliïnt beslút hoe fluch de wizing trochkomt. Test dat fan bûten nei in adreswiziging, want it LAN-gefal kin it net befêstigje. Let op in resolver dy’t it âlde antwurd langer as de libbensdoer fan ’e record cachet. In namme dy’t noch nei it foarige adres wiist, liket krekt op in server dy’t del gien is.
Skriuw op hokker namme it profyl brûkt en wêrop’t dy oan beide kanten fan ’e grins oplost. In profyl dat fan in routerfunksje ôfhinget dy’t nimmen fêstlein hat, is in supportoproep dy’t op ’e folgjende firmware-update wachtet. De notysje fertelt ek de folgjende persoan oft in ynterne flater it bekende hairpin-gefal is of eat nijs.