Rokovanje da, internet ne: kaj na Windows 11 popraviti najprej

V sistemu Windows 11 sveža rokovanja pogosto stojijo ob brskalnikih, ki ne odprejo ničesar. Rokovanje dokazuje le, da se je izmenjava UDP s partnerjem končala. Ne pove ničesar o poti, ki jo je namestil Windows, o resolverju, ki ga uporablja, niti o tem, ali izhod sploh kaj posreduje.

Štirje pogoji odločajo, kateri od teh slojev je odpovedal. Prehod čeznje po vrsti vzame minute, medtem ko prepisovanje ključev vzame več časa in ne spremeni ničesar.

Ugotovite sloj, preden se dotaknete ključev

Pojdite skozi tri cilje v tem vrstnem redu. Začnite z naslovom na strani tunela, nato javni IP kot število in končajte z imenom gostitelja. Kjer se veriga pretrga, tam se poimenuje sloj. Neuspeh na prvem koraku je usmerjanje, na drugem je posredovanje ali NAT, na tretjem pa razreševanje imen.

Ta vrstni red je cela metoda. Preprečuje, da bi se napaka DNS diagnosticirala kot pokvarjen tunel, kar je tu najpogostejša napačna smer.

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

Če je čas rokovanja prazen

Ko je čas rokovanja prazen, se šifrirana izmenjava ni nikoli končala. Napaka je torej pred usmerjanjem. Najprej poglejte naslov končne točke in vrata, nato pa, ali omrežje filtrira UDP. Ponudnik gostovanja, ki zavrže promet WireGuard, povzroči točno to, prav tako odjemalec, ki je kopiral končno točko iz starega profila.

Bajti, ki odhajajo, nihče pa ne prihaja, so drug primer. To kaže na NAT ali požarni zid, ki vrača promet na napačno mesto.

Če pot izgubi proti fizičnemu vmesniku

Za polni tunel mora razdelek partnerja pokrivati cilje, ki jih nameravate uporabljati. Windows včasih obdrži privzeto pot fizičnega vmesnika tudi z nastavljenim pravilom za vse. Razdelitev pravila za vse na 0.0.0.0/1 in 128.0.0.0/1 ustvari dva bolj določena predpona, ki zmagata pri iskanju. Razdelitev je dokumentirana rešitev, ne preference.

To potrdite s route print ali poizvedbo javnega naslova. Izbrani vmesnik bi moral biti tunelski vmesnik. Če fizični še vedno zmaga, popravite obsege partnerja, preden se dotaknete strežnika.

Če naslovi delujejo in imena odpovedo

WireGuard prenaša pakete IP in nima mnenja o DNS. Vstavite vrstico DNS = v razdelek vmesnika ali nastavite vmesnik prek sistema Windows. Brez nje ping po naslovu uspe, medtem ko vsako ime gostitelja odpove, in uporabniki to prijavijo kot ni internetnega dostopa.

Preverite, katere strežnike Windows po povezavi res uporablja. Ostali resolver na fizičnem vmesniku pojasnjuje delno odpoved, ko se nekatera imena razrešijo, druga pa ne. Počistite ga, namesto da bi dodali drugega povrhu.

Če je računalnik z Windows izhod

Internet Connection Sharing ob vklopu prepiše naslavljanje, kar lahko premakne skupni vmesnik v drug obseg. Odjemalec, ki še vedno kaže na prvotni naslov, potem preneha delovati. Vrednosti v registru ScopeAddress in StandaloneDHCPAddress nadzorujejo ta obseg, nastavitev pa se lahko po ponovnem zagonu povrne.

Vredna ogleda sta še dva konflikta, značilna za Windows. Storitev Routing and Remote Access lahko moti tunel. Nameščevalnik, zgrajen za napačno arhitekturo, odpove s sporočilom, ki nikoli ne omeni arhitekture.

Popravite sloj, ki ga je imenoval test, nato znova zaženite iste tri cilje. Sprememba, ki popravi test imena gostitelja, a pokvari naslov tunela, je bila uporabljena na napačnem sloju.