ASA hairpin: вихід в інтернет чи плече VPN між майданчиками?

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

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

Два плеча, один інтерфейс

Вирішіть, яке плече ви будуєте, перш ніж вводити правило NAT, бо правила не взаємозамінні. Плече A — від клієнта в інтернет: адреса пулу всередину, трансляційована публічна адреса назовні, назад через той самий інтерфейс. Плече B — від клієнта до приватного префікса на дальньому боці іншого партнера IPsec: адреса пулу зберігається, повторно шифрується й доставляється партнеру, який має знати, як відповісти пулу.

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

same-security-traffic permit intra-interface

Цей один рядок дозволяє схему пересилання, як описує довідка з NAT для ASA для шляхів через той самий інтерфейс. Він не додає маршрут клієнта, не авторизує ресурс, не транслює адресу й не узгоджує селектор IPsec, тому очікуйте, що після нього треба додати ще три-чотири речі, і не читайте його прийняття як прогрес.

Плече A: клієнт хоче в інтернет

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

object network VPN_POOL
 subnet 10.80.0.0 255.255.255.0
nat (outside,outside) after-auto source dynamic VPN_POOL interface route-lookup

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

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

Плече B: клієнт хоче приватний майданчик

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

nat (outside,outside) source static VPN_POOL VPN_POOL
    destination static SITE_PREFIX SITE_PREFIX route-lookup

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

Перевірте й порядок правил. Широке правило PAT над правилом ідентичності транслює приватний обмін ще до того, як правило ідентичності буде оцінене, і симптом — тунель майданчика без відповідного SA, а не помилка NAT.

Тест, який каже, яке плече ви збудували

Використовуйте власне оцінювання шляху на ASA, а не читання конфігурації й сподівання. packet-tracer input outside tcp 10.80.0.25 40000 203.0.113.10 443 detailed показує рішення NAT, маршрут і результат ACL для одного потоку; повторіть із приватним призначенням. Якщо фаза NAT переписує потік із приватного в приватний, ви збудували плече A для пакета, якому потрібне було плече B.

Ще дві команди закривають проміжок. show nat detail друкує порядок правил, якого дотримувався packet-tracer, і show crypto ipsec sa показує, чи існує селектор для очікуваної пари. Відсутній SA — це питання налаштування селектора чи партнера, а не те, що правило NAT може виправити.

Перевірте кожне плече тим трафіком, якому воно служить

Прийміть плече A звичайним публічним запитом від клієнта, а плече B — запитом до приватного ресурсу, який справді існує. Потім повторіть кожне з відхиленим ресурсом, бо «дозволено» і «схвалено політикою доступу» — не той самий доказ, і ping, що походить із концентратора, не тренує жодного з клієнтських шляхів.

Тримайте два записи тесту окремо в тікеті: адреса джерела, призначення, правило NAT, що збіглося, і результат. Коли наступний звіт скаже «VPN зламано», ця пара за хвилину скаже, яке плече деградувало, і відповідь зазвичай — маршрут або селектор, а не рядок того самого інтерфейсу, який усі підозрюють першим.

Схожі статті