Како моделирати VPN ток помоћу ASA packet-tracer

Packet-tracer на ASA одговара на уско питање: да ли би овај пакет, који овде улази са овим tuple, био дозвољен и куда би отишао. Не одговара да ли далеки крај прима нешто. Уобичајена грешка је уношење спољашњег IKE tuple када је оно што желите да тестирате апликација која се креће унутар тунела. Прво исправите tuple, прочитајте фазе, а затим прикупите стварне доказе за све што симулатор не види.

Преглед испод претпоставља да су 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, и tuple се обрће. Уписивање одредишта као извора је други најчешћи начин да се добије убедљив али неважан 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 преносе пакете или чувају стање. Следите документовано понашање за ваше издање и одобрену дијагностичку процедуру уместо да сваку варијанту третирате као претрагу само за читање.

Шта траг још увек не може да вам каже

Држите четири ствари у једној белешци: tuple, одговарајуће правило NAT, тунел или политику која би требало да носи ток, и запажање специфично за смер. Без њих каснији инжењер не може да одвоји локалну одлуку о политици од успостављене контролне равни и од услуге која ради. Први неуспех кога следи успех такође није доказ да је тунел морао да се подигне између; запишите фазу и промену стања.

Почните са унутрашњим tuple, зауставите се на првој фази која противречи пројекту и само онда посегните за доказима са крајњих тачака. Траг је оракул политике, не потврда о достави.