Пренасочен порт по SSH не винаги е SOCKS прокси
Разграничете фиксираното локално пренасочване по SSH от динамичния SOCKS слушател, преди да конфигурирате приложение.
Създавате SSH тунел, въвеждате 127.0.0.1 и порта му в настройките за прокси на браузъра и нищо не се зарежда. Слушателят може да работи безупречно. Може просто да чака грешен вид трафик.
| Пренасочване | Какво изпраща локалното приложение | Избор на дестинация |
|---|---|---|
-L | Обичайният протокол на целевата услуга | Фиксиран в SSH командата |
-D | SOCKS договаряне, след това трафик на приложението | Поискан от SOCKS клиента |
За един уеб сървър това е фиксирано пренасочване:
ssh -N -L 127.0.0.1:9080:web.example.com:80 [email protected]Отворете http://127.0.0.1:9080/ като уебсайт. Не обозначавайте порт 9080 като SOCKS: той препраща байтове към единствения уеб сървър, посочен в командата. Отварянето на сайт под друго име на хост може също да засегне виртуалния хостинг, пренасочванията или бисквитките му.
За SOCKS слушател формата се променя:
ssh -N -D 127.0.0.1:1080 [email protected]Конфигурирайте приложението да използва SOCKS на 127.0.0.1:1080. Въвеждането на този адрес директно в адресната лента на браузъра изпраща уеб заявка към SOCKS слушател, още едно несъответствие на протокола.
Ръководството на OpenSSH документира и двете форми. Има полезно изключение: пренасочването на съществуващ HTTP прокси чрез -L създава локален порт, който говори протокола на HTTP прокси, защото фиксираната му дестинация сама е HTTP прокси. Услугата в далечния край определя какво принадлежи на фиксирано пренасочване. Пренасочване на съществуващ прокси през SSH запазва протокола и акаунта на този прокси.