Så modellerar du ett VPN-flöde med ASA packet-tracer

Packet-tracer på en ASA svarar på en smal fråga: skulle detta paket, som kommer in här med denna tuple, tillåtas, och vart skulle det gå. Den svarar inte på om den fjärran änden tar emot något. Det vanliga misstaget är att mata in en yttre IKE-tuple när det du vill testa är applikationen som går inuti tunneln. Rätta tuple först, läs faserna och skaffa sedan riktiga bevis för allt som simulatorn inte kan se.

Genomgången nedan förutsätter att ACL, NAT-regeln och tunnel-group-kontexten ligger framför dig. Utan dem beskriver utdata en policy du inte kan kontrollera.

Steg 1: skriv det inre flödet med enkla ord

Beskriv applikationen innan du skriver något. En värd på insidan som öppnar SSH till en server bakom den fjärran gatewayen är ett inre TCP-flöde med en bestämd källport. Det är flödet som ACL och VPN-filtret utvärderar, så det är flödet du skriver.

Skriv det som en mening och översätt det sedan fält för fält:

packet-tracer input inside tcp 10.30.0.25 53000 10.40.0.50 22 detailed

Steg 2: välj ingångsgränssnittet och riktningen

Ingång är gränssnittet paketet anländer på, inte det det lämnar via. För en LAN-värd som startar är det inside-gränssnittet. För returpaketet i samma session är det outside-gränssnittet, och tuple vänds. Att skriva destinationen som källan är det näst vanligaste sättet att få ett övertygande men irrelevant ALLOW.

Portar är också riktningsbestämda. Tjänsteporten hör till destinationsfältet vid en initierad begäran, och klientens efemära port hör till källfältet. En modell med TCP-destination 500 beskriver en TCP-applikation som lyssnar på 500; den blir inte ett IKE-test bara för att talet visas i kommandot.

Steg 3: läs faserna i ordning

Varje fas i utdata är ett beslut med en ägare: ruttuppslag, ACL, NAT och sedan val av VPN eller tunnel. Läs dem i den utskrivna ordningen och stanna vid den första fasen som inte stämmer med designen.

NAT lurar folk. Om den översatta källan hamnar utanför den crypto ACL som väljer trafik för tunneln kan flödet tillåtas och aldrig kapslas in. Spårningen skriver ut den översatta adressen, så jämför den med tunnelns intressanta trafik i stället för med den ursprungliga adressen.

Steg 4: kontrollera vilka kringgåenden du valde

Formen detailed tar alternativ som hoppar över kontroller, och Cisco dokumenterar ett bypass-checks-alternativ som täcker ACL, VPN-filter, uRPF och IPsec-spoofkontroller. Ett ALLOW som erhålls med dessa kringgåenden säger att rutten och NAT skulle fungera, inte att policyn skulle släppa igenom ett riktigt paket. Notera alternativen bredvid resultatet.

Om du behöver policy-svaret, kör utan kringgåendena. Om du isolerar en routningsfråga, kör med dem och märk resultatet som ett routningssvar.

Steg 5: stäng gapet med det verkliga utbytet

Ett simulerat tillstånd stannar vid ASA:n. Om den fjärran gatewayen dekrypterade paketet, om servern accepterade anslutningen och om ett svar kom tillbaka är separata observationer. Använd slutpunktstäljare eller en smal inspelning på en godkänd väg.

Vissa trace- och replay-alternativ överför paket eller bevarar tillstånd. Följ det dokumenterade beteendet för din version och ditt godkända diagnostiska förfarande i stället för att behandla varje variant som en skrivskyddad sökning.

Vad spårningen fortfarande inte kan berätta

Håll fyra saker i en anteckning: tuple, den matchande NAT-regeln, tunneln eller policyn som ska bära flödet och den riktningsspecifika observationen. Utan dem kan en senare ingenjör inte skilja ett lokalt policybeslut från ett etablerat kontrollplan och från en fungerande tjänst. Ett första misslyckande följt av en framgång är heller inget bevis för att tunneln måste komma upp däremellan; notera fasen och tillståndsändringen.

Börja med den inre tuple, stanna vid den första fasen som motsäger designen och grip först då efter slutpunktsbevis. Spårningen är ett policy-orakel, inte ett leveranskvitto.