Доступ до сайту HTTPS, доступного лише через VPN, за допомогою SSH-перенаправлення

На одній машині вже є схвалений доступ до VPN, другій машині потрібен рівно один приватний сервіс HTTPS, і локальне SSH-перенаправлення може закрити цю прогалину, не даючи другій машині тунель. Перенаправлення переносить одне TCP-призначення, а не всю мережу, і саме це обмеження є суттю. Пройдіть п'ять кроків нижче по порядку, бо кожен збій має свою причину і пізніший крок не може врятувати ранішу прогалину. Якщо бракує будь-якої передумови, цей проєкт її не вирішує, і жодне налаштування команд не допоможе.

Крок перший: підтвердьте три передумови

Три речі мають бути вже правдою, перш ніж будь-яка команда матиме значення. Потрібні дозвіл використовувати першу машину як хост перенаправлення, робочий доступ SSH до неї та політика сервера, що дозволяє заплановане призначення. У обліковому записі SSH, створеному для передавання файлів, перенаправлення може бути вимкнене, а сервер, що дозволяє перенаправлення, все одно може обмежувати, які призначення через нього доступні. Запитайте перед тестуванням, бо використання робочої станції колеги як точки переходу без домовленості є проблемою політики, навіть коли команда працює бездоганно.

Дві команди вирішують технічну половину цього списку. Перша доводить, що обліковий запис і ключ працюють без інтерактивного запиту, а друга друкує фактичну політику сервера, а не закоментований приклад у файлі конфігурації.

ssh -o BatchMode=yes [email protected] 'echo ok'
sudo sshd -T | grep -E 'allowtcpforwarding|permitopen'

Крок другий: прив'яжіть порт loopback і тримайте сеанс живим

На машині, де працює клієнтський застосунок, відкрийте локальне перенаправлення до приватного сервісу. Прив'яжіть його явно до loopback, щоб він не публікувався в локальній мережі, і виберіть високий порт, який ще не займає жоден локальний сервіс. Тримайте сеанс робочим, поки працюєте, бо його закриття закриває й слухача. ExitOnForwardFailure перетворює відхилене прив'язування або зайнятий порт на негайний вихід замість сеансу, що лишається без перенаправлення, і саме цей режим відмови марнує найбільше часу.

Приватне з'єднання встановлюється з хоста переходу, тому його DNS, маршрути, політика VPN і доступ до сервісу мають усі працювати. Сеанс SSH не створює досяжності, якої хост переходу не має, і не може виправити маршрут, який VPN так і не проштовхнув. Підтвердьте слухача там, де він справді є, замість того щоб довіряти тиші команди.

ssh -N -o ExitOnForwardFailure=yes -L 127.0.0.1:9443:portal.lab.example:443 [email protected]
ss -ltn '( sport = :9443 )'

Крок третій: зберігайте ім'я HTTPS, коли сокет локальний

Перехід на https://127.0.0.1:9443/ змінює ім'я сервера TLS і повноваження застосунку. Сертифікат, виданий для portal.lab.example, не проходитиме перевірку проти адреси loopback, і помилка, що виникне, виглядає як зламаний сертифікат, а не як скорочений шлях перенаправлення. Для перевірки з командного рядка збережіть справжній URL і змініть лише призначення сокета. Це робить --connect-to, а посібник curl описує використану нижче форму з чотирьох полів.

curl --noproxy portal.lab.example --connect-to portal.lab.example:443:127.0.0.1:9443 https://portal.lab.example/

Ім'я залишається в URL, у рукостисканні TLS і в заголовку Host, а TCP-з'єднання йде до локального слухача. Параметр без проксі утримує перевірку на цьому перенаправленні, замість того щоб налаштований HTTP-проксі її перехопив, а збереження перевірки сертифіката ввімкненою і робить результат осмисленим.

Крок четвертий: знайте, що не охоплює одне перенаправлення

Одне TCP-перенаправлення охоплює один порт призначення. Сторінці, яка перенаправляє на друге ім'я хоста, завантажує ресурси з хоста всередині приватної мережі або надсилає на інший порт, потрібне власне перенаправлення, і кожному з них потрібна така сама перевірка політики, як першому. Робочі процеси браузера додають власні вимоги, бо браузеру треба сказати надсилати справжнє ім'я на локальний порт через конфігурацію проксі або локальне зіставлення. Тому успішна перевірка з командного рядка не доводить, що браузер теж упорається, хоча й доводить шлях.

UDP, виявлення SMB і вхід до домену взагалі не проходять через TCP-перенаправлення. Якщо справжня потреба — загальний доступ до мережі, цей проєкт є неправильним інструментом, а правильний — підтримуваний шлюз віддаленого доступу.

Крок п'ятий: приберіть і запишіть

Зупиніть сеанс, коли перевірку завершено, і підтвердьте, що слухач зник. Якщо вибраний порт уже був зайнятий, виберіть інший невикористаний порт loopback і оновіть разом URL, тестову команду й нотатку, замість того щоб зупиняти не пов'язаний локальний сервіс для звільнення номера. Залишене відкритим перенаправлення на ноутбуці перетворює діагностику на некерований сервіс.

Запишіть хост переходу, перенаправлене призначення, локальний порт і того, хто схвалив домовленість. Перенаправлення, що існує лише в чиїйсь історії shell, перебуває за один перезапуск від повторного розслідування, і наступна людина не знатиме, яку з трьох передумов уже перевірено.