Handshake yra, interneto nėra: ką taisyti pirmiausia Windows 11

Windows 11 dažnai nauji handshake stovi šalia naršyklių, kurios nieko neatidaro. Handshake įrodo tik tai, kad UDP mainai su partneriu baigėsi. Jis nieko nesako apie maršrutą, kurį įdiegė Windows, apie naudojamą resolverį, nei apie tai, ar išėjimas apskritai ką nors persiunčia.

Keturių sąlygų sprendžia, kuris iš šių sluoksnių nepavyko. Juos peržiūrėti iš eilės užima minutes, o raktų perrašymas užima ilgiau ir nieko nekeičia.

Nustatykite sluoksnį prieš liesdami raktus

Pereikite tris taikinius šia tvarka. Pradėkite nuo adreso tunelio pusėje, tada viešas IP kaip skaičius, ir pabaikite su kompiuterio vardu. Ten, kur seka nutrūksta, ten ir įvardijamas sluoksnis. Pirmo žingsnio nesėkmė yra maršrutizavimas, antrojo – persiuntimas arba NAT, trečiojo – vardų skyrimas.

Ši tvarka yra visas metodas. Ji neleidžia DNS gedimo diagnozuoti kaip sulaužyto tunelio, o tai čia dažniausia klaidinga kryptis.

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

Jei handshake laikas tuščias

Kai handshake laikas tuščias, užšifruoti mainai niekada nebuvo baigti. Taigi gedimas yra anksčiau nei maršrutizavimas. Pirmiausia pažiūrėkite į galinio taško adresą ir prievadą, paskui – ar tinklas filtruoja UDP. Hostingo teikėjas, kuris meta WireGuard srautą, sukuria būtent tai, ir klientas, kuris nukopijavo galinį tašką iš seno profilio, taip pat.

Baitai, kurie išeina, bet neįeina nė vienas, yra kitas atvejis. Tai rodo į NAT arba ugniagesį, kuris grąžina srautą ne į tą vietą.

Jei maršrutas pralaimi fiziniam adapteriui

Visam tuneliui partnerio sekcija turi apimti taikinius, kuriuos ketinate naudoti. Windows kartais palieka fizinio adapterio numatytąjį maršrutą net ir nustačius viską apimančią taisyklę. Viską apimančios taisyklės padalijimas į 0.0.0.0/1 ir 128.0.0.0/1 sukuria du konkretesnius prefiksus, kurie laimi paiešką. Padalijimas yra dokumentuotas apeities būdas, o ne preferencija.

Patvirtinkite tai su route print arba viešo adreso paieška. Pasirinkta sąsaja turėtų būti tunelio adapteris. Jei fizinis vis dar laimi, pataisykite partnerio diapazonus prieš liesdami serverį.

Jei adresai veikia, o vardai nepavyksta

WireGuard perduoda IP paketus ir neturi nuomonės apie DNS. Įdėkite DNS = eilutę į sąsajos sekciją arba nustatykite adapterį per Windows. Be jos ping pagal adresą pavyksta, o kiekvienas kompiuterio vardas nepavyksta, ir vartotojai tai praneša kaip interneto nebuvimą.

Patikrinkite, kuriuos serverius Windows iš tikrųjų naudoja po prisijungimo. Fiziniame adapteryje likęs resolveris paaiškina dalinę nesėkmę, kai kai kurie vardai išsprendžiami, o kiti ne. Išvalykite jį, o ne pridėkite antrą ant viršaus.

Jei Windows kompiuteris yra išėjimas

Internet Connection Sharing perrašo adresavimą, kai įjungtas, todėl bendrinamas adapteris gali persikelti į kitą diapazoną. Klientas, kuris vis dar rodo į pradinį adresą, tada nustoja veikti. Registro reikšmės ScopeAddress ir StandaloneDHCPAddress valdo tą diapazoną, o nustatymas gali grįžti po perkrovimo.

Verti dėmesio dar du Windows būdingi konfliktai. Paslauga Routing and Remote Access gali trukdyti tuneliui. Neteisingai architektūrai sukurtas diegėjas nepavyksta su pranešimu, kuris niekada nemini architektūros.

Pataisykite sluoksnį, kurį įvardijo testas, tada paleiskite tuos pačius tris taikinius iš naujo. Pakeitimas, kuris pataiso kompiuterio vardo testą, bet sugadina tunelio adresą, buvo pritaikytas neteisingam sluoksniui.