Sådan modellerer du en VPN-strøm med ASA packet-tracer

Packet-tracer på en ASA svarer på et snævert spørgsmål: ville denne pakke, der kommer ind her med denne tuple, være tilladt, og hvor ville den gå hen. Den svarer ikke på, om den fjerne ende modtager noget. Den sædvanlige fejl er at fodre den med en ydre IKE-tuple, når det, du vil teste, er applikationen, der kører inde i tunnelen. Ret tuple først, læs faserne, og skaf derefter rigtige beviser for alt, hvad simulatoren ikke kan se.

Gennemgangen nedenfor forudsætter, at ACL, NAT-reglen og tunnel-group-konteksten ligger foran dig. Uden dem beskriver outputtet en politik, du ikke kan kontrollere.

Trin 1: skriv den indre strøm med enkle ord

Beskriv applikationen, før du skriver noget. En vært på indersiden, der åbner SSH til en server bag den fjerne gateway, er én indre TCP-strøm med en bestemt kildeport. Det er den strøm, ACL og VPN-filteret vurderer, så det er den strøm, du skriver.

Skriv den som en sætning, og oversæt den derefter felt for felt:

packet-tracer input inside tcp 10.30.0.25 53000 10.40.0.50 22 detailed

Trin 2: vælg indgangsgrænsefladen og retningen

Indgang er den grænseflade, pakken ankommer på, ikke den, den forlader via. For en LAN-vært, der starter, er det inside-grænsefladen. For returpakken i samme session er det outside-grænsefladen, og tuple vendes. At skrive destinationen som kilden er den næstmest almindelige måde at opnå et overbevisende, men irrelevant ALLOW.

Porte er også retningsbestemte. Serviceporten hører til destinationsfeltet ved en igangsat anmodning, og klientens efemere port hører til kildefeltet. En model med TCP-destination 500 beskriver en TCP-applikation, der lytter på 500; den bliver ikke en IKE-test, fordi tallet optræder i kommandoen.

Trin 3: læs faserne i rækkefølge

Hver fase i outputtet er en beslutning med en ejer: ruteopslag, ACL, NAT og derefter valg af VPN eller tunnel. Læs dem i den trykte rækkefølge, og stop ved den første fase, der er uenig med designet.

NAT snyder folk. Hvis den oversatte kilde falder uden for den crypto-ACL, der vælger trafik til tunnelen, kan strømmen blive tilladt og aldrig indkapslet. Sporingen udskriver den oversatte adresse, så sammenlign den med tunnelens interessante trafik i stedet for med den oprindelige adresse.

Trin 4: kontroller, hvilke omgåelser du valgte

Formen detailed tager muligheder, der springer kontroller over, og Cisco dokumenterer en bypass-checks-mulighed, der dækker ACL, VPN-filter, uRPF og IPsec-spoofkontroller. Et ALLOW opnået med dem omgået siger, at ruten og NAT ville virke, ikke at politikken ville admittere en rigtig pakke. Notér mulighederne ved siden af resultatet.

Hvis du har brug for politiksvaret, så kør det uden omgåelserne. Hvis du isolerer et routing-spørgsmål, så kør det med dem, og mærk resultatet som et routing-svar.

Trin 5: luk hullet med den rigtige udveksling

En simuleret tilladelse stopper ved ASA'en. Om den fjerne gateway dekrypterede pakken, om serveren accepterede forbindelsen, og om der kom et svar tilbage, er separate observationer. Brug endepunkts-tællere eller en smal optagelse på en godkendt vej.

Nogle trace- og replay-muligheder transmitterer pakker eller bevarer tilstand. Følg den dokumenterede adfærd for din version og din godkendte diagnostiske procedure i stedet for at behandle hver variant som et skrivebeskyttet opslag.

Hvad sporingen stadig ikke kan fortælle dig

Hold fire ting i ét notat: tuple, den matchede NAT-regel, den tunnel eller politik, der skulle bære strømmen, og den retningsspecifikke observation. Uden dem kan en senere ingeniør ikke skelne en lokal politikbeslutning fra et etableret kontrolplan og fra en fungerende tjeneste. En første fejl efterfulgt af en succes er heller ikke bevis for, at tunnelen måtte komme op indimellem; notér fasen og tilstandsændringen.

Start med den indre tuple, stop ved den første fase, der modsiger designet, og ræk først derefter ud efter endepunktsbeviser. Sporingen er et politik-orakel, ikke en leveringskvittering.