SSH na veřejnou IP adresu serveru WireGuard ve Windows selhává

Tunely, které se zvednou, zatímco SSH na veřejnou adresu serveru přestane fungovat, vypadají jako server, který odmítá spojení. Ve Windows je pravděpodobnější příčina místní: AllowedIPs plného tunelu s /0 zapne restriktivní pravidla firewallu, která povolí vlastní transport tunelu a jen velmi málo dalšího. Šifrované pakety, které na tuto adresu dorazí, nic neříkají o tom, zda smí samostatné TCP spojení na stejnou adresu odejít.

Oddělte veřejnou adresu koncového bodu od jeho vnitřní adresy tunelu, než se dotknete seznamu peerů. Téměř každý pokus opravit to úpravou AllowedIPs udělá politiku slabší, nikoli trasu správnou.

Povolení směrování a povolení firewallu jsou různé věci

Trasa rozhoduje, kam se paket odešle, a pravidlo firewallu rozhoduje, zda smí být odeslán vůbec. Přidání trasy pro veřejnou IP koncového bodu proto vytvoří cestu, kterou filtr stále může zablokovat, a přesně tento zmatek tento symptom vytváří. Ve Windows je filtr součástí implementace, nikoli doplňkem, takže jej žádný záznam trasy nezmění. Obě rozhodnutí jsou oddělená i jinde, i když se výchozí hodnoty liší.

Proto může traceroute ke koncovému bodu uspět, zatímco pokus o SSH selže. První nese služba, která výjimku vlastní, druhý ne.

Co /0 ve Windows dělá

Když jeden peer má povolené adresy pokrývající celý prostor IPv4, WireGuard for Windows uplatní restriktivní postoj firewallu, který blokuje provoz, jenž by jinak odešel mimo tunel. Vlastní transport služby tunelu je povolen, protože bez toho by VPN nemohla fungovat. Jiná aplikace na stejnou veřejnou adresu takové povolení nedostane, protože výjimka patří transportu, nikoli adrese. Poznámky k síti ve Windows popisují toto chování a související ovládací prvek v editoru.

Tato pravidla jsou mechanismem za pojmem kill switch. Aktivují se tvarem konfigurace, nikoli zaškrtávacím polem s tímto názvem.

Výjimky mění model ochrany

Nahrazení /0 dvěma polovými výchozími prefixy je dokumentovaný způsob, jak zachovat široké směrování bez restriktivní sémantiky, a je to jiný model ochrany, nikoli kratší zápis. Odečtení adresy koncového bodu od povolených prefixů je další běžná obezlička, která seznam prodlužuje a také mění, která pravidla se aktivují. Ani jedno není místní úpravou s místním účinkem. Každé posouvá hranici pro každý tok na stroji, nejen pro spojení, které jste opravovali.

Tam, kde je přímé veřejné SSH skutečně potřeba, musí vlastník profilu navrhnout jak vnější trasu, tak její povolení ve firewallu, a rozhodnout, co se stane s nesouvisejícím provozem, když tunel spadne. Samostatné posouzení IPv4 a IPv6 k tomu patří, protože pravidla se vyjadřují po rodinách. Široká obezlička přidaná na záchranu jedné řídicí relace obvykle vystaví víc než tu relaci.

Otestujte zvolenou řídicí cestu

Nejprve rozhodněte, zda má správa cestovat uvnitř tunelu, nebo mimo něj, a pak otestujte tuto volbu, nikoli obě najednou. Níže uvedené příkazy kontrolují adresy klienta, stav peeru a spojení na každý cíl. Spusťte je z klienta Windows, dokud je tunel zvednutý.

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

Úspěšné SSH na vnitřní adresu dokazuje, že tunel přenáší řídicí provoz a že vlastní firewall serveru jej z rozsahu peerů přijímá. Selhání na obou cílech je problém na straně serveru nebo s klíčem, nikoli problém směrování ve Windows. Pokud vnitřní adresa funguje a vnější ne, místní postoj firewallu dělá přesně to, k čemu byl navržen. Přečtěte si tři výsledky v tomto pořadí, než začnete profil upravovat.

Zapište řídicí cestu, použitou adresu a chování při výpadku tunelu. Právě tato poznámka brání dalšímu člověku rozšířit obezličku, aby ušetřil pět minut.