Jak lokalne przekierowanie SSH przenosi sesję TCP OpenVPN

Tutaj nakładają się trzy transporty, a każdy ma własne ramkowanie. Ładunek VPN podróżuje wewnątrz sesji TLS, ta sesja TLS podróżuje wewnątrz połączenia TCP do portu loopback, a bajty tego połączenia podróżują wewnątrz SSH do hosta relay, który otwiera prawdziwe połączenie TCP do nasłuchu VPN. Nic w tym układzie nie zmienia tego, co OpenVPN uwierzytelnia, i nic w nim nie czyni nasłuchu UDP osiągalnym przez TCP. Resztę czytaj jako opis ścieżki bajtów, a nie przepis na obejście kontroli sieciowej.

Co lokalne przekierowanie naprawdę przenosi

Klient SSH nasłuchuje na lokalnym porcie. Gdy lokalny proces się łączy, klient pakuje bajty w swój szyfrowany kanał, a strona serwera otwiera nowe połączenie TCP do celu wskazanego w żądaniu przekierowania.

Ten cel rozwiązuje relay, a nie twoja maszyna, dlatego nazwa istniejąca tylko wewnątrz sieci zdalnej nadal działa. Oznacza to też, że relay musi móc dotrzeć do nasłuchu VPN i mieć trasę powrotną do niego. Nazwa rozwiązywana na twoim laptopie nic nie mówi o tym, co widzi relay.

Uruchomienie sesji SSH dowodzi tylko, że relay jest osiągalny i uwierzytelniony. Nie mówi, czy następny nasłuch działa, czy zapora między relay a nasłuchem przyjmuje połączenie, ani czy VPN przyjmie twój profil.

Skieruj klienta na lokalny nasłuch

Podany przykład: relay może dotrzeć do nasłuchu TCP pod gw.internal.example:443, a wysoki port lokalny udostępnia tę ścieżkę tylko tej maszynie.

ssh -N -L 127.0.0.1:24011:gw.internal.example:443 [email protected]

Podręcznik OpenSSH opisuje lokalne przekierowanie jako lokalne przyjmowanie połączeń TCP i otwieranie kolejnego połączenia po stronie zdalnej. Wiąż nasłuch z loopbackiem, a nie ze wszystkimi interfejsami, ponieważ przekierowanie osiągalne z sieci jest otwartym relay z twoim nazwiskiem. Wiązanie wieloznaczne udostępnia też port każdemu innemu lokalnemu kontu na współdzielonej maszynie.

Następnie ustaw klienta VPN w tryb TCP i skieruj go na 127.0.0.1:24011. Jeśli profil używa UDP, ten projekt nie pomoże: przekierowanie przenosi strumień bajtów i nie ma przez nie ścieżki datagramów.

Trzymaj oba uwierzytelnienia osobno

SSH uwierzytelnia host relay. OpenVPN nadal uwierzytelnia drugą stronę VPN, a cel loopback nie zmienia tego wymogu. Wyłączenie kontroli certyfikatu, bo gniazdo wskazuje teraz na localhost, to najgorszy skrót w tym projekcie. Zamienia układ transportowy na układ zaufania, a na drugi nikt się nie zgodził.

Zachowaj nienaruszone kotwicę zaufania profilu, kontrolę roli serwera i weryfikację nazwy. Jeśli twój klient porównuje nazwę serwera z adresem, do którego dzwonił, loopback może wymagać jawnego ustawienia nazwy zamiast wyłączonej kontroli, a dokumentacja profilu jest miejscem, w którym potwierdza się, które pole jest porównywane.

Traktuj relay jako drugą stronę w historii zaufania: jego administrator widzi metadane połączeń i może przekierować przekierowanie, jeśli konfiguracja się zmieni. Układ wymaga zgody zarówno relay, jak i właściciela usługi VPN, nie tylko tego, kto potrzebuje jej dziś.

Nie buduj pętli pod tunelem

Po zainstalowaniu tras przez VPN połączenie SSH, które je niesie, nadal potrzebuje ścieżki do relay, która nie przechodzi przez tunel. Jeśli trasa domyślna przejdzie na VPN, a relay jest osiągalny tylko przez ten sam tunel, transport się załamuje i VPN idzie z nim. Awaria wygląda jak zerwany tunel, a nie błąd routingu, dlatego jest źle diagnozowana.

Zwykłą poprawką jest trasa hostowa do adresu relay przypięta do interfejsu fizycznego przed podniesieniem tunelu, plus sprawdzenie, że trasa przetrwa ponowne połączenie. Sprawdź ją wyszukaniem trasy dla adresu relay, zamiast zakładać, że kolejność była prawidłowa.

Spodziewaj się też, że ten stos będzie wolniejszy i bardziej kruchy niż połączenie bezpośrednie, bo są teraz dwa uporządkowane transporty i jeszcze jeden punkt końcowy do utrzymania. To sposób przekroczenia granicy sieci, nie technika wydajności.

Zamknij nasłuch, gdy skończysz

Zatrzymaj sesję SSH, gdy tunel nie jest już potrzebny, i potwierdź, że lokalny port został zwolniony. Zapomniane przekierowanie trzyma uwierzytelnioną ścieżkę otwartą na maszynie, która może być współdzielona.

Przejrzyj też dozwolone cele przekierowania na relay, ponieważ permisywna konfiguracja zmienia każde przejęte konto w ogólny punkt zaczepienia. Zapisz port, relay i cel razem, aby następna osoba wiedziała, czemu służyło przekierowanie i czy nadal jest zatwierdzone.