Slik modellerer du en VPN-flyt med ASA packet-tracer

Packet-tracer på en ASA svarer på et smalt spørsmål: ville denne pakken, som kommer inn her med denne tuple, være tillatt, og hvor ville den gå. Den svarer ikke på om den fjerne enden mottar noe. Den vanlige feilen er å gi den en ytre IKE-tuple når det du vil teste er applikasjonen som går inne i tunnelen. Rett tuple først, les fasene, og skaff deretter ekte bevis for alt simulatoren ikke kan se.

Gjennomgangen nedenfor forutsetter at ACL, NAT-regelen og tunnel-group-konteksten ligger foran deg. Uten dem beskriver utdata en policy du ikke kan kontrollere.

Trinn 1: skriv den indre flyten med enkle ord

Beskriv applikasjonen før du skriver noe. En vert på innsiden som åpner SSH til en server bak den fjerne gatewayen, er én indre TCP-flyt med en bestemt kildeport. Det er flyten ACL og VPN-filteret vurderer, så det er flyten du skriver.

Skriv den som en setning, og oversett den deretter felt for felt:

packet-tracer input inside tcp 10.30.0.25 53000 10.40.0.50 22 detailed

Trinn 2: velg inngangsgrensesnittet og retningen

Inngang er grensesnittet pakken ankommer på, ikke det den forlater via. For en LAN-vert som starter, er det inside-grensesnittet. For returpakken i samme sesjon er det outside-grensesnittet, og tuple snus. Å skrive destinasjonen som kilden er den nest vanligste måten å få en overbevisende, men irrelevant ALLOW.

Porter er også retningsbestemte. Tjenesteporten hører til destinasjonsfeltet ved en initiert forespørsel, og klientens efemere port hører til kildefeltet. En modell med TCP-destinasjon 500 beskriver en TCP-applikasjon som lytter på 500; den blir ikke en IKE-test fordi tallet vises i kommandoen.

Trinn 3: les fasene i rekkefølge

Hver fase i utdata er en beslutning med en eier: ruteoppslag, ACL, NAT, deretter VPN- eller tunnelvalg. Les dem i den trykte rekkefølgen og stopp ved den første fasen som er uenig med designet.

NAT lurer folk. Hvis den oversatte kilden faller utenfor crypto-ACL-en som velger trafikk for tunnelen, kan flyten bli tillatt og aldri innkapslet. Sporingen skriver ut den oversatte adressen, så sammenlign den med tunnelens interessante trafikk i stedet for med den opprinnelige adressen.

Trinn 4: kontroller hvilke omgåelser du valgte

Formen detailed tar alternativer som hopper over kontroller, og Cisco dokumenterer et bypass-checks-alternativ som dekker ACL, VPN-filter, uRPF og IPsec-spoofkontroller. En ALLOW hentet med disse omgått sier at ruten og NAT ville virke, ikke at policyen ville tillate en ekte pakke. Noter alternativene ved siden av resultatet.

Hvis du trenger policy-svaret, kjør det uten omgåelsene. Hvis du isolerer et rutespørsmål, kjør det med dem og merk resultatet som et rutesvar.

Trinn 5: lukk gapet med den ekte utvekslingen

En simulert tillatelse stopper ved ASA-en. Om den fjerne gatewayen dekrypterte pakken, om serveren godtok forbindelsen, og om det kom et svar tilbake, er separate observasjoner. Bruk endepunktstellere eller en smal opptak på en godkjent vei.

Noen trace- og replay-alternativer overfører pakker eller bevarer tilstand. Følg den dokumenterte oppførselen for din versjon og din godkjente diagnostiske prosedyre i stedet for å behandle hver variant som et skrivebeskyttet oppslag.

Hva sporingen fortsatt ikke kan fortelle deg

Hold fire ting i ett notat: tuple, den matchende NAT-regelen, tunnelen eller policyen som skal bære flyten, og den retningsspesifikke observasjonen. Uten dem kan en senere ingeniør ikke skille en lokal policybeslutning fra et etablert kontrollplan og fra en fungerende tjeneste. En første feil etterfulgt av en suksess er heller ikke bevis for at tunnelen måtte komme opp imellom; noter fasen og tilstandsendringen.

Start med den indre tuple, stopp ved den første fasen som motsier designet, og først da grip etter endepunktbevis. Sporingen er et policy-orakel, ikke en leveringskvittering.