Шлюз розміщує власну сторінку адміністрування: внутрішня чи публічна адреса

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

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

Сторінка завантажується ззовні, а не через тунель

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

Маршрут призначення вибирає адресу, а не порт. Ніщо в таблиці маршрутизації не знає, що порт 443 призначений для адміністрування, а порт 1194 — для транспорту, тому обидва вважаються одним і тим самим призначенням.

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

Тримайте зовнішню кінцеву точку доступною

Профілям повного тунелю потрібен маршрут-виняток для кінцевої точки VPN, і параметр redirect-gateway в OpenVPN документує саме це: віддалена кінцева точка зберігає маршрут через раніше наявний шлюз, щоб тунель не маршрутизував у себе. Приберіть цей виняток, і зашифрований транспорт піде за тунелем, що завершить сеанс у петлі. Саме через цей виняток адреса кінцевої точки залишається доступною зсередини тунелю.

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

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

ip -4 route get 203.0.113.77
ip -4 rule show
ip -4 route show table all

Якщо пошук показує маршрут кінцевої точки через фізичний шлюз, поведінка правильна, і сторінка адміністрування просто надсилається не тим шляхом. Саме тут розв'язання імен стає виправленням.

Дайте службі приватне ім'я

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

Не перенаправляйте ім'я транспорту на внутрішню адресу, бо наступне встановлення тунелю тоді спробує досягти адреси, яка існує лише всередині тунелю. Ця помилка дає VPN, що працює рівно один раз.

Перевірте й обидві родини адрес, бо залишений запис AAAA може відправити браузер туди, куди приватний план ніколи не сягав.

dig +short admin.hq.internal
dig +short -t AAAA admin.hq.internal
curl -sS -o /dev/null -w '%{http_code} %{remote_ip}\n' https://admin.hq.internal/

Узгодьте політику з місцем, де працює процес

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

Контейнер, опублікований на порту хоста, іде іншим шляхом, бо пакет транслюється за призначенням і пересилається. Цей запит зустрічає політику пересилання хоста й власні правила Docker, тому робочий нативний слухач може співіснувати з контейнером, який відхиляє той самий порт.

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

Перевірте приватний доступ і відхилений публічний шлях

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

Читайте прив'язки й стан фільтра, а не ім'я хоста, яке отримали користувачі. Відкритість — властивість сокета, а не імені. Ця різниця переживає будь-яку зміну DNS.

ss -lntp | grep ':443'
nft list ruleset | grep -n 443
curl -sS -m 5 -o /dev/null -w '%{http_code}\n' https://203.0.113.77/

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

Схожі статті