Handshake jes, interreto ne: kion unue ripari en Windows 11

Ofte en Windows 11 freŝaj handshake-oj staras apud retumiloj, kiuj malfermas nenion. La handshake pruvas nur, ke la UDP-interŝanĝo kun la samtavolano finiĝis. Ĝi diras nenion pri la itinero, kiun Windows instalis, pri la solvilo, kiun ĝi uzas, nek pri ĉu la eliro entute plusendas ion.

Kvar kondiĉoj decidas, kiu el tiuj tavoloj fiaskis. Trapasi ilin laŭ ordo daŭras minutojn, dum reverki ŝlosilojn daŭras pli longe kaj ŝanĝas nenion.

Decidu la tavolon antaŭ ol tuŝi la ŝlosilojn

Trapasu tri celojn en ĉi tiu sinsekvo. Komencu per adreso ĉe la tunela flanko, poste publika IP kiel numero, kaj finu per gastigantnomo. Kie la sinsekvo rompiĝas, tie nomiĝas la tavolo. Malsukceso ĉe la unua paŝo estas enkursigado, ĉe la dua ĝi estas plusendado aŭ NAT, kaj ĉe la tria ĝi estas nomtraktado.

Tiu ordo estas la tuta metodo. Ĝi malhelpas, ke DNS-difekto estu diagnozita kiel rompita tunelo, kio estas la plej ofta malĝusta turno ĉi tie.

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

Se la handshake-tempo estas malplena

Kiam la handshake-tempo estas malplena, la ĉifrita interŝanĝo neniam finiĝis. Do la difekto sidas pli frue ol enkursigado. Rigardu unue la finpunkton kaj la pordon, poste ĉu la reto filtradas UDP. Gastigprovizanto, kiu forĵetas WireGuard-trafikon, produktas ĝuste tion, kaj same faras kliento, kiu kopiis finpunkton el malnova profilo.

Bajtoj, kiuj eliras sen ke iu eniras, estas alia kazo. Tio montras al NAT aŭ fajroŝirmilo, kiu resendas trafikon al la malĝusta loko.

Se la itinero perdas kontraŭ la fizika adaptilo

Por plena tunelo la sekcio pri samtavolano devas kovri la celojn, kiujn vi intencas uzi. Windows foje konservas la defaŭltan itineron de la fizika adaptilo eĉ kun ĉionampleksa regulo agordita. Dividi la ĉionampleksan regulon en 0.0.0.0/1 plus 128.0.0.0/1 kreas du pli specifajn prefiksojn, kiuj gajnas la serĉon. La divido estas dokumentita provizora solvo, ne prefero.

Konfirmu per route print aŭ per serĉo de publika adreso. La elektita interfaco devus esti la tunela adaptilo. Se la fizika ankoraŭ gajnas, riparu la gamojn de la samtavolano antaŭ ol tuŝi la servilon.

Se adresoj funkcias kaj nomoj fiaskas

WireGuard portas IP-paketojn kaj havas neniun opinion pri DNS. Metu linion DNS = en la sekcion pri interfaco, aŭ agordu la adaptilon per Windows. Sen ĝi ping per adreso sukcesas dum ĉiu gastigantnomo fiaskas, kaj uzantoj raportas tion kiel mankon de interreto.

Kontrolu, kiujn servilojn Windows fakte uzas post konekto. Restinta solvilo sur la fizika adaptilo klarigas partan malsukceson, kie iuj nomoj solviĝas kaj aliaj ne. Forigu ĝin anstataŭ aldoni duan supre.

Se la Windows-maŝino estas la eliro

Internet Connection Sharing reverkas adresadon kiam ĝi estas ŝaltita, kio povas movi la kunhavigitan adaptilon al alia gamo. Kliento, kiu ankoraŭ montras al la originala adreso, tiam ĉesas funkcii. La registraj valoroj ScopeAddress kaj StandaloneDHCPAddress regas tiun gamon, kaj la agordo povas reiri post restarto.

Du aliaj Windows-specifaj konfliktoj indas rigardon. La servo Routing and Remote Access povas ĝeni la tunelon. Instalilo konstruita por malĝusta arkitekturo fiaskas per mesaĝo, kiu neniam mencias arkitekturon.

Riparu la tavolon, kiun la testo nomis, poste relanĉu la samajn tri celojn. Ŝanĝo, kiu riparas la gastigantnoman teston sed rompas la tunelan adreson, estis aplikita al la malĝusta tavolo.