Спліт-тунель не звільняє публічний хост від правил NAT на ASA

Маршрут split-include втягує публічний хост у тунель, де ASA має виконати hairpin і транслювати джерело. Пропустіть будь-який із двох кроків — і потік обірветься.

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

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

Міф: спліт-тунель прибирає міжмережевий екран зі шляху

Вважається, що будь-яке призначення поза приватними діапазонами залишається на локальному інтернет-з’єднанні, тому міжмережевий екран його ніколи не бачить і ніколи не потребує правила для нього. Це слушно лише доти, доки призначення немає в списку тунелю. Тієї миті, коли адміністратор додає публічний хост до ACL split-include, клієнт надсилає цей трафік у тунель, і ASA має маршрутизувати, фільтрувати й транслювати його, як будь-який інший розшифрований потік. На клієнті не змінилося нічого, крім списку призначень.

Клієнт не став маршрутизатором. Він дотримався політики, яку ви йому дали.

Що насправді робить маршрут split-include

У конфігурації віддаленого доступу Cisco ASA групова політика містить split-tunnel-policy tunnelspecified і split-tunnel-network-list, який називає стандартний ACL. Кожен рядок permit у цьому ACL — це призначення, яке клієнт має надіслати в тунель, а все інше далі використовує локальний маршрут за замовчуванням.

Додавання одного хоста — це один рядок, і це єдина частина зміни, яку клієнт може побачити: access-list RA-SPLIT standard permit host 203.0.113.20.

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

Пакет приходить і виходить через той самий інтерфейс

Тепер простежте потік після розшифрування. Пакет увійшов через зовнішній інтерфейс тунелем VPN, його призначення — публічна адреса, і таблиця маршрутизації надсилає його назад через той самий зовнішній інтерфейс в бік інтернету. Трафік, який входить і виходить через один інтерфейс, відкидається, якщо ASA не дозволено його пропускати, і саме це робить same-security-traffic permit intra-interface. Без цього з’єднання падає так, що виглядає як проблема маршрутизації, але нею не є.

Цей параметр глобальний. Він дозволяє hairpinning для кожного потоку, якому це потрібно, не лише для цього партнерського хоста, тому він належить до перевіреної зміни, а не до швидкого тесту.

Чому PAT, обмежений призначенням, не є необов’язковим

Адреса джерела в розшифрованому пакеті й далі є VPN-адресою клієнта, зазвичай із пулу на кшталт 10.77.0.0/24. Ця адреса не має маршруту в публічному інтернеті, тож партнер або ніколи не відповідає, або відповідає в нікуди.

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

same-security-traffic permit intra-interface

object network RA_POOL
 subnet 10.77.0.0 255.255.255.0
object network PARTNER_HOST
 host 203.0.113.20

nat (outside,outside) source dynamic RA_POOL interface destination static PARTNER_HOST PARTNER_HOST

Частина destination static важлива. Якщо її прибрати, правило стане широкою трансляцією, яка може збігтися з набагато більшим обсягом трафіку, ніж задумано, а широке правило identity, розташоване раніше в порядку, може повністю його подолати. Перевірте show nat detail і порядок розділів, перш ніж припускати, що збігається саме ваше правило.

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

Доведіть це правильним тестовим призначенням

Використовуйте сам партнерський хост, а не типову сторінку what-is-my-ip. Та сторінка майже напевно поза split-списком, тому повідомляє вашу локальну інтернет-адресу і нічого не каже про цей шлях. Відкрийте нове з’єднання зі службою партнера й запитайте, яке джерело вони спостерігали, або виконайте packet-tracer input outside tcp 10.77.0.10 12345 203.0.113.20 443 detailed і прочитайте етапи NAT і маршрутизації рядок за рядком. Traceroute з клієнта — слабша перевірка, бо показує шлях, який уже відбувся, а не політику, що його обрала.

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

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

Схожі статті