Handshake on, interneti pole: mida Windows 11 puhul kõigepealt parandada

Värsked handshake’id seisavad Windows 11 puhul sageli brauserite kõrval, mis ei ava midagi. Handshake tõestab ainult seda, et UDP vahetus partneriga lõppes. See ei ütle midagi marsruudi kohta, mille Windows seadis, ega resolveri kohta, mida see kasutab, ega selle kohta, kas väljapääs üldse midagi edasi saadab.

Neli tingimust otsustavad, milline neist kihtidest ebaõnnestus. Nende järjest läbimine võtab minuteid, samas kui võtmete ümberkirjutamine võtab kauem ja ei muuda midagi.

Tehke kiht kindlaks enne, kui võtmeid puudutate

Käige läbi kolm sihtkohta selles järjekorras. Alustage tunnelipoolsest aadressist, seejärel avalikust IP-st numbrina ja lõpetage hostinimega. Seal, kus jada katkeb, saab kihi nime. Ebaõnnestumine esimeses etapis on marsruutimine, teises edasisaatmine või NAT ja kolmandas nimede lahendamine.

See järjekord ongi kogu meetod. See takistab DNS-tõrke diagnoosimist katkise tunnelina, mis on siin kõige tavalisem vale pööre.

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

Kui handshake’i aeg on tühi

Kui handshake’i aeg on tühi, ei lõppenud krüpteeritud vahetus kunagi. Seega asub tõrge marsruutimisest varem. Vaadake kõigepealt lõpp-punkti aadressi ja porti, seejärel seda, kas võrk filtreerib UDP-d. Majutusteenuse pakkuja, kes WireGuardi liikluse maha viskab, tekitab täpselt selle, ja sama teeb klient, kes kopeeris lõpp-punkti vanast profiilist.

Baidid, mis väljuvad, ilma et ükski sisse tuleks, on teine juhtum. See osutab NAT-ile või tulemüürile, mis saadab liikluse tagasi valesse kohta.

Kui marsruut kaotab füüsilisele adapterile

Täistunneli puhul peab partneri jaotis katma sihtkohad, mida kavatsete kasutada. Windows hoiab mõnikord füüsilise adapteri vaikimisi marsruuti ka siis, kui kõike hõlmav reegel on seatud. Kõike hõlmava reegli jagamine osadeks 0.0.0.0/1 pluss 128.0.0.0/1 loob kaks täpsemat prefiksit, mis päringu võidavad. Jagamine on dokumenteeritud mööduhiilimine, mitte eelistus.

Kinnitage seda route print või avaliku aadressi päringuga. Valitud liides peaks olema tunneliadapter. Kui füüsiline veel võidab, parandage partneri vahemikud enne, kui serverit puudutate.

Kui aadressid töötavad ja nimed ei tööta

WireGuard kannab IP-pakette ja ei arva DNS-i kohta midagi. Pange liidese jaotisse rida DNS = või seadistage adapter Windowsi kaudu. Ilma selleta õnnestub aadressi järgi ping, samal ajal kui iga hostinimi ebaõnnestub, ja kasutajad teatavad sellest kui interneti puudumisest.

Kontrollige, milliseid servereid Windows pärast ühendamist tegelikult kasutab. Füüsilisele adapterile jäänud resolver seletab osalist tõrget, kus mõned nimed lahenevad ja teised mitte. Koristage see ära, selle asemel et teine peale lisada.

Kui Windowsi masin on väljapääs

Internet Connection Sharing kirjutab aadressimise ümber, kui see on sisse lülitatud, mis võib jagatud adapteri teise vahemikku liigutada. Klient, mis osutab endiselt algsele aadressile, lakkab siis töötamast. Registri väärtused ScopeAddress ja StandaloneDHCPAddress juhivad seda vahemikku ja säte võib pärast taaskäivitust tagasi võtta.

Vaadata tasub veel kahte Windowsi-spetsiifilist konflikti. Teenus Routing and Remote Access võib tunnelit segada. Vale arhitektuuri jaoks ehitatud paigaldaja ebaõnnestub sõnumiga, mis ei maini arhitektuuri kunagi.

Parandage kiht, mille test nimetas, ja käivitage siis samad kolm sihtkohta uuesti. Muudatus, mis parandab hostinime testi, aga rikub tunneli aadressi, rakendati valele kihile.