Порт, переадресованный через 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: он передаёт байты единственному веб-серверу, указанному в команде. Открытие сайта под другим именем хоста также может повлиять на его виртуальный хостинг, перенаправления или cookie.
Для SOCKS-слушателя форма меняется:
ssh -N -D 127.0.0.1:1080 [email protected]Настройте приложение на использование SOCKS по адресу 127.0.0.1:1080. Ввод этого адреса прямо в адресную строку браузера отправляет веб-запрос SOCKS-слушателю, ещё одно несоответствие протоколов.
Руководство OpenSSH описывает обе формы. Есть полезное исключение: переадресация существующего HTTP-прокси с помощью -L создаёт локальный порт, который говорит на протоколе HTTP-прокси, потому что его фиксированное назначение само является HTTP-прокси. Именно служба на дальнем конце определяет, что подходит для фиксированной переадресации. Переадресация существующего прокси через SSH сохраняет протокол и учётную запись этого прокси.