Порт, переадресований через 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 зберігає протокол і обліковий запис цього проксі.