Handshake bai, internet ez: zer konpondu lehenengo Windows 11n

Handshake batek UDP trukea ondo joan zela frogatzen du soilik. Erabaki zein geruza huts egin duen: Windows-ek jarritako bidea, erabiltzen duen resolver-a edo irteera.

Askotan Windows 11n azken handshake-ak ezer irekitzen ez duten nabigatzaileen ondoan egoten dira. Handshake-ak soilik frogatzen du parearekin UDP trukea amaitu zela. Ez du ezer esaten Windows-ek jarritako bideaz, erabiltzen duen resolver-az, ezta irteerak ezer birbidaltzen duen ere.

Lau baldintzak erabakitzen dute zein geruzak huts egin duen. Horiek ordenan lantzeak minutu batzuk hartzen ditu, gakoak berridazteak, berriz, denbora gehiago eta ez du ezer aldatzen.

Erabaki geruza gakoak ukitu aurretik

Joan hiru helmugatatik, ordena honetan. Hasi tunelaren aldeko helbide batekin, gero IP publiko bat zenbaki gisa, eta amaitu ostalari-izen batekin. Katea non hausten den, han izendatzen da geruza. Lehen urratseko hutsa bideratzea da, bigarrenean birbidaltzea edo NAT, eta hirugarrenean izenen ebazpena.

Ordena hori da metodo osoa. DNS hutsegite bat tunel hautsi gisa diagnostikatzea eragozten du, eta hori da hemen ohikoena den norabide okerra.

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

Handshake denbora hutsik badago

Handshake denbora hutsik dagoenean, zifratutako trukea ez zen inoiz amaitu. Beraz, hutsegitea bideratzea baino lehenago dago. Begiratu lehenik muturreko helbidea eta ataka, gero sareak UDP iragazten duen. WireGuard trafikoa botatzen duen ostalari-hornitzaileak zehazki hau eragiten du, eta profila zahar batetik muturra kopiatu duen bezeroak ere bai.

Irten eta inor sartzen ez diren byteak beste kasu bat dira. Hori NAT-era edo trafikoa leku okerrean itzultzen duen suebaki batera bideratzen da.

Bidea egokigailu fisikoaren aurka galtzen bada

Tunel oso baterako, parearen atalak erabili nahi dituzun helmugak estali behar ditu. Windows-ek batzuetan egokigailu fisikoaren bide lehenetsia mantentzen du, dena hartzen duen araua ezarrita egon arren. Dena hartzen duen araua 0.0.0.0/1 gehi 128.0.0.0/1 banatzeak bilaketan irabazten duten bi aurrizki zehatzago sortzen ditu. Banaketa dokumentatutako inguru-bidea da, ez lehentasuna.

Egiaztatu route print erabiliz edo helbide publiko baten kontsultarekin. Aukeratutako interfazea tunelaren egokigailua izan beharko litzateke. Fisikoak oraindik irabazten badu, zuzendu parearen barrutiak zerbitzaria ukitu aurretik.

Helbideek funtzionatzen badute eta izenek huts egiten badute

WireGuard-ek IP paketeak daramatza eta ez du DNS-ari buruzko iritzirik. Jarri DNS = lerro bat interfazearen atalean, edo ezarri egokigailua Windows-etik. Hori gabe, helbide bidezko ping-ak ondo doaz, ostalari-izen guztiek huts egiten duten bitartean, eta erabiltzaileek internetik ez dagoela jakinarazten dute.

Egiaztatu Windows-ek konektatu ondoren benetan zein zerbitzari erabiltzen dituen. Egokigailu fisikoan geratutako resolver batek hutsegite partziala azaltzen du, non izen batzuk ebazten diren eta beste batzuk ez. Garbitu ezazu gainean bigarren bat erantsi beharrean.

Windows makina irteera bada

Internet Connection Sharing-ek helbideratzea berridazten du gaituta dagoenean, eta horrek partekatutako egokigailua beste barruti batera eraman dezake. Jatorrizko helbidera oraindik seinalatzen duen bezeroak funtzionatzeari uzten dio orduan. Erregistroko ScopeAddress eta StandaloneDHCPAddress balioek barruti hori kontrolatzen dute, eta ezarpena berrabiaraztean atzera daiteke.

Windows-eko beste bi gatazka begiratzeko merezi dute. Routing and Remote Access zerbitzuak tunela oztopa dezake. Arkitektura okerreko instalatzaile batek arkitektura inoiz aipatzen ez duen mezu batekin egiten du huts.

Konpondu probak izendatu duen geruza, eta gero exekutatu hiru helmuga berak. Ostalari-izenaren proba konpondu baina tunelaren helbidea apurtzen duen aldaketa geruza okerrean aplikatu da.

Erlazionatutako artikuluak