Локальне переспрямування SSH до наявного HTTP-проксі: дві адреси loopback
Наявний проксі на SSH-хості може обслуговувати один застосунок через одне локальне переспрямування. Розрізняйте дві адреси loopback і протокол проксі.
Ваш затверджений проксі працює на проміжному хості, де слухає лише loopback, тому ніщо поза цією машиною не може до нього дістатися. Вам не потрібні VPN або новий проксі; вам потрібен один порт цієї машини, перенесений на один ваш порт. Локальне переспрямування робить саме це, і для нього потрібні одна команда та одне налаштування застосунку. Плутанина зазвичай виникає через змішування того, яка адреса loopback належить якій машині.
Вирішіть, чи вже існує фіксований проксі
Ця техніка переспрямовує службу, яка вже працює. Якщо на віддаленому хості є лише демон SSH і немає проксі, жодна кількість переспрямування його не створить, і з'єднання буде відхилено з віддаленого боку. Переконайтеся, що проксі прив'язаний, який у нього порт і чи слухає він на 127.0.0.1 або на конкретній адресі інтерфейсу, бо саме на цю адресу має цілитися переспрямування.
Якщо перевірити це заздалегідь, ви позбавите себе налагодження тунелю, який ніколи ні до чого не був підключений.
Побудуйте переспрямування й прочитайте команду
Потрібна форма прив'язує порт loopback на вашому ноутбуці та з'єднує його з боку сервера з адресою проксі так, як сервер її бачить.
ssh -NT -o ControlPath=none -o ExitOnForwardFailure=yes \
-L 127.0.0.1:13128:127.0.0.1:3128 [email protected]-N придушує віддалену команду, а -T придушує виділення termios, бо вам потрібен тунель, а не оболонка. Перша адреса loopback — це місце, де слухає ноутбук; другу розв'язує сервер SSH, тому 127.0.0.1 там означає проксі на тій машині. ExitOnForwardFailure змушує команду гучно завершитися помилкою, якщо локальний порт уже зайнятий, замість запуску сеансу, який нічого не переспрямовує. Записуйте цільову адресу так, як її розв'язує сервер, бо ім'я, яке може розв'язати лише ваш ноутбук, не спрацює на іншому боці.
Власна політика сервера діє до того, як будь-що з цього запрацює. AllowTcpForwarding має це дозволяти, а PermitOpen може обмежувати, до яких призначень і портів може дістатися сеанс, тому переспрямування, яке клієнт приймає, сервер усе одно може відхилити. Відмова з'являється як помилка переспрямування або каналу на клієнті, і прочитати це повідомлення швидше, ніж редагувати команду.
Спрямуйте один застосунок на переспрямування
Налаштуйте застосунок на використання HTTP-проксі за адресою http://127.0.0.1:13128, з обліковими даними, якщо віддалений проксі їх вимагає. Збережіть власну перевірку сертифікатів застосунку для призначень HTTPS, оскільки тунель проксі її не замінює. Це фіксоване переспрямування однієї служби, тому застосунку треба сказати про проксі, а не залишати його самому шукати проксі.
Швидка перевірка перед будь-яким постійним налаштуванням: curl -x http://127.0.0.1:13128 -I https://example.com, що перевіряє метод HTTP CONNECT, який проксі має підтримувати.
Залиште повноваження там, де вони були
Віддалений проксі й далі вирішує, які призначення й методи він дозволяє, і вхід через SSH не повинен мовчки давати кожному обліковому запису загальний вебретранслятор. Прив'язка до 127.0.0.1 на ноутбуці уникає публікації порту у вашій локальній мережі й не робить порт закритим від інших процесів на тій самій машині. Заміна цієї прив'язки адресою wildcard заради спільного використання проксі — так і з'являється некерований відкритий ретранслятор.
Транспорт SSH захищає перехід до сервера. Далі проксі відкриває власне з'єднання, тому звичайний HTTP-запит до призначення залишається звичайним і за сервером, хоча перший відрізок був зашифрований.
Перевірте обидва кінці, потім приберіть
Налаштування локального тунелю й успіх віддаленої служби — різні результати, і код виходу команди говорить вам лише про перший. Перевірте наявність слухача за допомогою ss -ltn, потім виконайте дозволений запит застосунку й запит, який проксі має відхилити. Якщо обидва поводяться як очікується, шлях справжній; якщо тунель працює, а кожен запит завершується помилкою, проксі відмовляє або не може дістатися призначення.
Коли закінчите, зупиніть процес SSH, якому він належить, видаліть налаштування проксі із застосунку й переконайтеся, що локальний порт зник, а не залишився слухач, який переживе завдання.