Lokalne przekierowanie SSH do istniejącego proxy HTTP: dwa adresy loopback

Zatwierdzone proxy działa na hoście pośredniczącym, gdzie nasłuchuje tylko na loopback, więc nic spoza tej maszyny nie może go osiągnąć. Nie potrzebujesz VPN ani nowego proxy; potrzebujesz jednego portu tej maszyny przeniesionego na jeden swój port. Lokalne przekierowanie robi dokładnie to i wymaga jednego polecenia oraz jednego ustawienia aplikacji. Zamieszanie zwykle wynika z pomylenia, który adres loopback należy do której maszyny.

Ustal, czy stałe proxy już istnieje

Ta technika przekierowuje usługę, która już działa. Jeśli zdalny host ma tylko demona SSH i żadnego proxy, żadna ilość przekierowania go nie stworzy, a połączenie zostanie odrzucone po stronie zdalnej. Potwierdź, że proxy jest związane, jaki ma port i czy nasłuchuje na 127.0.0.1, czy na konkretnym adresie interfejsu, bo właśnie na ten adres musi celować przekierowanie.

Potwierdzenie tego najpierw oszczędza ci debugowania tunelu, który nigdy nie był do niczego podłączony.

Zbuduj przekierowanie i przeczytaj polecenie

Potrzebna forma wiąże port loopback na twoim laptopie i łączy go, po stronie serwera, z adresem proxy tak, jak widzi go serwer.

ssh -NT -o ControlPath=none -o ExitOnForwardFailure=yes \
  -L 127.0.0.1:13128:127.0.0.1:3128 [email protected]

-N wycisza zdalne polecenie, a -T wycisza przydział termios, bo chcesz tunel, a nie powłokę. Pierwszy adres loopback to miejsce, gdzie nasłuchuje laptop; drugi jest rozwiązywany przez serwer SSH, więc 127.0.0.1 tam oznacza proxy na tej maszynie. ExitOnForwardFailure sprawia, że polecenie głośno zawodzi, jeśli lokalny port jest już zajęty, zamiast uruchamiać sesję, która nic nie przekierowuje. Adres docelowy zapisz tak, jak rozwiązuje go serwer, bo nazwa, którą może rozwiązać tylko twój laptop, zawiedzie po drugiej stronie.

Własna polityka serwera obowiązuje, zanim cokolwiek z tego zadziała. AllowTcpForwarding musi na to pozwalać, a PermitOpen może ograniczać, do jakich celów i portów może dotrzeć sesja, więc przekierowanie, które klient akceptuje, serwer nadal może odrzucić. Odmowa pojawia się jako błąd przekierowania lub kanału u klienta, a przeczytanie tej wiadomości jest szybsze niż edycja polecenia.

Skieruj jedną aplikację na przekierowanie

Skonfiguruj aplikację tak, aby używała proxy HTTP pod http://127.0.0.1:13128, z poświadczeniami, jeśli zdalne proxy ich wymaga. Zachowaj własną weryfikację certyfikatów aplikacji dla celów HTTPS, ponieważ tunel proxy jej nie zastępuje. To stałe przekierowanie jednej usługi, więc aplikacji trzeba powiedzieć o proxy, zamiast zostawiać jej samodzielne wykrywanie.

Szybkie sprawdzenie przed jakąkolwiek trwałą konfiguracją: curl -x http://127.0.0.1:13128 -I https://example.com, co ćwiczy metodę HTTP CONNECT, którą proxy musi obsługiwać.

Zachowaj uprawnienia tam, gdzie były

Zdalne proxy nadal decyduje, do jakich celów i metod pozwala, a logowanie SSH nie powinno po cichu dawać każdemu kontu ogólnego przekaźnika sieciowego. Powiązanie z 127.0.0.1 na laptopie pozwala uniknąć publikowania portu w twojej sieci lokalnej i nie czyni portu prywatnym wobec innych procesów na tej samej maszynie. Zastąpienie tego powiązania adresem wildcard, aby udostępnić proxy, to sposób, w jaki powstaje niezarządzany otwarty przekaźnik.

Transport SSH chroni przeskok do serwera. Dalej proxy otwiera własne połączenie, więc zwykłe żądanie HTTP do celu pozostaje zwykłe także za serwerem, mimo że pierwszy odcinek był zaszyfrowany.

Zweryfikuj oba końce, a potem posprzątaj

Konfiguracja lokalnego tunelu i sukces zdalnej usługi to różne wyniki, a kod wyjścia polecenia mówi ci tylko o pierwszym. Sprawdź ss -ltn, czy nasłuch istnieje, a następnie wykonaj dozwolone żądanie aplikacji i żądanie, które proxy powinno odrzucić. Jeśli oba zachowują się zgodnie z oczekiwaniem, ścieżka jest prawdziwa; jeśli tunel działa, a każde żądanie zawodzi, proxy odmawia lub nie może dotrzeć do celu.

Gdy skończysz, zatrzymaj proces SSH, który go posiada, usuń ustawienie proxy z aplikacji i potwierdź, że lokalny port zniknął, zamiast zostawiać nasłuch, który przetrwa zadanie.