Як моделювати потік VPN за допомогою ASA packet-tracer

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

Розбір нижче припускає, що ACL, правило NAT і контекст tunnel-group перед вами. Без них вивід описує політику, яку ви не можете перевірити.

Крок 1: опишіть внутрішній потік простими словами

Опишіть застосунок, перш ніж щось вводити. Хост усередині, що відкриває SSH до сервера за далеким шлюзом, — це один внутрішній потік TCP з певним портом джерела. Саме цей потік оцінюють ACL і фільтр VPN, тому саме його ви вводите.

Запишіть його реченням і перекладіть поле за полем:

packet-tracer input inside tcp 10.30.0.25 53000 10.40.0.50 22 detailed

Крок 2: виберіть вхідний інтерфейс і напрямок

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

Порти теж мають напрямок. Порт служби належить полю призначення при ініційованому запиті, а ефемерний порт клієнта — полю джерела. Модель із призначенням TCP 500 описує застосунок TCP, що слухає 500; вона не стає тестом IKE лише тому, що число з'явилося в команді.

Крок 3: читайте фази по порядку

Кожна фаза у виводі — рішення з власником: пошук маршруту, ACL, NAT, потім вибір VPN або тунелю. Читайте їх у надрукованому порядку і зупиніться на першій фазі, що розходиться з проєктом.

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

Крок 4: перевірте, які обходи ви вибрали

Форма detailed приймає параметри, що пропускають перевірки, і Cisco документує параметр bypass-checks, що охоплює ACL, фільтр VPN, uRPF і перевірки підміни IPsec. ALLOW, отриманий із цими обходами, каже, що маршрут і NAT працювали б, а не що політика прийняла б реальний пакет. Запишіть параметри поруч із результатом.

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

Крок 5: закрийте розрив реальним обміном

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

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

Чого трасування все ще не може сказати

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

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