Ako modelovať tok VPN pomocou ASA packet-tracer

Packet-tracer na ASA odpovedá na úzku otázku: bol by tento paket, ktorý tu vstupuje s týmto tuplom, povolený a kam by šiel. Neodpovedá, či vzdialený koniec niečo prijme. Bežnou chybou je zadávať vonkajší IKE tuple, keď to, čo chcete testovať, je aplikácia, ktorá ide vnútri tunela. Najprv opravte tuple, prečítajte fázy a potom si zaobstarajte skutočné dôkazy pre všetko, čo simulátor nevidí.

Nasledujúci prehľad predpokladá, že ACL, pravidlo NAT a kontext tunnel-group sú pred vami. Bez nich výstup opisuje politiku, ktorú nemôžete overiť.

Krok 1: napíšte vnútorný tok jednoduchými slovami

Opíšte aplikáciu, skôr než čokoľvek napíšete. Host vnútri, ktorý otvára SSH k serveru za vzdialenou bránou, je jeden vnútorný tok TCP s konkrétnym zdrojovým portom. To je tok, ktorý hodnotia ACL a filter VPN, takže to je tok, ktorý zadávate.

Napíšte ho ako vetu a potom ho preložte pole po poli:

packet-tracer input inside tcp 10.30.0.25 53000 10.40.0.50 22 detailed

Krok 2: vyberte vstupné rozhranie a smer

Vstup je rozhranie, na ktorom paket prichádza, nie to, ktorým odchádza. Pre host v LAN, ktorý iniciuje, je to rozhranie inside. Pre návratový paket tej istej relácie je to rozhranie outside a tuple sa obracia. Zapísať cieľ ako zdroj je druhý najčastejší spôsob, ako získať presvedčivý, ale nepodstatný ALLOW.

Porty majú tiež smer. Port služby patrí do poľa cieľa pri iniciovanej požiadavke a dočasný port klienta patrí do poľa zdroja. Model s cieľom TCP 500 opisuje aplikáciu TCP, ktorá počúva na 500; nestane sa testom IKE len preto, že sa číslo objaví v príkaze.

Krok 3: čítajte fázy v poradí

Každá fáza vo výstupe je rozhodnutie s vlastníkom: hľadanie trasy, ACL, NAT a potom výber VPN alebo tunela. Čítajte ich v tlačenom poradí a zastavte sa pri prvej fáze, ktorá nezodpovedá návrhu.

NAT ľudí často nachytá. Ak preložený zdroj padne mimo crypto ACL, ktoré vyberá prevádzku pre tunel, tok môže byť povolený a nikdy nebude zapuzdrený. Trasovanie tlačí preloženú adresu, takže ju porovnajte so zaujímavou prevádzkou tunela, nie s pôvodnou adresou.

Krok 4: skontrolujte, ktoré obchádzania ste zvolili

Forma detailed prijíma možnosti, ktoré preskakujú kontroly, a Cisco dokumentuje možnosť bypass-checks pokrývajúcu ACL, filter VPN, uRPF a kontroly podvrhnutia IPsec. ALLOW získaný s nimi preskočenými hovorí, že trasa a NAT by fungovali, nie že by politika prijala skutočný paket. Zapíšte možnosti vedľa výsledku.

Ak potrebujete odpoveď politiky, spustite to bez obchádzaní. Ak izolujete otázku smerovania, spustite to s nimi a označte výsledok ako odpoveď o smerovaní.

Krok 5: uzavrite medzeru skutočnou výmenou

Simulované povolenie končí na ASA. Či vzdialená brána paket dešifrovala, či server spojenie prijal a či sa vrátila odpoveď, sú oddelené pozorovania. Použite počítadlá koncových bodov alebo úzke zachytenie na schválenej ceste.

Niektoré možnosti trace a replay prenášajú pakety alebo uchovávajú stav. Postupujte podľa dokumentovaného správania pre vašu verziu a schválený diagnostický postup, namiesto toho, aby ste každý variant brali ako iba čítací dotaz.

Čo vám trasovanie stále nemôže povedať

Držte štyri veci v jednej poznámke: tuple, zodpovedajúce pravidlo NAT, tunel alebo politiku, ktorá má tok niesť, a pozorovanie špecifické pre smer. Bez nich neskorší inžinier nedokáže oddeliť miestne rozhodnutie o politike od zavedenej riadiacej roviny a od fungujúcej služby. Prvé zlyhanie nasledované úspechom tiež nie je dôkazom, že tunel musel medzitým vzniknúť; zapíšte fázu a zmenu stavu.

Začnite vnútorným tuplom, zastavte sa pri prvej fáze, ktorá odporuje návrhu, a až potom siahnite po dôkazoch z koncových bodov. Trasovanie je orákulum politiky, nie potvrdenie o doručení.