SSH na javni IP naslov strežnika WireGuard v Windows ne uspe

Tuneli, ki se dvignejo, medtem ko SSH na javni naslov strežnika preneha delovati, izgledajo kot strežnik, ki zavrača povezavo. V Windows je verjetnejši vzrok lokalen: AllowedIPs polnega tunela z /0 vklopi omejitvena pravila požarnega zidu, ki dovolijo lastni prenos tunela in zelo malo drugega. Šifrirani paketi, ki dosežejo ta naslov, ne povedo ničesar o tem, ali sme ločena povezava TCP na isti naslov oditi.

Ločite javni naslov končne točke od njenega notranjega naslova tunela, preden se dotaknete seznama peerov. Skoraj vsak poskus, da bi to popravili z urejanjem AllowedIPs, naredi politiko šibkejšo, ne poti pravilne.

Dovoljenje za usmerjanje in dovoljenje požarnega zidu sta različna

Pot odloča, kam bi bil paket poslan, pravilo požarnega zidu pa odloča, ali se sme sploh poslati. Zato dodajanje poti za javni IP končne točke ustvari pot, ki jo filter lahko še vedno blokira, in prav ta zmeda nastane zaradi tega simptoma. V Windows je filter del izvedbe in ne dodatek, zato ga noben vnos poti ne spremeni. Odločitvi sta ločeni tudi drugje, čeprav se privzete vrednosti razlikujejo.

Zato lahko traceroute do končne točke uspe, medtem ko poskus SSH ne uspe. Prvega nosi storitev, ki ima izjemo, drugega ne.

Kaj /0 počne v Windows

Ko ima en peer dovoljene naslove, ki pokrivajo celoten prostor IPv4, WireGuard for Windows uporabi omejitveno držo požarnega zidu, ki blokira promet, ki bi sicer odšel zunaj tunela. Lastni prenos storitve tunela je dovoljen, ker VPN sicer ne bi mogel delovati. Druga aplikacija na isti javni naslov takega dovoljenja ne prejme, saj izjema pripada prenosu in ne naslovu. Opombe o omrežju Windows opisujejo to vedenje in povezani nadzor v urejevalniku.

Ta pravila so mehanizem za izrazom kill switch. Aktivirajo se z obliko konfiguracije in ne s potrditvenim poljem s tem imenom.

Izjeme spremenijo model zaščite

Zamenjava /0 z dvema pollprivzetima predponama je dokumentiran način, kako ohraniti široko usmerjanje brez omejitvene semantike, in je drugačen model zaščite, ne krajši zapis. Odštevanje naslova končne točke od dovoljenih predpon je druga pogosta rešitev, ki podaljša seznam in tudi spremeni, katera pravila se aktivirajo. Nobeno ni lokalna sprememba z lokalnim učinkom. Vsako premakne mejo za vsak tok na stroju, ne le za povezavo, ki ste jo popravljali.

Kjer je neposreden javni SSH res potreben, mora lastnik profila oblikovati tako zunanjo pot kot njeno dovoljenje v požarnem zidu in se odločiti, kaj se zgodi z nepovezanim prometom, ko tunel pade. Ločen pregled IPv4 in IPv6 je del tega, saj so pravila izražena po družini. Široka obvoznica, dodana za rešitev ene seje upravljanja, običajno razkrije več kot ta seja.

Preizkusite izbrano pot upravljanja

Najprej se odločite, ali naj upravljanje potuje znotraj tunela ali zunaj njega, nato preizkusite to izbiro, ne obeh hkrati. Spodnji ukazi preverijo naslove odjemalca, stanje peera in povezavo do vsakega cilja. Zaženite jih z odjemalca Windows, medtem ko je tunel dvignjen.

ipconfig | findstr /i "WireGuard IPv4"
wg show
ssh -v [email protected]
Test-NetConnection 203.0.113.9 -Port 22

Uspešen SSH na notranji naslov dokazuje, da tunel prenaša promet upravljanja in da lastni požarni zid strežnika sprejema ta promet iz obsega peerov. Neuspeh na obeh ciljih je težava na strani strežnika ali s ključem, ne težava usmerjanja v Windows. Če notranji naslov deluje, zunanji pa ne, lokalna drža požarnega zidu počne natanko to, za kar je bila zasnovana. Preberite tri rezultate v tem vrstnem redu, preden uredite profil.

Zapišite pot upravljanja, uporabljeni naslov in vedenje, ko je tunel spuščen. Prav ta zapis prepreči naslednji osebi, da bi razširila obvoznico, da bi prihranila pet minut.