Trenger ruteren mellom to IPsec-peers IPsec?

En laboratorieøvelse som sier «konfigurer IPsec mellom to nettsteder» skjuler to forskjellige oppgaver. De to endepunktene avslutter tunnelen: de forhandler, autentiserer, krypterer og dekrypterer. Enhver ruter imellom videresender pakker hvis ytre header tilhører endepunktene, og den gjør det uten å vite at tunnelen finnes.

Å avgjøre hvilken oppgave en enhet blir bedt om, er det første trinnet i øvelsen. Mesteparten av forvirringen i laboratorierapporter, og en god del av forvirringen i produksjonsdiagrammer, kommer av å behandle «støtter IPsec» som én egenskap i stedet for to.

Videresending er ikke avslutning

I tunnelmodus er den ytre IP-headeren adressert til enhetene som avslutter tunnelen. En ruter i midten slår opp destinasjonen og videresender, akkurat som for enhver annen pakke, og nyttelasten den bærer er ugjennomsiktig for den.

Den ugjennomsiktigheten er tilsiktet. Ruteren har ikke peerens hemmelighet, kjører ingen forhandling og trenger ingen policybase. Den trenger en rute mot det fjerne endepunktet og tillatelse til å videresende pakken.

Å blande de to fører til reelle feil: å be en transitbrannmur «tillate IPsec» når det faktiske kravet er å tillate protokoll 50 mellom bestemte adresser, eller å forvente at en mellomliggende enhet dekrypterer for inspeksjon når den ikke har noen nøkkel.

Hva mellomliggende enhet likevel må få riktig

Videresending har sine egne krav. Ruter må nå begge de ytre endepunktene, og enhver policy langs veien må tillate den faktiske ytre trafikken i stedet for et gjettet portnummer. En regel skrevet mot TCP 443 fordi noen antok TLS, vil ikke samsvare med protokoll 50.

Innebygd ESP er IP-protokoll 50. Det er ikke TCP 50 og ikke UDP 50, og en regel som blokkerer ikke-TCP-trafikk vil slippe den. Hvis designet bruker UDP-innkapsling, endres den synlige transporten til innkapslingsporten, og policyen må samsvare med det valgte designet.

Pakkestørrelsen spiller også inn. En rute som bærer en liten sondering beviser ikke at hele den innkapslede utvekslingen får plass. En vei som slipper store pakker kan la forhandlingen lykkes og arbeidslasten feile, noe som ser ut som et programproblem. Test med trafikk på størrelse med den reelle arbeidslasten før du skylder på tunnelen.

Hvorfor simulatoren endrer spørsmålet

En simulator er ikke en ruter med kortere funksjonsliste; den er en modell med et dokumentert delsett og egne regler for hva en gitt enhet kan konfigureres til å gjøre. Ciscos Packet Tracer-FAQ sier uttrykkelig at enheter og protokoller er forenklede modeller.

Så blir spørsmålet tre spørsmål. Videresender den simulerte enheten pakkene scenariet trenger? Tilbyr samme enhet den konfigurasjonsflaten leksjonen forutsetter? Og betyr den aksepterte kommandoen at atferden faktisk simuleres, eller bare parses?

En manglende kommando kan være en modellbegrensning snarere enn en feil i konfigurasjonen din. En eksisterende kommando kan godta syntaks uten å gjengi all produksjonsatferd. Sjekk enhetshjelpen for den installerte versjonen før du konkluderer i noen retning.

Å skrive et bestått-kriterium for labben

For en underlay-leksjon er bestått-kriteriet at endepunktene nås, pluss de ytre pakkene som passerer mellomliggende enhet. Bevis det med simulatorens egne tellere eller en pakkevisning, og navngi protokollen du forventer å se.

For en IPsec-leksjon legger du til forhandlingstilstanden og én beskyttet LAN-til-LAN-strøm. Hvis simulatoren viser sikkerhetsassosiasjoner, registrer dem. Hvis ikke, si det i rapporten i stedet for å antyde at tunnelen ble verifisert.

Ta vare på simulatorversjonen, de valgte enhetene og læringsmålet sammen med topologifilen. Det er den registreringen som gjør at noen andre kan gjenskape øvelsen og forstå hvilke deler som ble modellert.

Produksjonskonfigurasjon trenger sine egne plattformsbevis. En grønn simulert pakke er et undervisningsresultat, ikke en kompatibilitetserklæring om maskinvaren du kommer til å rulle ut.