SSH do publicznego IP serwera WireGuard nie działa w Windows

Tunele, które wstają, gdy SSH do publicznego adresu serwera przestaje działać, wyglądają jak serwer odrzucający połączenie. W Windows bardziej prawdopodobna przyczyna jest lokalna: AllowedIPs pełnego tunelu o wartości /0 włącza restrykcyjne reguły zapory, które pozwalają na własny transport tunelu i bardzo niewiele więcej. Zaszyfrowane pakiety docierające do tego adresu nie mówią nic o tym, czy osobne połączenie TCP do tego samego adresu może wyjść.

Oddziel publiczny adres punktu końcowego od jego wewnętrznego adresu tunelu, zanim dotkniesz listy peerów. Niemal każda próba naprawienia tego przez edycję AllowedIPs osłabia politykę zamiast czynić trasę poprawną.

Uprawnienie routingu i uprawnienie zapory to różne rzeczy

Trasa decyduje, dokąd pakiet zostałby wysłany, a reguła zapory decyduje, czy w ogóle może zostać wysłany. Dodanie trasy dla publicznego IP punktu końcowego daje więc ścieżkę, którą filtr nadal może zablokować, i dokładnie tę niejasność tworzy ten objaw. W Windows filtr jest częścią implementacji, a nie dodatkiem, więc żaden wpis trasy go nie zmienia. Obie decyzje są rozdzielone także gdzie indziej, choć wartości domyślne się różnią.

Dlatego traceroute do punktu końcowego może się powieść, gdy próba SSH zawodzi. Pierwszy niesie usługa, do której należy wyjątek, drugiej nie.

Co robi /0 w Windows

Gdy jeden peer ma dozwolone adresy obejmujące całą przestrzeń IPv4, WireGuard for Windows stosuje restrykcyjną postawę zapory, która blokuje ruch, który inaczej wyszedłby poza tunel. Własny transport usługi tunelu jest dozwolony, ponieważ VPN inaczej nie mógłby działać. Inna aplikacja do tego samego publicznego adresu nie otrzymuje takiego pozwolenia, bo wyjątek należy do transportu, a nie do adresu. Uwagi sieciowe Windows opisują to zachowanie i powiązaną kontrolkę w edytorze.

Te reguły są mechanizmem stojącym za określeniem kill switch. Są aktywowane kształtem konfiguracji, a nie polem wyboru o tej nazwie.

Wyjątki zmieniają model ochrony

Zastąpienie /0 dwoma półdomyślnymi prefiksami to udokumentowany sposób zachowania szerokiego routingu bez restrykcyjnej semantyki, i jest to inny model ochrony, a nie krótszy zapis. Odjęcie adresu punktu końcowego od dozwolonych prefiksów to inne częste obejście, które wydłuża listę i zmienia też, które reguły się aktywują. Żadne z nich nie jest lokalną zmianą o lokalnym efekcie. Każde przesuwa granicę dla każdego przepływu na maszynie, nie tylko dla połączenia, które naprawiałeś.

Tam, gdzie bezpośredni publiczny SSH jest naprawdę potrzebny, właściciel profilu musi zaprojektować zarówno trasę zewnętrzną, jak i jej uprawnienie w zaporze, oraz zdecydować, co dzieje się z niepowiązanym ruchem, gdy tunel padnie. Osobne przejrzenie IPv4 i IPv6 też się w to wlicza, ponieważ reguły są wyrażane per rodzina. Szerokie obejście dodane, by uratować jedną sesję zarządzania, zwykle odsłania więcej niż ta sesja.

Przetestuj wybraną ścieżkę zarządzania

Najpierw zdecyduj, czy zarządzanie ma podróżować wewnątrz tunelu, czy poza nim, a potem przetestuj ten wybór, a nie oba naraz. Poniższe polecenia sprawdzają adresy klienta, stan peera i połączenie z każdym celem. Uruchom je z klienta Windows, gdy tunel jest podniesiony.

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

Udane SSH do adresu wewnętrznego dowodzi, że tunel przenosi ruch zarządzania i że własna zapora serwera przyjmuje go z zakresu peerów. Niepowodzenie na obu celach to problem po stronie serwera lub klucza, a nie routingu Windows. Jeśli adres wewnętrzny działa, a zewnętrzny nie, lokalna postawa zapory robi dokładnie to, do czego została zaprojektowana. Przeczytaj trzy wyniki w tej kolejności, zanim zmienisz profil.

Zapisz ścieżkę zarządzania, użyty adres i zachowanie, gdy tunel jest wyłączony. To ta notatka powstrzymuje następną osobę przed poszerzeniem obejścia, by zaoszczędzić pięć minut.