Handshake po, internet jo: çfarë të rregullohet së pari në Windows 11

Në Windows 11, handshake-t e freskëta shpesh qëndrojnë pranë shfletuesve që nuk hapin asgjë. Handshake vërteton vetëm se shkëmbimi UDP me partnerin përfundoi. Ai nuk thotë asgjë për rrugën që instaloi Windows, për resolver-in që përdor, as për nëse dalja përcjell ndonjë gjë.

Katër kushte vendosin cila prej këtyre shtresave dështoi. Kalimi nëpër to me radhë merr minuta, ndërsa rishkrimi i çelësave merr më shumë kohë dhe nuk ndryshon asgjë.

Vendosni shtresën përpara se të prekni çelësat

Kaloni nëpër tre destinacione, në këtë rend. Filloni me një adresë nga ana e tunelit, pastaj një IP publike si numër, dhe përfundoni me një emër hosti. Aty ku zinxhiri thyhet, aty emërtohet shtresa. Dështimi në hapin e parë është rrugëzim, në të dytin është përcjellje ose NAT, dhe në të tretin është zgjidhje emrash.

Ky rend është e gjithë metoda. Parandalon që një defekt DNS të diagnostikohet si tunel i thyer, që është devijimi i gabuar më i zakonshëm këtu.

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

Nëse koha e handshake është bosh

Kur koha e handshake është bosh, shkëmbimi i kriptuar nuk përfundoi kurrë. Pra defekti ndodhet më herët se rrugëzimi. Shikoni së pari adresën e pikës fundore dhe portën, pastaj nëse rrjeti filtron UDP. Një ofrues hostimi që hedh trafikun WireGuard prodhon pikërisht këtë, dhe po ashtu një klient që kopjoi një pikë fundore nga një profil i vjetër.

Bajt që dalin pa hyrë asnjë janë një rast tjetër. Kjo tregon NAT ose një mur zjarri që e kthen trafikun në vendin e gabuar.

Nëse rruga humbet ndaj përshtatësit fizik

Për një tunel të plotë, seksioni i partnerit duhet të mbulojë destinacionet që prisni të përdorni. Windows ndonjëherë mban rrugën e paracaktuar të përshtatësit fizik edhe kur është vendosur një rregull gjithëpërfshirës. Ndarja e rregullit gjithëpërfshirës në 0.0.0.0/1 plus 128.0.0.0/1 krijon dy prefikse më specifikë që fitojnë kërkimin. Ndarja është një zgjidhje e dokumentuar, jo një preferencë.

Konfirmojeni me route print ose me një kërkim të një adrese publike. Ndërfaqja e zgjedhur duhet të jetë përshtatësi i tunelit. Nëse ai fizik vazhdon të fitojë, rregulloni intervalet e partnerit përpara se të prekni serverin.

Nëse adresat funksionojnë dhe emrat dështojnë

WireGuard transporton paketa IP dhe nuk ka mendim për DNS. Vendosni një rresht DNS = në seksionin e ndërfaqes, ose konfiguroni përshtatësin përmes Windows. Pa atë, ping sipas adrese funksionon ndërsa çdo emër hosti dështon, dhe përdoruesit e raportojnë si mungesë interneti.

Kontrolloni cilët serverë përdor Windows në të vërtetë pas lidhjes. Një resolver i mbetur në përshtatësin fizik shpjegon një dështim të pjesshëm, ku disa emra zgjidhen dhe të tjerë jo. Pastrojeni në vend që të shtoni një të dytë sipër.

Nëse makina Windows është dalja

Internet Connection Sharing e rishkruan adresimin kur aktivizohet, gjë që mund ta zhvendosë përshtatësin e ndarë në një interval tjetër. Një klient që vazhdon të tregojë adresën origjinale atëherë ndalon së punuari. Vlerat e regjistrit ScopeAddress dhe StandaloneDHCPAddress kontrollojnë atë interval, dhe cilësimi mund të kthehet pas një rindezjeje.

Vlen të shihen dy konflikte të tjera tipike për Windows. Shërbimi Routing and Remote Access mund të ndërhyjë në tunel. Një instalues i ndërtuar për arkitekturën e gabuar dështon me një mesazh që nuk e përmend kurrë arkitekturën.

Rregulloni shtresën që emërtoi testi, pastaj ekzekutoni përsëri të njëjtat tre destinacione. Një ndryshim që rregullon testin e emrit të hostit por thyen adresën e tunelit është aplikuar në shtresën e gabuar.