WireGuard fungerar på mobildata men inte på samma wifi

Tunneln kommer upp på mobildata och stannar sedan på ansluter hemma, med samma profil, samma peer-nyckel och ingen konfigurationsändring däremellan. Skillnaden sitter i resan: en förfrågan inifrån LAN:et till routerns publika adress är inte samma resa som en förfrågan som kommer från internet. De flesta hemgateways implementerar inte returvägen alls, eller bara för vissa protokoll. Det får symtomet att se ut som en trasig nyckel medan ingenting vid nyckeln har flyttat sig. Fastställ vilken väg som misslyckades innan du rör en nyckel, en portvidarebefordran eller en klientprofil.

En adress, två olika vägar

Utifrån når ett paket routerns publika adress, och en portvidarebefordringsregel lämnar det till WireGuard-lyssnaren på den interna värden. Inifrån ringer klienten samma publika adress, så paketet lämnar klienten, kommer till routern och måste vändas tillbaka mot LAN:et. Det är vid den vändningen de två vägarna skiljs, eftersom routern måste översätta ett flöde som både lämnar och kommer in igen på samma gränssnitt. Många implementationer släpper det i stället för att översätta det, och klienten väntar då på en handskakning som aldrig skickades.

Beteendet kallas oftast NAT-loopback eller hairpinning, och det hör till routern snarare än till WireGuard; RFC 4787 beskriver de översättningsfall där en gateway kan eller inte kan stödja det. WireGuard själv har ingen åsikt om vägen, eftersom den bara ser paket som når dess gränssnitt. När routern släpper flödet tar daemonen aldrig emot något, klienten rapporterar timeout för handskakningen, och serverloggen förblir tom. En tom logg är därför en ledtråd om var paketet stannade, inte bevis för att servern är nere. Det är också därför en ominstallation inte ändrar något.

Det omvända räknas också: en serverlogg som visar ett handskakningsförsök från LAN-adressen bevisar att paketet kom fram och att vägen är okej, vilket flyttar undersökningen till nycklar och tillåtna adresser. Läs loggen för vad den bevisar, inte för vad du hoppades få se.

Återskapa det innan du ändrar något

Testa från ett auktoriserat externt nätverk med samma enhet och samma profil och upprepa sedan testet inne i LAN:et utan att ändra något. En genomförd handskakning ute och en klient som inne aldrig lämnar enheten återskapar tillståndet i stället för att gissa på det. Båda försöken måste använda samma profil, annars bevisar jämförelsen ingenting.

Titta sedan på vad slutpunktsnamnet löser upp till för den här enheten. De tre följande kommandona visar också vilken adress klienten faktiskt ringde:

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

Det första kommandot rapporterar den slutpunkt som gränssnittet använder just nu, och de två andra visar vad namnet löser upp till på den här maskinen. En klient som ringer en publik adress medan den sitter på samma nätverk som servern använder hairpin-vägen. En klient som ringer LAN-adressen gör det inte, och ett fel där hör till en annan undersökning. Den skillnaden avgör om nästa avsnitt gäller alls.

Stödda sätt att nå en server i närheten

Den renaste lösningen är ett split-horizon-svar: det publika namnet löser upp till den publika adressen för internet och till serverns LAN-adress för klienter innanför. Profilen behåller ett slutpunktsnamn och resolvern väljer vägen. Det kräver kontroll över det interna DNS-svaret, vilket en hemrouter oftast erbjuder och en organisation kan ordna medvetet. Utan den kontrollen återstår en routerfunktion eller en andra profil.

Routerfunktionen är reflektion: gatewayen översätter flödet från insidan till utsidan och skickar tillbaka det in. Där den fungerar krävs ingen klientändring, och där den inte fungerar räddar ingen klientinställning den. Testa den genom att följa serverloggen under ett internt försök i stället för att läsa routerns funktionslista.

Att ändra profilen till en privat adress är en diagnos, inte en design. Det bevisar att servern svarar på LAN:et, och det bryter samma profil i samma stund som laptopen lämnar huset.

Håll profilen användbar borta hemifrån

Vilken väg du än väljer, låt identitetskontrollen vara. Slutpunktsadressen är inte peer-identiteten, och en adressändring rättfärdigar aldrig att acceptera en orelaterad publik nyckel som råkar svara. WireGuard autentiserar med nyckeln, så en felaktig värd misslyckas med handskakningen i stället för att ge åtkomst till något oväntat.

Om den publika adressen flyttar sig är dynamisk DNS det som håller namnet användbart, och klientens uppdateringsbeteende avgör hur snabbt ändringen slår igenom. Testa det utifrån efter en adressändring, eftersom LAN-fallet inte kan bekräfta det. Se upp för en resolver som cachar det gamla svaret längre än postens livstid. Ett namn som fortfarande pekar på den förra adressen ser exakt ut som en server som gick ner.

Skriv ner vilket namn profilen använder och vad det löser upp till på varje sida av gränsen. En profil som beror på en routerfunktion som ingen har antecknat är ett supportärende som väntar på nästa firmwareuppdatering. Anteckningen är också det som talar om för nästa person huruvida ett internt fel är det kända hairpin-fallet eller något nytt.