Як локальне переспрямування SSH переносить сесію TCP OpenVPN
Один локальний порт, два автентифіковані зв'язки, три транспорти. Що переміщує переспрямування SSH і де ще діють петля та перевірки сертифіката.
Тут нашаровуються три транспорти, і кожен має своє кадрування. Корисне навантаження VPN іде всередині сесії TLS, ця сесія TLS іде всередині TCP-з'єднання до порту зворотної петлі, а байти цього з'єднання йдуть усередині SSH до relay-хоста, який відкриває справжнє TCP-з'єднання до слухача VPN. Ніщо в цій схемі не змінює те, що OpenVPN автентифікує, і ніщо в ній не робить слухач UDP досяжним через TCP. Читайте решту як опис шляху байтів, а не як рецепт обходу мережевого контролю.
Що насправді переміщує локальне переспрямування
Клієнт SSH слухає локальний порт. Коли локальний процес підключається, клієнт пакує байти у свій зашифрований канал, а серверний бік відкриває нове TCP-з'єднання до пункту призначення, названого в запиті переспрямування.
Цей пункт призначення розв'язує relay, а не ваша машина, тому ім'я, що існує лише всередині віддаленої мережі, досі працює. Це також означає, що relay має досягати слухача VPN і мати зворотний маршрут до нього. Ім'я, яке розв'язується на вашому ноутбуці, нічого не каже про те, що бачить relay.
Запуск сесії SSH доводить лише те, що relay досяжний і автентифікований. Він нічого не каже про те, чи працює наступний слухач, чи приймає з'єднання міжмережевий екран між relay і слухачем або чи прийме VPN ваш профіль.
Спрямуйте клієнт на локальний слухач
Оголошений приклад: relay досягає слухача TCP на gw.internal.example:443, а високий локальний порт відкриває цей шлях лише цій машині.
ssh -N -L 127.0.0.1:24011:gw.internal.example:443 [email protected]Посібник OpenSSH описує локальне переспрямування як локальний прийом TCP-з'єднань і відкриття наступного з'єднання з віддаленого боку. Прив'язуйте слухач до зворотної петлі, а не до всіх інтерфейсів, бо переспрямування, досяжне з мережі, — це відкритий relay з вашим ім'ям. Прив'язка з підстановчим знаком також відкриває порт будь-якому іншому локальному обліковому запису на спільній машині.
Далі переведіть клієнт VPN у режим TCP і спрямуйте його на 127.0.0.1:24011. Якщо профіль використовує UDP, ця схема не допоможе: переспрямування несе потік байтів, і шляху дейтаграм через нього немає.
Тримайте дві автентифікації окремо
SSH автентифікує relay-хост. OpenVPN і далі автентифікує партнера VPN, і призначення на зворотній петлі не змінює цієї вимоги. Вимкнення перевірок сертифіката через те, що сокет тепер указує на localhost, — найгірше скорочення в цій схемі. Воно перетворює транспортну домовленість на домовленість про довіру, і на другу ніхто не погоджувався.
Зберігайте якір довіри профілю, перевірку ролі сервера й перевірку імені недоторканими. Якщо ваш клієнт порівнює ім'я сервера з адресою, на яку дзвонив, зворотній петлі може знадобитися явне налаштування імені замість вимкненої перевірки, а документація профілю — те місце, де підтверджують, яке поле порівнюється.
Ставтеся до relay як до другої сторони в історії довіри: його адміністратор бачить метадані з'єднань і може перенаправити переспрямування, якщо конфігурацію змінено. Схема потребує схвалення і relay, і власника служби VPN, а не лише того, кому це потрібно сьогодні.
Не будуйте петлю під тунелем
Після того як VPN встановить маршрути, SSH-з'єднанню, що його несе, усе ще потрібен шлях до relay, який не проходить через тунель. Якщо маршрут за замовчуванням переходить до VPN, а relay доступний лише через той самий тунель, транспорт руйнується, і VPN іде разом із ним. Збій виглядає як падіння тунелю, а не як помилка маршрутизації, тому його діагностують неправильно.
Звичайне виправлення — маршрут до хоста за адресою relay, закріплений за фізичним інтерфейсом до підняття тунелю, плюс перевірка, що маршрут переживає повторне підключення. Перевірте його пошуком маршруту для адреси relay, а не припущенням, що порядок був правильний.
Очікуйте також, що цей стек буде повільнішим і крихкішим за пряме з'єднання, бо тепер є два впорядковані транспорти й ще одна кінцева точка для обслуговування. Це спосіб перетнути мережевий кордон, а не техніка продуктивності.
Закрийте слухач, коли завершите
Зупиніть сесію SSH, коли тунель більше не потрібен, і підтвердьте, що локальний порт звільнено. Забуте переспрямування тримає автентифікований шлях відкритим на машині, яка може бути спільною.
Перегляньте також дозволені пункти призначення переспрямування на relay, бо потуральна конфігурація перетворює будь-який скомпрометований обліковий запис на загальну точку опори. Запишіть порт, relay і пункт призначення разом, щоб наступна людина знала, для чого було переспрямування і чи воно ще схвалене.