Чому клієнти Access Server недоступні з локальної мережі

Ноутбук підключається, тунель піднято, а запити до внутрішньої служби зависають на етапі з’єднання. На самій службі запит надходить з адреси на кшталт 10.90.0.25, відповідь виходить до шлюзу за замовчуванням, і нічого не повертається, бо цей шлюз не знає, де розташований 10.90.0.25. З іншого боку та сама несправність виглядає як внутрішній хост, що не може пінгувати підключеного клієнта. І те, і друге — один відсутній об’єкт: зворотний маршрут до пулу клієнтів VPN, який може додати лише приватна мережа.

Прочитайте адресу джерела, яку бачить служба

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

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

ip -br addr show
ss -tnp state established '( dport = :443 )'
ip route get 10.90.0.25

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

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

Додайте маршрут там, де вирішується відповідь

Маршрут належить шлюзу, який внутрішня служба вже використовує, а не самій службі, якщо тільки вона не маршрутизує власний трафік. Спрямуйте його на досяжну приватну адресу Access Server, яка відрізняється від тунельної адреси клієнта.

ip route add 10.90.0.0/24 via 10.0.1.5
ip route get 10.90.0.25

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

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

Пересилання й фільтри мають узгоджуватися з маршрутом

Маршрутизація — це лише половина шляху. Серверові має бути дозволено пересилати між тунелем і приватним інтерфейсом, що в Linux означає net.ipv4.ip_forward плюс ланцюг пересилання, який дозволяє пару інтерфейсів, а на зміцненому хості зазвичай окреме явне правило для кожного напрямку.

sysctl net.ipv4.ip_forward
nft list ruleset | grep -A5 forward

Фільтрація з урахуванням стану пояснює симптом, який веде людей не туди. Відповідь усередині встановленого потоку не потребує нового вхідного правила, тому з’єднання, що зависає після SYN-ACK, блокується не відсутнім правилом accept; його відкидають або маршрутизують неправильно. Зберігайте цю відмінність, бо вона відокремлює зміну маршрутизації від зміни брандмауера.

Асиметричні зворотні шляхи — тихіша версія тієї самої проблеми. Якщо до пулу ведуть два маршрути і відповідь іде тим, що виходить через інший інтерфейс, ніж той, яким надійшов запит, сувора перевірка зворотного шляху відкидає його, і потік зривається лише в частини клієнтів.

Маршрутизація чи маскарадинг: виберіть свідомо

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

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

Підмережа за клієнтом — окреме завдання

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

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

Перевірте одним потоком і одним перехопленням

Доведіть шлях одним з’єднанням замість загального тесту досяжності. Спостерігайте той самий потік на обох кінцях: запит, що надходить до служби, і відповідь, що її покидає.

tcpdump -ni any host 10.90.0.25 and port 443

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

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