Jak modelovat tok VPN pomocí ASA packet-tracer

Packet-tracer na ASA odpovídá na úzkou otázku: byl by tento paket, který zde vstupuje s tímto tuplem, povolen a kam by šel. Neodpovídá na to, zda vzdálený konec něco přijme. Běžnou chybou je zadávat vnější IKE tuple, když to, co chcete testovat, je aplikace, která jede uvnitř tunelu. Nejprve opravte tuple, přečtěte fáze a potom si opatřete skutečné důkazy pro vše, co simulátor nevidí.

Následující průchod předpokládá, že před sebou máte ACL, pravidlo NAT a kontext tunnel-group. Bez nich výstup popisuje politiku, kterou nemůžete ověřit.

Krok 1: napište vnitřní tok prostými slovy

Popište aplikaci, než cokoli napíšete. Host uvnitř, který otevírá SSH k serveru za vzdálenou bránou, je jeden vnitřní tok TCP s konkrétním zdrojovým portem. To je tok, který hodnotí ACL a filtr VPN, takže to je tok, který zadáváte.

Napište ho jako větu a potom ho přeložte pole po poli:

packet-tracer input inside tcp 10.30.0.25 53000 10.40.0.50 22 detailed

Krok 2: vyberte vstupní rozhraní a směr

Vstup je rozhraní, na kterém paket přichází, ne to, kterým odchází. Pro host v LAN, který spojení iniciuje, je to rozhraní inside. Pro návratový paket stejné relace je to rozhraní outside a tuple se obrací. Zapsat cíl jako zdroj je druhý nejčastější způsob, jak získat přesvědčivý, ale nepodstatný ALLOW.

Porty mají také směr. Port služby patří do pole cíle u iniciovaného požadavku a dočasný port klienta patří do pole zdroje. Model s cílem TCP 500 popisuje aplikaci TCP, která naslouchá na 500; nestane se testem IKE jen proto, že se číslo objeví v příkazu.

Krok 3: čtěte fáze v pořadí

Každá fáze ve výstupu je rozhodnutí s vlastníkem: hledání trasy, ACL, NAT a potom volba VPN nebo tunelu. Čtěte je v tištěném pořadí a zastavte se u první fáze, která neodpovídá návrhu.

NAT lidi často nachytá. Pokud přeložený zdroj padne mimo crypto ACL, které vybírá provoz pro tunel, tok může být povolen a nikdy zapouzdřen. Trasování tiskne přeloženou adresu, takže ji porovnejte se zajímavým provozem tunelu, ne s původní adresou.

Krok 4: zkontrolujte, která obejití jste zvolili

Forma detailed přijímá volby, které přeskakují kontroly, a Cisco dokumentuje volbu bypass-checks pokrývající ACL, filtr VPN, uRPF a kontroly podvržení IPsec. ALLOW získaný s nimi říká, že trasa a NAT by fungovaly, ne že by politika přijala skutečný paket. Zapište volby vedle výsledku.

Pokud potřebujete odpověď politiky, spusťte to bez obejití. Pokud izolujete otázku směrování, spusťte to s nimi a označte výsledek jako odpověď o směrování.

Krok 5: uzavřete mezeru skutečnou výměnou

Simulované povolení končí na ASA. Zda vzdálená brána paket dešifrovala, zda server spojení přijal a zda se vrátila odpověď, jsou oddělená pozorování. Použijte čítače koncových bodů nebo úzké zachycení na schválené cestě.

Některé volby trace a replay přenášejí pakety nebo uchovávají stav. Postupujte podle dokumentovaného chování pro vaši verzi a schválený diagnostický postup, místo abyste každou variantu brali jako pouze čtecí dotaz.

Co vám trasování stále nemůže říct

Držte čtyři věci v jedné poznámce: tuple, odpovídající pravidlo NAT, tunel nebo politiku, která má tok nést, a pozorování specifické pro směr. Bez nich pozdější inženýr nedokáže oddělit místní rozhodnutí o politice od zavedené řídicí roviny a od fungující služby. První selhání následované úspěchem také není důkaz, že tunel musel mezitím vzniknout; zapište fázi a změnu stavu.

Začněte vnitřním tuplem, zastavte se u první fáze, která odporuje návrhu, a teprve potom sáhněte po důkazech z koncových bodů. Trasování je orákulum politiky, ne potvrzení o doručení.