Handshake da, internet nu: ce reparăm mai întâi pe Windows 11

Pe Windows 11, handshake-urile recente stau adesea lângă browsere care nu deschid nimic. Handshake-ul dovedește doar că schimbul UDP cu partenerul s-a încheiat. Nu spune nimic despre ruta instalată de Windows, despre resolverul pe care îl folosește, nici despre dacă ieșirea transmite ceva.

Patru condiții decid care dintre aceste straturi a eșuat. Parcurgerea lor în ordine durează minute, în timp ce rescrierea cheilor durează mai mult și nu schimbă nimic.

Stabiliți stratul înainte de a atinge cheile

Parcurgeți trei destinații, în această ordine. Începeți cu o adresă din partea tunelului, apoi un IP public ca număr și terminați cu un nume de gazdă. Acolo unde lanțul se rupe, acolo se numește stratul. Un eșec la primul pas este rutare, la al doilea este transmitere sau NAT, iar la al treilea este rezolvare de nume.

Această ordine este întreaga metodă. Împiedică diagnosticarea unei defecțiuni DNS ca tunel rupt, care este cea mai frecventă direcție greșită aici.

wg show
Find-NetRoute -RemoteIPAddress 1.1.1.1
Resolve-DnsName example.com -Server 1.1.1.1

Dacă timpul handshake-ului este gol

Când timpul handshake-ului este gol, schimbul criptat nu s-a încheiat niciodată. Deci defecțiunea se află mai devreme decât rutarea. Uitați-vă mai întâi la adresa punctului final și la port, apoi dacă rețeaua filtrează UDP. Un furnizor de găzduire care aruncă traficul WireGuard produce exact asta, la fel și un client care a copiat un punct final dintr-un profil vechi.

Octeții care ies fără să intre niciunul sunt alt caz. Asta indică NAT sau un firewall care trimite traficul înapoi în locul greșit.

Dacă ruta pierde în fața adaptorului fizic

Pentru un tunel complet, secțiunea partenerului trebuie să acopere destinațiile pe care intenționați să le folosiți. Windows păstrează uneori ruta implicită a adaptorului fizic chiar și cu o regulă generală configurată. Împărțirea regulii generale în 0.0.0.0/1 plus 128.0.0.0/1 creează două prefixe mai specifice care câștigă căutarea. Împărțirea este o soluție documentată, nu o preferință.

Confirmați cu route print sau cu o căutare a unei adrese publice. Interfața aleasă ar trebui să fie adaptorul tunelului. Dacă cel fizic câștigă în continuare, corectați intervalele partenerului înainte de a atinge serverul.

Dacă adresele funcționează și numele eșuează

WireGuard transportă pachete IP și nu are opinie despre DNS. Puneți o linie DNS = în secțiunea de interfață sau configurați adaptorul prin Windows. Fără ea, un ping după adresă reușește în timp ce fiecare nume de gazdă eșuează, iar utilizatorii raportează asta ca lipsă de internet.

Verificați ce servere folosește Windows efectiv după conectare. Un resolver rămas pe adaptorul fizic explică un eșec parțial, în care unele nume se rezolvă și altele nu. Curățați-l în loc să adăugați un al doilea deasupra.

Dacă mașina Windows este ieșirea

Internet Connection Sharing rescrie adresarea când este activat, ceea ce poate muta adaptorul partajat într-un alt interval. Un client care încă indică adresa originală nu mai funcționează. Valorile de registru ScopeAddress și StandaloneDHCPAddress controlează acel interval, iar setarea poate reveni după o repornire.

Merită o privire alte două conflicte specifice Windows. Serviciul Routing and Remote Access poate interfera cu tunelul. Un instalator creat pentru arhitectura greșită eșuează cu un mesaj care nu menționează niciodată arhitectura.

Reparați stratul numit de test, apoi rulați din nou aceleași trei destinații. O modificare care repară testul numelui de gazdă dar rupe adresa tunelului a fost aplicată stratului greșit.