Tworzenie lokalnego proxy SOCKS przez SSH

Mając autoryzowany dostęp SSH do serwera, możesz utworzyć w OpenSSH lokalny nasłuch SOCKS. Połączenie SSH przenosi przekazywany ruch, a zdalny serwer nawiązuje połączenie z celem.

Nasłuch tylko na pętli zwrotnej

ssh -N -T -o ControlPath=none -o ForkAfterAuthentication=no -o ExitOnForwardFailure=yes -D 127.0.0.1:1080 [email protected]

Zastąp konto i nazwę hosta. Serwer SSH musi zezwalać na przekazywanie; administrator może ograniczyć je i cele niezależnie od logowania do konta.

-D tworzy przekazywanie dynamiczne, a jawny adres pętli zwrotnej ogranicza nasłuch do tego komputera. -N pomija zdalne polecenie; -T pomija pseudoterminal. ControlPath=none omija istniejący współdzielony proces główny, a ForkAfterAuthentication=no utrzymuje to wywołanie na pierwszym planie.

Utrzymuj proces w działaniu podczas używania proxy. Jeśli port 1080 jest zajęty, wybierz inny wolny wysoki port i zaktualizuj klienta. ExitOnForwardFailure=yes kończy SSH, jeśli nie można utworzyć nasłuchu.

Korzystanie z punktu SOCKS

curl --proxy socks5h://127.0.0.1:1080 --noproxy '' --connect-timeout 5 --max-time 15 https://example.com/

To żądanie deleguje obsługę nazwy celu przez SOCKS5. Inne aplikacje wymagają własnej konfiguracji SOCKS; pole proxy HTTP nie potrafi komunikować się protokołem SOCKS z tym nasłuchem.

Aby sprawdzić, który proces posiada port:

ss -ltnp 'sport = :1080'

Właściwy proces SSH powinien posiadać nasłuch na pętli zwrotnej. Żądanie przez niego sprawdza, czy zdalny serwer także dociera do celu. Użyj kontrolowanego celu, gdy chcesz zbadać obserwowane wyjście.

Czas życia sesji

Ctrl-C zamyka proces SSH, nasłuch i przekazywane połączenia. Zerwane połączenie SSH również wyłącza dostępność proxy.

ExitOnForwardFailure sprawdza etap tworzenia. Nie kończy SSH przy każdej późniejszej awarii połączenia z celem, więc osobno diagnozuj sesję, lokalny port i żądanie do celu.