Który ruch aplikacji naprawdę niesie przekierowanie SSH?

Terminal się łączy, znak zachęty się pojawia i wszyscy się zgadzają, że dostęp SSH działa. Potem klient bazy danych na laptopie nadal nie dociera do prywatnego hosta, a wina spada na sesję. Zbudowano powłokę, a to jeden z czterech dość różnych interfejsów, jakie SSH może zaproponować. Najpierw nazwij interfejs, potem sprawdź, czy aplikacja rzeczywiście go używa. Kolejność ma znaczenie, bo każdy interfejs zawodzi na swój sposób.

Nazwij interfejs, zanim cokolwiek porównasz

podręcznik klienta OpenSSH wyróżnia cztery mechanizmy, które łatwo pomylić. Powłoka lub polecenie zdalne wykonuje się na hoście SSH. Przekierowanie lokalne otwiera nasłuchujące gniazdo na kliencie i wykonuje dalsze połączenie od strony zdalnej. Przekierowanie zdalne robi odwrotnie, nasłuchując po stronie serwera. Przekierowanie dynamiczne udostępnia punkt końcowy SOCKS programom, które wiedzą, jak go użyć.

• Powłoka: program działa na zdalnej maszynie, lokalnie nic nie nasłuchuje.
• Przekierowanie lokalne: Twój laptop ma port, zdalny host wykonuje połączenie wychodzące.
• Przekierowanie zdalne: strona zdalna ma port, ruch wraca w Twoją stronę.
• Dynamiczne: serwer proxy SOCKS na kliencie, używany tylko przez aplikacje rozumiejące proxy.

Żadne z nich nie instaluje trasy. Program, który ignoruje ustawienia proxy, albo mówi UDP, albo sam rozwiązuje nazwy, nie jest objęty działaniem aktywnej sesji SSH. To nie błąd SSH; to zakres interfejsu, który wybrałeś.

Przekierowania lokalne, zdalne i dynamiczne różnią się tym, kto nasłuchuje

Różnica, która rozstrzyga większość przypadków, to kto posiada nasłuchujące gniazdo. Przy przekierowaniu lokalnym klient nasłuchuje, a zdalny koniec wybiera cel, dlatego adres celu jest rozwiązywany z punktu widzenia serwera. Przy przekierowaniu zdalnym serwer nasłuchuje, a połączenie jest przenoszone z powrotem na Twoją stronę, i tak udostępniasz usługę lokalną bez publikowania jej bezpośrednio.

ssh -N -L 5432:db.internal.example:5432 [email protected]
ssh -N -D 1080 [email protected]
ss -ltnp | grep -E '5432|1080'

Pierwsze polecenie wiąże port 5432 na laptopie i przekierowuje go do bazy danych tak, jak jest widoczna z bastionu. Drugie tworzy proxy SOCKS na porcie 1080. Trzecie polecenie potwierdza, które procesy naprawdę nasłuchują, i to jedyny dowód, że przekierowanie istnieje, a nie zawiodło cicho z powodu konfliktu portów.

Przekierowanie dynamiczne zasługuje na własne ostrzeżenie: obejmuje tylko aplikacje, które respektują SOCKS. Przeglądarkę można na nie skierować, narzędziu wiersza poleceń można kazać go użyć, ale sterownik bazy danych z własnym stosem połączeń zwykle nie może. Założenie, że każdy program na maszynie używa teraz tunelu, to najczęstszy błąd w całej tej dziedzinie.

Tryb urządzenia tunelowego to jedyny prawdziwy wyjątek sieciowy

OpenSSH obsługuje też przekierowanie urządzenia tunelowego -w, które przekazuje interfejs punkt-punkt zamiast nasłuchu TCP. To prawdziwy tunel sieciowy i jest konfigurowany świadomie, a nie jako efekt uboczny otwarcia powłoki.

sudo ssh -w 0:0 [email protected]
ip addr show tun0

Wymaga odpowiednich numerów interfejsów dostępnych na obu końcach, właściwej konfiguracji na serwerze i wystarczających uprawnień na kliencie do utworzenia urządzenia. Wymaga też planu adresacji i routingu, bo goły interfejs nie niesie żadnej polityki co do tego, które cele powinny go używać.

Nawet wtedy tunel kończy się na zdalnym hoście. Jakakolwiek ochrona zapewniona przez transport SSH kończy się tam, a dalsze połączenie to osobny skok. Brama VPN ma taki sam kształt granicy, dlatego porównanie powinno dotyczyć zakresu i zakończenia, a nie tego, które narzędzie jest silniejsze. Głośne nazwanie tej granicy rozstrzyga też spór o to, czy tunel «szyfruje wszystko», bo wyraźnie nie szyfruje.

Sprawdź, czy Twoja aplikacja używa interfejsu, który zbudowałeś

Weryfikacja jest dla każdej aplikacji, nie dla sesji. Działające przekierowanie dowodzi, że port jest związany i zdalna strona może wybrać numer; nie dowodzi, że program, na którym Ci zależy, połączył się przez nie.

curl -sS --socks5-hostname 127.0.0.1:1080 -o /dev/null -w '%{http_code}\n' https://app.internal.example/health
psql "host=127.0.0.1 port=5432 dbname=app sslmode=require" -c 'select 1'

Pierwsze polecenie wysyła żądanie przez punkt końcowy SOCKS z nazwą hosta rozwiązaną zdalnie, a drugie ćwiczy przekierowany port bazy danych przy nadal wymaganym TLS. Uruchom te same testy z zatrzymanym przekierowaniem, aby potwierdzić, że zawodzą, bo test, który przechodzi w obie strony, nigdy nie używał tunelu.

Potem porównaj z rutowanym VPN tylko w wymiarach, które mają znaczenie: jakie cele są objęte, jakie protokoły działają, gdzie kończy się ochrona i kto musi zatwierdzić dostęp. Przekierowanie jednej usługi może być węższą i lepszą odpowiedzią, podczas gdy VPN jest właściwą formą, gdy wiele aplikacji potrzebuje tej samej ścieżki sieciowej. Żadne z nich nie daje wszystkiego, co osiągalne z jego zdalnego punktu końcowego.