WireGuard funcționează pe date mobile, dar nu pe același wifi

Tunelul se ridică pe date mobile și apoi rămâne pe se conectează acasă, cu același profil, aceeași cheie de peer și nicio modificare de configurație între timp. Diferența stă în drum: o cerere din interiorul LAN-ului către adresa publică a routerului nu este aceeași călătorie ca o cerere care sosește din internet. Majoritatea gateway-urilor de acasă fie nu implementează calea de întoarcere, fie o implementează doar pentru anumite protocoale. Asta face simptomul să pară o cheie defectă deși nimic la cheie nu s-a mișcat. Stabiliți care cale a eșuat înainte de a atinge o cheie, o redirecționare de port sau un profil de client.

O adresă, două căi diferite

Din exterior, un pachet ajunge la adresa publică a routerului, iar o regulă de redirecționare de port îl predă ascultătorului WireGuard de pe gazda internă. Din interior, clientul formează aceeași adresă publică, așa că pachetul pleacă de la client, ajunge la router și trebuie întors spre LAN. Exact la această întoarcere se despart cele două căi, pentru că routerul trebuie să traducă un flux care iese și reintră pe aceeași interfață. Multe implementări îl aruncă în loc să îl traducă, iar clientul așteaptă atunci o strângere de mână care nu a fost niciodată trimisă.

Comportamentul se numește de obicei NAT loopback sau hairpinning și aparține routerului, nu lui WireGuard; RFC 4787 expune cazurile de traducere în care un gateway poate sau nu să îl accepte. WireGuard în sine nu are o părere despre cale, pentru că vede doar pachetele care ajung la interfața sa. Când routerul aruncă fluxul, daemonul nu primește niciodată nimic, clientul raportează un timp de așteptare al strângerii de mână, iar jurnalul serverului rămâne gol. Un jurnal gol este deci un indiciu despre locul unde s-a oprit pachetul, nu o dovadă că serverul este căzut. Este și motivul pentru care o reinstalare nu schimbă nimic.

Și inversul contează: un jurnal al serverului care arată o încercare de strângere de mână de la adresa LAN dovedește că pachetul a ajuns și că calea este bună, ceea ce mută ancheta spre chei și adrese permise. Citiți jurnalul pentru ce dovedește, nu pentru ce sperați să vedeți.

Reproduceți înainte de a schimba ceva

Testați dintr-o rețea externă autorizată cu același dispozitiv și același profil, apoi repetați testul în interiorul LAN-ului fără să modificați nimic. O strângere de mână finalizată afară și un client care înăuntru nu părăsește niciodată dispozitivul reproduc condiția în loc să o ghicească. Ambele încercări trebuie să folosească același profil, altfel comparația nu dovedește nimic.

Priviți apoi la ce se rezolvă numele punctului final pentru acest dispozitiv. Următoarele trei comenzi arată și ce adresă a format clientul de fapt:

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

Prima comandă raportează punctul final pe care îl folosește interfața acum, iar celelalte două arată la ce se rezolvă numele pe această mașină. Un client care formează o adresă publică în timp ce se află în aceeași rețea cu serverul exercită calea hairpin. Un client care formează adresa LAN nu face asta, iar o defecțiune acolo aparține unei alte anchete. Această distincție decide dacă secțiunea următoare se aplică măcar.

Moduri acceptate de a ajunge la un server apropiat

Cel mai curat aranjament este un răspuns cu orizont divizat: numele public se rezolvă la adresa publică pentru internet și la adresa LAN a serverului pentru clienții din interior. Profilul păstrează un singur nume de punct final, iar resolverul alege calea. Asta cere control asupra răspunsului DNS intern, pe care un router de acasă îl oferă de obicei și pe care o organizație îl poate aranja intenționat. Fără acel control, opțiunile rămase sunt o funcție a routerului sau un al doilea profil.

Funcția routerului este reflexia: gateway-ul traduce fluxul din interior spre exterior și îl trimite înapoi înăuntru. Acolo unde funcționează nu are nevoie de nicio modificare la client, iar acolo unde nu funcționează nicio setare a clientului nu o salvează. Testați-o urmărind jurnalul serverului în timpul unei încercări interne, în loc să citiți lista de funcții a routerului.

Editarea profilului către o adresă privată este un diagnostic, nu un proiect. Dovedește că serverul răspunde în LAN și rupe același profil în momentul în care laptopul pleacă de acasă.

Păstrați profilul utilizabil departe de casă

Orice cale ați alege, lăsați în pace verificarea identității. Adresa punctului final nu este identitatea peer-ului, iar o schimbare de adresă nu justifică niciodată acceptarea unei chei publice străine care se întâmplă să răspundă. WireGuard autentifică prin cheie, așa că o gazdă greșită eșuează strângerea de mână în loc să acorde acces la ceva neașteptat.

Dacă adresa publică se mută, DNS-ul dinamic este ceea ce ține numele util, iar comportamentul de reîmprospătare al clientului decide cât de repede ajunge schimbarea. Testați asta din exterior după o schimbare de adresă, pentru că cazul LAN nu îl poate valida. Fiți atenți la un resolver care păstrează în cache răspunsul vechi peste durata de viață a înregistrării. Un nume care încă indică adresa anterioară arată exact ca un server care a căzut.

Notați ce nume folosește profilul și la ce se rezolvă pe fiecare parte a graniței. Un profil care depinde de o funcție a routerului pe care nimeni nu a consemnat-o este un apel la suport care așteaptă următoarea actualizare de firmware. Nota este și ceea ce îi spune următoarei persoane dacă o defecțiune internă este cazul hairpin cunoscut sau ceva nou.