Kättely kyllä, internet ei: mitä Windows 11:ssä korjataan ensin

Usein Windows 11:ssä tuoreet kättelyt seisovat sellaisten selainten vieressä, jotka eivät avaa mitään. Kättely todistaa vain, että UDP-vaihto vastapuolen kanssa onnistui. Se ei kerro mitään reitistä, jonka Windows asensi, resolverista, jota se käyttää, eikä siitä, välittääkö ulospääsy ylipäätään mitään.

Neljä ehtoa ratkaisee, mikä noista kerroksista petti. Niiden läpikäyminen järjestyksessä vie minuutteja, kun taas avainten uudelleenkirjoitus vie kauemmin eikä muuta mitään.

Ratkaise kerros ennen kuin kosket avaimiin

Käy läpi kolme kohde tässä järjestyksessä. Aloita tunnelin puoleisesta osoitteesta, sitten julkinen IP numerona ja lopeta isäntänimeen. Siinä, missä sarja katkeaa, kerros nimetään. Ensimmäisen askeleen epäonnistuminen on reititystä, toisessa välitystä tai NAT ja kolmannessa nimien selvitystä.

Tuo järjestys on koko menetelmä. Se estää DNS-vian diagnosoimisen rikkinäiseksi tunneliksi, mikä on täällä yleisin väärä askel.

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

Jos kättelyaika on tyhjä

Kun kättelyaika on tyhjä, salattu vaihto ei koskaan valmistunut. Vika on siis reititystä aiemmin. Katso ensin päätepisteen osoite ja portti, sitten se, suodattaako verkko UDP:tä. Palveluntarjoaja, joka pudottaa WireGuardin liikenteen, tuottaa juuri tämän, ja samoin asiakasohjelma, joka kopioi päätepisteen vanhasta profiilista.

Lähtevät tavut ilman yhtään saapuvaa ovat eri tapaus. Se viittaa NATiin tai palomuuriin, joka palauttaa liikenteen väärään paikkaan.

Jos reitti häviää fyysiselle sovittimelle

Koko tunnelia varten vastapuoliosan on katettava kohteet, joita aiot käyttää. Windows joskus pitää fyysisen sovittimen oletusreitin, vaikka kaiken kattava sääntö olisi asetettu. Kaiken kattavan säännön jakaminen osiin 0.0.0.0/1 plus 128.0.0.0/1 luo kaksi täsmällisempää etuliitettä, jotka voittavat haun. Jako on dokumentoitu kiertotie, ei mieltymys.

Vahvista se route print tai julkisen osoitteen hautauksella. Valitun liitännän pitäisi olla tunnelisovitin. Jos fyysinen yhä voittaa, korjaa vastapuolen alueet ennen kuin kosket palvelimeen.

Jos osoitteet toimivat ja nimet eivät

WireGuard kuljettaa IP-paketteja eikä sillä ole mielipidettä DNS:stä. Laita rivi DNS = liitännän osioon tai aseta sovitin Windowsin kautta. Ilman sitä ping osoitteella onnistuu, kun taas jokainen isäntänimi epäonnistuu, ja käyttäjät raportoivat sen internetin puuttumisena.

Tarkista, mitä palvelimia Windows todella käyttää yhteyden jälkeen. Fyysiselle sovittimelle jäänyt resolver selittää osittaisen vian, jossa jotkin nimet selviävät ja toiset eivät. Siivoa se sen sijaan, että lisäisit toisen päälle.

Jos Windows-kone on ulospääsy

Internet Connection Sharing kirjoittaa osoitteistuksen uudelleen, kun se on käytössä, mikä voi siirtää jaetun sovittimen toiselle alueelle. Asiakasohjelma, joka osoittaa yhä alkuperäiseen osoitteeseen, lakkaa silloin toimimasta. Rekisterin arvot ScopeAddress ja StandaloneDHCPAddress ohjaavat tuota aluetta, ja asetus voi palautua uudelleenkäynnistyksen jälkeen.

Kaksi muuta Windows-kohtaista ristiriitaa kannattaa katsoa. Routing and Remote Access -palvelu voi häiritä tunnelia. Väärälle arkkitehtuurille rakennettu asennusohjelma epäonnistuu viestillä, joka ei mainitse arkkitehtuuria koskaan.

Korjaa kerros, jonka testi nimesi, ja aja sitten samat kolme kohdetta uudelleen. Muutos, joka korjaa isäntänimitestin mutta rikkoo tunnelin osoitteen, kohdistettiin väärään kerrokseen.