Користувач шлюзу в Access Server: маршрутизація LAN філії клієнта

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

Дві адреси, два різні домагання

Коли клієнт підключається, Access Server видає йому адресу з налаштованого пулу VPN, наприклад 10.90.0.0/24. Це виділення — оренда для одного вузла. Ніщо не каже, що той самий клієнт стоїть і перед 10.60.0.0/24, і сервер не вгадуватиме: префікс LAN доступний через конкретного клієнта лише тоді, коли адміністратор його оголосить.

Тому статичний маршрут на іншій машині не допомагає. Маршрут каже надсилай 10.60.0.0/24 на цю адресу, але якщо адреса належить клієнту, який ніколи не позначався як шлюз, сервер не має причини доставляти туди ці пакети, а стек клієнта може їх відкинути. Оголошення і маршрут — дві половини одного механізму.

Що встановлює налаштування шлюзу

У Admin Web UI оголошення — це властивість користувача: увімкніть Configure VPN gateway у користувача-конектора і введіть реальний префікс філії в Network on the VPN client side. Цей користувач автентифікується як будь-який інший, тому йому потрібна політика облікових даних для пристрою без нагляду.

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

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

Завершіть зворотні шляхи обох мереж

План: головний офіс 10.40.0.0/24, філія 10.60.0.0/24, пул VPN 10.90.0.0/24, а Access Server доступний за приватною адресою. Маршрутизатору головного офісу потрібні маршрути для префікса філії та пулу. Без них тунель несе запит, а відповідь виходить через шлюз за замовчуванням, що дає напіввідкрите з'єднання.

У філії конектор має пересилати пакети, не адресовані йому: пересилання IP в операційній системі плюс дозвіл, обмежений інтерфейсами тунелю та LAN; у Linux це net.ipv4.ip_forward=1 разом із правилами ланцюжка forward, у Windows — routing and remote access. Потім вузлам філії потрібен зворотний шлях: або конектор є їхнім шлюзом за замовчуванням, або наявний шлюз несе конкретні маршрути.

Таблиця маршрутизації конектора не переналаштовує кожен вузол у LAN філії. Якщо вузли вказують на інший маршрутизатор, зворотні маршрути належать йому, і він має прийняти, що видима адреса джерела не є сусідом у локальній підмережі.

Читайте збій як шлях

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

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

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

Посібник Access Server щодо з'єднання сайт-сайт перелічує ті самі налаштування в порядку продукту.