Как да моделирате 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, тунела или политиката, които трябва да носят потока, и наблюдението, специфично за посоката. Без тях по-късен инженер не може да раздели локално решение за политика от установена управляваща плоскост и от работеща услуга. Първи провал, последван от успех, също не е доказателство, че тунелът е трябвало да се вдигне между тях; запишете фазата и промяната на състоянието.

Започнете с вътрешния кортеж, спрете на първата фаза, която противоречи на дизайна, и само тогава посегнете към доказателства от крайни точки. Проследяването е оракул за политика, не квитанция за доставка.