Kézfogás van, internet nincs: mit javítsunk először Windows 11-en

Windows 11-en gyakran állnak friss kézfogások olyan böngészők mellett, amelyek semmit sem nyitnak meg. A kézfogás csak azt bizonyítja, hogy a társal végzett UDP-csere befejeződött. Semmit sem mond a Windows által beállított útvonalról, a használt feloldóról, és arról sem, hogy a kijárat egyáltalán továbbít-e valamit.

Négy feltétel dönti el, melyik réteg hibázott. Sorrendben végigvenni őket percek kérdése, míg a kulcsok újraírása tovább tart, és semmit sem változtat.

Előbb a réteget döntse el, csak utána nyúljon a kulcsokhoz

Három célon menjen végig, ebben a sorrendben. Kezdje egy alagút oldali címmel, aztán egy nyilvános IP-vel számként, és fejezze be egy gazdanévvel. Ahol a sor megszakad, ott neveződik meg a réteg. Az első lépés hibája az útválasztás, a másodiké a továbbítás vagy a NAT, a harmadiké a névfeloldás.

Ez a sorrend maga a módszer. Megakadályozza, hogy egy DNS-hibát törött alagútként diagnosztizáljanak, ami itt a leggyakoribb rossz irány.

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

Ha a kézfogás ideje üres

Amikor a kézfogás ideje üres, a titkosított csere soha nem fejeződött be. A hiba tehát az útválasztás előtt van. Nézze meg először a végpont címét és portját, aztán hogy a hálózat szűri-e az UDP-t. Az a szolgáltató, amely eldobja a WireGuard-forgalmat, pontosan ezt okozza, és az a kliens is, amely régi profilból másolt végpontot.

A kimenő bájtok bejövő nélkül más eset. Ez NAT-ra vagy arra a tűzfalra utal, amely rossz helyre küldi vissza a forgalmat.

Ha az útvonal alulmarad a fizikai adapterrel szemben

Teljes alagútnál a társ szakasznak le kell fednie azokat a célokat, amelyeket használni kíván. A Windows néha megtartja a fizikai adapter alapértelmezett útvonalát akkor is, ha mindenre kiterjedő szabály van beállítva. A mindenre kiterjedő szabály felosztása 0.0.0.0/1 és 128.0.0.0/1 részekre két konkrétabb előtagot hoz létre, amelyek megnyerik a keresést. A felosztás dokumentált kerülőút, nem preferencia.

Erősítse meg route print-mal vagy egy nyilvános cím lekérdezésével. A választott interfésznek az alagút adapterének kell lennie. Ha a fizikai továbbra is nyer, javítsa a társ tartományait, mielőtt a szerverhez nyúl.

Ha a címek működnek és a nevek nem

A WireGuard IP-csomagokat szállít, és nincs véleménye a DNS-ről. Tegyen DNS = sort az interfész szakaszba, vagy állítsa be az adaptert Windowson keresztül. Enélkül a címre küldött ping sikerül, miközben minden gazdanév meghiúsul, és a felhasználók ezt internet hiányaként jelentik.

Ellenőrizze, mely szervereket használ a Windows valójában csatlakozás után. A fizikai adapteren maradt feloldó részleges hibát magyaráz, amikor egyes nevek feloldódnak, mások nem. Tisztítsa ki, ahelyett hogy egy másodikat tenne rá.

Ha a Windows gép a kijárat

Az Internet Connection Sharing átírja a címzést, ha be van kapcsolva, ami a megosztott adaptert más tartományba viheti. Az eredeti címre mutató kliens ekkor működésképtelenné válik. A ScopeAddress és StandaloneDHCPAddress beállításjegyzék-értékek szabályozzák ezt a tartományt, és a beállítás újraindítás után visszaállhat.

Két további, Windows-specifikus ütközés is érdemes egy pillantásra. A Routing and Remote Access szolgáltatás zavarhatja az alagutat. A rossz architektúrára épített telepítő olyan üzenettel hiúsul meg, amely soha nem említi az architektúrát.

Javítsa a teszt által megnevezett réteget, majd futtassa újra ugyanazt a három célt. Az a változtatás, amely kijavítja a gazdanév-tesztet, de elrontja az alagút címét, rossz rétegen lett alkalmazva.