SSH į viešąjį WireGuard serverio IP „Windows“ aplinkoje nepavyksta

Tuneliai, kurie pakyla tuo metu, kai SSH į viešąjį serverio adresą nustoja veikti, atrodo kaip serveris, atmetantis ryšį. „Windows“ aplinkoje labiau tikėtina priežastis yra vietinė: viso tunelio AllowedIPs su /0 įjungia ribojančias ugniasienės taisykles, kurios leidžia paties tunelio transportą ir labai nedaug kito. Užšifruoti paketai, pasiekiantys tą adresą, nieko nesako apie tai, ar atskiras TCP ryšys į tą patį adresą gali išeiti.

Atskirkite endpointo viešąjį adresą nuo jo vidinio tunelio adreso prieš liesdami peer sąrašą. Beveik kiekvienas bandymas tai sutvarkyti redaguojant AllowedIPs daro politiką silpnesnę, o ne maršrutą teisingą.

Maršrutizavimo leidimas ir ugniasienės leidimas skiriasi

Maršrutas nusprendžia, kur paketas bus siunčiamas, o ugniasienės taisyklė – ar jį apskritai galima siųsti. Todėl maršruto į endpointo viešąjį IP pridėjimas sukuria kelią, kurį filtras vis dar gali užblokuoti, ir būtent šią painiavą sukelia šis simptomas. „Windows“ aplinkoje filtras yra įgyvendinimo dalis, o ne priedas, todėl joks maršruto įrašas jo nepakeičia. Šie du sprendimai atskiri ir kitur, nors numatytosios reikšmės skiriasi.

Štai kodėl traceroute į endpointą gali pavykti, o SSH bandymas nepavyksta. Pirmąjį perduoda paslauga, kuriai priklauso išimtis, antrasis – ne.

Ką /0 daro „Windows“ aplinkoje

Kai vieno peer leidžiami adresai apima visą IPv4 erdvę, WireGuard for Windows taiko ribojančią ugniasienės poziciją, kuri blokuoja srautą, kuris kitu atveju išeitų už tunelio ribų. Paties tunelio paslaugos transportas leidžiamas, nes VPN kitaip negalėtų veikti. Kita programa į tą patį viešąjį adresą tokio leidimo negauna, nes išimtis priklauso transportui, o ne adresui. „Windows“ tinklo pastabos aprašo šį elgesį ir susijusį valdiklį redaktoriuje.

Tos taisyklės yra mechanizmas, slypintis už frazės kill switch. Jos įjungiamos konfigūracijos forma, o ne tokiu pavadinimu pažymėtu laukeliu.

Išimtys keičia apsaugos modelį

/0 pakeitimas dviem pusiau numatytaisiais prefiksais yra dokumentuotas būdas išlaikyti platų maršrutizavimą be ribojančios semantikos, ir tai yra kitas apsaugos modelis, o ne trumpesnė rašyba. Endpointo adreso atėmimas iš leidžiamų prefiksų yra kita įprasta išeitis, kuri pailgina sąrašą ir taip pat keičia, kurios taisyklės įsijungia. Nė vienas nėra vietinis pakeitimas su vietiniu poveikiu. Kiekvienas perkelia ribą kiekvienam įrenginio srautui, ne tik tam ryšiui, kurį taisėte.

Kai tiesioginis viešasis SSH tikrai reikalingas, profilio savininkas turi suprojektuoti ir išorinį maršrutą, ir jo ugniasienės leidimą, bei nuspręsti, kas atsitiks nesusijusiam srautui tuneliui nukritus. Atskira IPv4 ir IPv6 peržiūra taip pat tam priklauso, nes taisyklės išreiškiamos pagal šeimą. Platus apėjimas, pridėtas gelbstint vieną administravimo sesiją, paprastai atskleidžia daugiau nei sesiją.

Išbandykite pasirinktą administravimo kelią

Pirmiausia nuspręskite, ar administravimas turi eiti tunelio viduje, ar už jo, tada išbandykite būtent šį pasirinkimą, o ne abu iš karto. Toliau pateiktos komandos tikrina kliento adresus, peer būseną ir ryšį su kiekvienu tikslu. Vykdykite jas iš „Windows“ kliento, kol tunelis pakeltas.

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

Sėkmingas SSH į vidinį adresą įrodo, kad tunelis perduoda administravimo srautą ir kad paties serverio ugniasienė priima jį iš peer diapazono. Abiejų tikslų nepavykimas yra serverio pusės arba rakto problema, o ne „Windows“ maršrutizavimo. Jei vidinis adresas veikia, o išorinis ne, vietinė ugniasienės pozicija daro būtent tai, kam buvo sukurta. Perskaitykite tris rezultatus šia tvarka prieš redaguodami profilį.

Užrašykite administravimo kelią, naudotą adresą ir elgesį, kai tunelis nuleistas. Būtent ši pastaba neleidžia kitam žmogui išplėsti apėjimo, kad sutaupytų penkias minutes.