Korleis modellere ein VPN-straum med ASA packet-tracer

Packet-tracer på ein ASA svarar på eit smalt spørsmål: ville denne pakken, som kjem inn her med denne tuple, vere tillaten, og kvar ville han gå. Han svarar ikkje på om den fjerne enden får noko. Den vanlege feilen er å gje han ein ytre IKE-tuple når det du vil teste er applikasjonen som går inne i tunnelen. Rett tuple først, les fasane, og skaff deretter ekte prov for alt simulatoren ikkje kan sjå.

Gjennomgangen nedanfor føreset at ACL, NAT-regelen og tunnel-group-konteksten ligg framfor deg. Utan dei skildrar utdata ein policy du ikkje kan kontrollere.

Steg 1: skriv den indre straumen med enkle ord

Skildre applikasjonen før du skriv noko. Ein vert på innsida som opnar SSH til ein tenar bak den fjerne gatewayen, er éin indre TCP-straum med ein bestemt kjeldeport. Det er straumen ACL og VPN-filteret vurderer, så det er straumen du skriv.

Skriv han som ei setning, og omset han deretter felt for felt:

packet-tracer input inside tcp 10.30.0.25 53000 10.40.0.50 22 detailed

Steg 2: vel inngangsgrensesnittet og retninga

Inngang er grensesnittet pakken kjem inn på, ikkje det han forlèt via. For ein LAN-vert som startar, er det inside-grensesnittet. For returpakken i same sesjon er det outside-grensesnittet, og tuple blir snudd. Å skrive destinasjonen som kjelda er den nest vanlegaste måten å få ein overtydande, men irrelevant ALLOW.

Portar er også retningsbestemte. Tenesteporten høyrer til destinasjonsfeltet ved ein initiert førespurnad, og den efemere porten til klienten høyrer til kjeldeteltet. Ein modell med TCP-destinasjon 500 skildrar ein TCP-applikasjon som lyttar på 500; han blir ikkje ein IKE-test fordi talet viser seg i kommandoen.

Steg 3: les fasane i rekkjefølgje

Kvar fase i utdata er eit vedtak med ein eigar: ruteoppslag, ACL, NAT, deretter VPN- eller tunnelval. Les dei i den trykte rekkjefølgja og stopp ved den første fasen som er usamd med designet.

NAT lurar folk. Viss den omsette kjelda fell utanfor crypto-ACL-en som vel trafikk for tunnelen, kan straumen bli tillaten og aldri innkapsla. Sporinga skriv ut den omsette adressa, så samanlikn henne med den interessante trafikken til tunnelen i staden for med den opphavlege adressa.

Steg 4: kontroller kva omkøyringar du valde

Forma detailed tek alternativ som hoppar over kontrollar, og Cisco dokumenterer eit bypass-checks-alternativ som dekkjer ACL, VPN-filter, uRPF og IPsec-spoofkontrollar. Ein ALLOW henta med desse omkøyringane seier at ruta og NAT ville verke, ikkje at policyen ville sleppe inn ein ekte pakke. Noter alternativa ved sida av resultatet.

Viss du treng policy-svaret, køyr det utan omkøyringane. Viss du isolerer eit rutespørsmål, køyr det med dei og merk resultatet som eit rutesvar.

Steg 5: lukk gapet med den ekte utvekslinga

Ei simulert tillating stoppar ved ASA-en. Om den fjerne gatewayen dekrypterte pakken, om tenaren godtok sambandet, og om det kom eit svar tilbake, er separate observasjonar. Bruk endepunktsteljarar eller eit smalt opptak på ein godkjend veg.

Nokre trace- og replay-alternativ overfører pakkar eller bevarer tilstand. Følg den dokumenterte åtferda for versjonen din og den godkjende diagnostiske prosedyren din i staden for å handsame kvar variant som eit skriveverna oppslag.

Kva sporinga framleis ikkje kan fortelje deg

Hald fire ting i eitt notat: tuple, den samsvarande NAT-regelen, tunnelen eller policyen som skal bere straumen, og den retningsspesifikke observasjonen. Utan dei kan ein seinare ingeniør ikkje skilje eit lokalt policyvedtak frå eit etablert kontrollplan og frå ein fungerande teneste. Ein første feil etterfølgd av ein suksess er heller ikkje prov for at tunnelen måtte kome opp imellom; noter fasen og tilstandsendringa.

Start med den indre tuple, stopp ved den første fasen som motset designet, og grip først då etter endepunktprov. Sporinga er eit policy-orakel, ikkje ein leveringskvittering.