Daj zdalnemu Pi proxy SOCKS przez swojego klienta SSH

Zdalne przekierowanie dynamiczne umieszcza nasłuchiwacz SOCKS na Pi i wykonuje dalsze połączenie z zatwierdzonej ścieżki VPN laptopa. Bez drugiego serwera SSH.

Zakładasz, że proxy SOCKS musi działać tam, gdzie dostęp sieciowy już istnieje. OpenSSH potrafi umieścić nasłuchiwacz zupełnie gdzie indziej. Zdalne przekierowanie dynamiczne otwiera port SOCKS na zdalnym hoście i rozpoczyna każde połączenie z twojego lokalnego klienta SSH, który niesie zatwierdzoną ścieżkę VPN laptopa. Pi dostaje ograniczone proxy; nie dziedziczy twojego tunelu ani twoich uprawnień.

Nasłuchiwacz i strona, z której powstaje połączenie, mogą się różnić

Zwykły ssh -D 1080 uruchamia nasłuchiwacz na twojej własnej maszynie i wysyła połączenia stamtąd. Zdalne przekierowanie dynamiczne odwraca to: nasłuchiwacz pojawia się na zdalnym hoście, a każde połączenie, które przyjmie, jest otwierane po stronie lokalnej. podręcznik klienta OpenSSH dokumentuje -R bez stałego celu dokładnie jako ten układ SOCKS4/5.

Obsługiwane polecenie z laptopa wygląda tak, przy czym konto, hosty i port są traktowane jako placeholdery:

ssh -NT -S none -o ExitOnForwardFailure=yes \
  -o PermitRemoteOpen=app.corp.example:443 \
  -R 1080 [email protected]

Trzy szczegóły wykonują tam użyteczną pracę. -S none trzyma sesję z dala od współdzielonego mastera sterowania, ExitOnForwardFailure zawodzi szybko, zamiast zostawiać cię z na wpół otwartą sesją, a PermitRemoteOpen ogranicza, do czego zdalny nasłuchiwacz może dotrzeć. Użyj autoryzowanego konta Pi i zweryfikuj klucz hosta, zanim cokolwiek z tego dodasz.

Co zdalny nasłuchiwacz naprawdę eksponuje

Sprawdź politykę przekierowań serwera, zanim zaczniesz polegać na nasłuchiwaczu. Przy GatewayPorts no zdalne przekierowanie pozostaje przypisane do loopbacku, i to jest ekspozycja, której chcesz. Serwer skonfigurowany do wymuszania przekierowania wildcard publikuje ten sam port na każdym interfejsie, co zamienia osobiste proxy w coś, do czego sieć lokalna może dotrzeć.

Loopback też nie jest granicą między użytkownikami. Inny proces na Pi może połączyć się z 127.0.0.1:1080, jeśli zna port, więc lokalne konta Pi i wszystko, co na nim działa, są częścią twojego projektu dostępu. To powód, by trzymać listę celów wąską, a nie powód, by pomijać kontrolę polityki.

Trzymaj dozwolony cel konkretnie dla aplikacji, do której próbujesz dotrzeć. Zastąpienie go nieograniczonym przekierowaniem, żeby zadziałał niepowiązany program, poszerza ścieżkę daleko poza problem, od którego zacząłeś. Lista celów zapisuje też, czemu służyła sesja, co pomaga temu, kto będzie ją później audytował. Zapisz ją obok konta, którego użyłeś.

Przepuść jedną aplikację przez proxy

Klient na Pi rozumiejący proxy może wtedy wysłać żądanie. Prefiks socks5h przekazuje nazwę celu proxy, więc wyszukiwanie i połączenie odbywają się po stronie laptopa, i pasuje do nazwanego celu w PermitRemoteOpen:

curl --proxy socks5h://127.0.0.1:1080 \
  --noproxy '' https://app.corp.example/

Zachowaj normalną walidację certyfikatu i własne uwierzytelnianie aplikacji. Proxy zmienia to, gdzie powstaje połączenie TCP; nie czyni bezpieczną usługi bez uwierzytelniania i nie zamienia samo-podpisanego punktu końcowego w zaufany.

Laptop nadal potrzebuje własnej trasy i dostępu do resolvera zarówno do serwera SSH, jak i do aplikacji. Ruch jego klienta SSH musi być wybierany przez zatwierdzoną politykę VPN, a wyjątek split-tunnel może wysłać ten ruch inną trasą niż ta, którą testowałeś.

Udowodnij trasę i zamknij ją

Potwierdź, że nasłuchiwacz istnieje tam, gdzie go oczekujesz, i że odpowiada tylko zamierzony cel:

$ ss -ltnp | grep 1080
LISTEN 0 128 127.0.0.1:1080 0.0.0.0:*
$ curl -sS -o /dev/null -w '%{http_code}\n' \
    --proxy socks5h://127.0.0.1:1080 https://app.corp.example/

ExitOnForwardFailure potrafi udowodnić, że przekierowanie zostało ustanowione, a mimo to nie może poświadczyć, że logowanie do aplikacji powiedzie się dalej. Testuj aplikację, nie tylko port. Nasłuchiwacz, który przyjmuje, a potem odrzuca każde żądanie, zwykle oznacza, że nazwa celu albo trasa laptopa są błędne, a nie że tunel zawiódł.

Ten układ przenosi tylko TCP. UDP, ICMP i programy ignorujące ustawienia proxy pozostają poza nim, a przekierowanie kończy się w chwili, gdy kończy się sesja SSH. Zatrzymaj tę sesję, gdy skończysz, i usuń ustawienie proxy dodane do aplikacji.

Do stałego dostępu użyj zamiast tego wspieranej rejestracji właściciela sieci lub zarządzanej bramy. Odwrotne proxy to niewłaściwe narzędzie do omijania ograniczeń VPN dotyczących urządzeń lub zasobów; użyte w ich wnętrzu jest po prostu jedną autoryzowaną ścieżką aplikacji z wyraźnymi granicami.

Powiązane artykuły