May handshake, walang internet: ano ang unang ayusin sa Windows 11

Sa Windows 11, ang mga bagong handshake ay madalas nakatayo sa tabi ng mga browser na walang binubuksan. Ang handshake ay nagpapatunay lamang na natapos ang palitan ng UDP sa peer. Wala itong sinasabi tungkol sa rutang inilagay ng Windows, sa resolver na ginagamit nito, o sa kung may ipinapasa ba ang labasan.

Apat na kondisyon ang nagpapasya kung alin sa mga layer na iyon ang nabigo. Ang pagsunod sa kanila nang sunud-sunod ay tumatagal ng minuto, samantalang ang muling pagsulat ng mga key ay tumatagal ng mas matagal at walang binabago.

Pasyaan ang layer bago hipuin ang mga key

Daanan ang tatlong destinasyon, sa ayos na ito. Magsimula sa isang address sa gilid ng tunnel, pagkatapos ay isang pampublikong IP bilang numero, at tapusin sa isang hostname. Kung saan mapuputol ang kadena, doon pinangalanan ang layer. Ang pagpalya sa unang hakbang ay routing, sa ikalawa ay pagpapasa o NAT, at sa ikatlo ay paglutas ng pangalan.

Ang ayos na iyon ang buong paraan. Pinipigilan nito ang isang sira ng DNS na ma-diagnose bilang sirang tunnel, na siyang pinakakaraniwang maling liko dito.

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

Kung walang laman ang oras ng handshake

Kapag walang laman ang oras ng handshake, hindi kailanman natapos ang naka-encrypt na palitan. Kaya ang sira ay nasa mas maaga pa kaysa routing. Tingnan muna ang address ng endpoint at port, pagkatapos ay kung sinasala ng network ang UDP. Ang isang hosting provider na nagtatapon ng trapik ng WireGuard ay gumagawa ng eksaktong ito, gayundin ang isang client na kumopya ng endpoint mula sa lumang profile.

Ang mga byte na lumalabas nang walang pumapasok ay ibang kaso. Iyon ay tumuturo sa NAT o sa firewall na nagbabalik ng trapik sa maling lugar.

Kung natatalo ang ruta sa pisikal na adapter

Para sa buong tunnel, kailangang saklawin ng seksyon ng peer ang mga destinasyong inaasahan mong gamitin. Minsan hinahayaan ng Windows ang default na ruta ng pisikal na adapter kahit may nakatakdang tuntunin para sa lahat. Ang paghati ng tuntunin para sa lahat sa 0.0.0.0/1 at 128.0.0.0/1 ay lumilikha ng dalawang mas tiyak na prefix na nananalo sa paghahanap. Ang paghati ay dokumentadong solusyon, hindi kagustuhan.

Kumpirmahin gamit ang route print o isang paghahanap ng pampublikong address. Ang napiling interface ay dapat ang adapter ng tunnel. Kung nananalo pa rin ang pisikal, ayusin ang mga saklaw ng peer bago hipuin ang server.

Kung gumagana ang mga address at nabibigo ang mga pangalan

Nagdadala ang WireGuard ng mga packet ng IP at wala itong opinyon tungkol sa DNS. Maglagay ng linyang DNS = sa seksyon ng interface, o i-set ang adapter sa pamamagitan ng Windows. Kung wala iyon, nagtatagumpay ang ping sa address habang nabibigo ang bawat hostname, at iniuulat ito ng mga user bilang walang internet.

Suriin kung aling mga server ang talagang ginagamit ng Windows pagkatapos kumonekta. Ang natirang resolver sa pisikal na adapter ay nagpapaliwanag ng bahagyang pagpalya, kung saan may mga pangalang nalulutas at may hindi. Linisin ito sa halip na magdagdag ng pangalawa sa ibabaw.

Kung ang Windows machine ang labasan

Ang Internet Connection Sharing ay nagsusulat muli ng addressing kapag naka-on, na maaaring maglipat ng shared adapter sa ibang saklaw. Ang client na nakaturo pa rin sa orihinal na address ay titigil sa paggana. Ang mga halaga ng registry na ScopeAddress at StandaloneDHCPAddress ang kumokontrol sa saklaw na iyon, at ang setting ay maaaring bumalik pagkatapos ng reboot.

Dalawang iba pang salungatan na partikular sa Windows ang sulit tingnan. Ang serbisyong Routing and Remote Access ay maaaring makagambala sa tunnel. Ang installer na ginawa para sa maling arkitektura ay nabibigo sa isang mensaheng hindi kailanman binabanggit ang arkitektura.

Ayusin ang layer na pinangalanan ng test, pagkatapos ay patakbuhin muli ang parehong tatlong destinasyon. Ang pagbabagong nag-aayos sa test ng hostname ngunit sumisira sa address ng tunnel ay inilapat sa maling layer.