Tunely, ktoré sa zdvihnú, kým SSH na verejnú adresu servera prestane fungovať, vyzerajú ako server, ktorý odmieta spojenie. Vo Windows je pravdepodobnejšia príčina lokálna: AllowedIPs plného tunela s /0 zapne reštriktívne pravidlá firewallu, ktoré povolia vlastný transport tunela a veľmi málo iného. Šifrované pakety, ktoré dorazia na túto adresu, nič nehovoria o tom, či smie samostatné TCP spojenie na tú istú adresu odísť.

Oddeľte verejnú adresu koncového bodu od jeho vnútornej adresy tunela, skôr než sa dotknete zoznamu peerov. Takmer každý pokus opraviť to úpravou AllowedIPs robí politiku slabšou, nie trasu správnou.

Povolenie smerovania a povolenie firewallu sú rozdielne

Trasa rozhoduje, kam sa paket odošle, a pravidlo firewallu rozhoduje, či sa smie odoslať vôbec. Preto pridanie trasy pre verejnú IP koncového bodu vytvorí cestu, ktorú filter stále môže zablokovať, a presne tento zmätok tento príznak vytvára. Vo Windows je filter súčasťou implementácie, nie doplnkom, takže ho nemení žiadny záznam trasy. Obe rozhodnutia sú oddelené aj inde, hoci predvolené hodnoty sa líšia.

Preto môže traceroute ku koncovému bodu uspieť, kým pokus o SSH zlyhá. Prvý nesie služba, ktorá výnimku vlastní, druhý nie.

Čo robí /0 vo Windows

Keď jeden peer má povolené adresy pokrývajúce celý priestor IPv4, WireGuard for Windows uplatní reštriktívny postoj firewallu, ktorý blokuje prevádzku, ktorá by inak odišla mimo tunela. Vlastný transport služby tunela je povolený, pretože bez toho by VPN nemohla fungovať. Iná aplikácia na tú istú verejnú adresu také povolenie nedostane, keďže výnimka patrí transportu, nie adrese. Poznámky k sieti vo Windows opisujú toto správanie a súvisiaci ovládací prvok v editore.

Tieto pravidlá sú mechanizmom za pojmom kill switch. Aktivujú sa tvarom konfigurácie, nie zaškrtávacím poľom s týmto názvom.

Výnimky menia model ochrany

Nahradenie /0 dvoma polopredvolenými prefixami je dokumentovaný spôsob, ako zachovať široké smerovanie bez reštriktívnej sémantiky, a je to iný model ochrany, nie kratší zápis. Odčítanie adresy koncového bodu od povolených prefixov je ďalšia bežná obchádzka, ktorá predlžuje zoznam a tiež mení, ktoré pravidlá sa aktivujú. Ani jedno nie je lokálna úprava s lokálnym účinkom. Každé posúva hranicu pre každý tok na stroji, nielen pre spojenie, ktoré ste opravovali.

Tam, kde je priame verejné SSH skutočne potrebné, musí vlastník profilu navrhnúť tak vonkajšiu trasu, ako aj jej povolenie vo firewalle, a rozhodnúť, čo sa stane s nesúvisiacou prevádzkou, keď tunel padne. Samostatné posúdenie IPv4 a IPv6 k tomu patrí, keďže pravidlá sa vyjadrujú po rodinách. Široká obchádzka pridaná na záchranu jednej riadiacej relácie zvyčajne odhalí viac než tá relácia.

Otestujte zvolenú riadiacu cestu

Najprv rozhodnite, či má správa cestovať vnútri tunela alebo mimo neho, a potom otestujte túto voľbu, nie obe naraz. Nižšie uvedené príkazy kontrolujú adresy klienta, stav peera a spojenie na každý cieľ. Spustite ich z klienta Windows, kým je tunel zdvihnutý.

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

Úspešné SSH na vnútornú adresu dokazuje, že tunel prenáša riadiacu prevádzku a že vlastný firewall servera ju prijíma z rozsahu peerov. Zlyhanie na oboch cieľoch je problém na strane servera alebo s kľúčom, nie problém smerovania vo Windows. Ak vnútorná adresa funguje a vonkajšia nie, lokálny postoj firewallu robí presne to, na čo bol navrhnutý. Prečítajte si tri výsledky v tomto poradí, skôr než začnete profil upravovať.

Zapíšte si riadiacu cestu, použitú adresu a správanie pri vypnutom tuneli. Práve táto poznámka bráni ďalšiemu človeku rozšíriť obchádzku, aby ušetril päť minút.

Súvisiace články