Чому клієнти OpenVPN не потрапляють у селектори IPsec шлюзу

Надішліть ping зі шлюзу на хост за віддаленим тунелем IPsec, і він чисто відповідає, тож тунель виглядає здоровим, а тікет іде далі. Далі підключений клієнт пробує той самий хост і нічого не отримує. Той ping ніколи не був доказом для потоку клієнта, бо вийшов із власною адресою джерела шлюзу і збігся з іншим селектором IPsec. Розуміння того, чому ці два випадки розходяться, і є більшість виправлення.

Ping зі шлюзу перевіряє потік, який ваш клієнт ніколи не використовує

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

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

Просуньте віддалений префікс, який застосунку справді потрібен

Візьміть ілюстративну пару 10.8.0.0/24 для підключених клієнтів і 172.30.239.0/25 для захищеної віддаленої мережі. Клієнтові потрібен маршрут до другого префікса, а не до LAN шлюзу і не до якоїсь іншої адреси тунелю. Саме просунутий у пул маршрут змушує клієнта взагалі передати цей трафік шлюзу. Без нього пакет ніколи не дійде до того рішення політики, яке ви налагоджуєте.

На сервері Community, який приймає просунуті маршрути, директива бере справжню маску: push "route 172.30.239.0 255.255.255.128". Access Server налаштовує ту саму ціль через параметри приватної мережі або правила доступу встановленої версії, причому маршрутизований чи трансляційний режим обирається свідомо. Правка згенерованих ланцюгів брандмауера замість відповідної конфігурації — це шлях, яким робоча інсталяція стає невідтворюваною.

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

Зробіть так, щоб селектори включали пул клієнтів

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

Огляньте узгоджену політику та налаштовані пропозиції, наприклад за допомогою ipsec statusall у strongSwan або еквівалентної команди стану для вашої реалізації. В IPsec на основі політик звичайний маршрут може вказувати на фізичний інтерфейс, поки відповідний трафік усе ще шифрується, тож відсутність тунельного пристрою нічого не доводить. Порівняйте пари селекторів із пулом і префіксом, які ви записали.

Загальний source NAT на шлюзі теж може зламати збіг. Якщо правило masquerade переписує джерело клієнта до перевірки політики, пакет уже не виглядає як написаний вами селектор. Це одна з причин, чому широке правило masquerade є поганим виправленням для другого VPN: воно змінює, яка політика застосовується і яку адресу фіксує віддалена сторона. Звільніть трафік, який збираєтеся маршрутизувати, або свідомо транслюйте його та оновіть селектори.

Свідомо оберіть маршрутизацію або трансляцію

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

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

Замкніть цикл на пересиланні та відповіді

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

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

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