Port przekierowany przez SSH nie zawsze jest proxy SOCKS
Odróżnij stałe lokalne przekierowanie SSH od dynamicznego nasłuchu SOCKS, zanim skonfigurujesz aplikację.
Tworzysz tunel SSH, wpisujesz 127.0.0.1 i jego port w ustawieniach proxy przeglądarki, i nic się nie ładuje. Nasłuch może działać bez zarzutu. Być może po prostu czeka na niewłaściwy rodzaj ruchu.
| Przekierowanie | Co wysyła aplikacja lokalna | Wybór celu |
|---|---|---|
-L | Zwykły protokół usługi docelowej | Ustalony w poleceniu SSH |
-D | Negocjacja SOCKS, następnie ruch aplikacji | Żądany przez klienta SOCKS |
Dla jednego serwera WWW jest to stałe przekierowanie:
ssh -N -L 127.0.0.1:9080:web.example.com:80 [email protected]Odwiedź http://127.0.0.1:9080/ jako witrynę. Nie oznaczaj portu 9080 jako SOCKS: przekazuje bajty do jednego serwera WWW wymienionego w poleceniu. Otwarcie witryny pod inną nazwą hosta może też wpływać na jej hosting wirtualny, przekierowania lub pliki cookie.
Dla nasłuchu SOCKS kształt się zmienia:
ssh -N -D 127.0.0.1:1080 [email protected]Skonfiguruj aplikację, aby używała SOCKS pod 127.0.0.1:1080. Wpisanie tego adresu bezpośrednio w pasku adresu przeglądarki wysyła żądanie sieciowe do nasłuchu SOCKS, kolejna niezgodność protokołów.
Podręcznik OpenSSH dokumentuje oba warianty. Istnieje użyteczny wyjątek: przekierowanie istniejącego proxy HTTP za pomocą -L daje lokalny port mówiący protokołem proxy HTTP, ponieważ jego stałym celem jest samo proxy HTTP. Usługa na drugim końcu decyduje, co należy do stałego przekierowania. Przekierowanie istniejącego proxy przez SSH zachowuje protokół i konto tego proxy.