Treng rutaren mellom to IPsec-partnarar IPsec?

Ein laboratorieøving som seier «konfigurer IPsec mellom to nettstader» gøymer to ulike oppgåver. Dei to endepunkta avsluttar tunnelen: dei forhandlar, autentiserer, krypterer og dekrypterer. Kvar ruter imellom sender vidare pakkar der den ytre headeren høyrer til endepunkta, og han gjer det utan å vite at tunnelen finst.

Å avgjere kva oppgåve ein eining blir bede om, er det første trinnet i øvinga. Mesteparten av forvirringa i laboratorierapportar, og ein god del av forvirringa i produksjonsdiagram, kjem av å handsame «støttar IPsec» som éin eigenskap i staden for to.

Vidaresending er ikkje avslutting

I tunnelmodus er den ytre IP-headeren adressert til einingane som avsluttar tunnelen. Ein ruter i midten slår opp destinasjonen og sender vidare, akkurat som for kvar annan pakke, og nyttelasta han ber er ugjennomsiktig for han.

Den ugjennomsiktigheita er tilsikta. Rutaren har ikkje hemmelegheita til partnaren, køyrer inga forhandling og treng ingen policybase. Han treng ei rute mot det fjerne endepunktet og løyve til å senda pakken vidare.

Å blanda dei to fører til reelle feil: å be ein transitbrannmur «tillate IPsec» når det faktiske kravet er å tillate protokoll 50 mellom bestemte adresser, eller å vente at ei mellomliggjande eining dekrypterer for inspeksjon når ho ikkje har nokon nøkkel.

Kva mellomliggjande eining likevel må få rett

Vidaresending har sine eigne krav. Ruter må nå begge dei ytre endepunkta, og kvar policy langs vegen må tillate den faktiske ytre trafikken i staden for eit gjeta portnummer. Ein regel skriven mot TCP 443 fordi nokon antok TLS, vil ikkje samsvare med protokoll 50.

Innebygd ESP er IP-protokoll 50. Det er ikkje TCP 50 og ikkje UDP 50, og ein regel som blokkerer ikkje-TCP-trafikk vil sleppe han. Viss designet brukar UDP-innkapsling, endrar den synlege transporten seg til innkapslingsporten, og policyen må samsvare med det valde designet.

Pakkestorleiken spelar også inn. Ei rute som ber ei lita sondering provar ikkje at heile den innkapsla utvekslinga får plass. Ein veg som slepp store pakkar kan la forhandlinga lukkast og arbeidslasta feile, noko som ser ut som eit programproblem. Test med trafikk på storleik med den reelle arbeidslasta før du skuldar på tunnelen.

Kvifor simulatoren endrar spørsmålet

Ein simulator er ikkje ein ruter med kortare funksjonsliste; han er ein modell med eit dokumentert delsett og eigne reglar for kva ei gitt eining kan konfigurerast til å gjere. Ciscos Packet Tracer-FAQ seier uttrykkeleg at einingar og protokollar er forenkla modellar.

Så blir spørsmålet tre spørsmål. Sender den simulerte eininga vidare pakkane scenariet treng? Tilbyr same eining den konfigurasjonsflata leksjonen føreset? Og betyr den aksepterte kommandoen at åtferda faktisk blir simulert, eller berre parsa?

Ein manglande kommando kan vere ei modellgrense snarare enn ein feil i konfigurasjonen din. Ein eksisterande kommando kan godta syntaks utan å gjengi all produksjonsåtferd. Sjekk eininghjelpa for den installerte versjonen før du konkluderer i noka retning.

Å skrive eit bestått-kriterium for labben

For ein underlay-leksjon er bestått-kriteriet at endepunkta blir nådde, pluss dei ytre pakkane som passerer mellomliggjande eining. Prov det med simulatorens eigne teljarar eller ei pakkevising, og namnge protokollen du ventar å sjå.

For ein IPsec-leksjon legg du til forhandlingstilstanden og éin verna LAN-til-LAN-straum. Viss simulatoren viser tryggingsassosiasjonar, registrer dei. Viss ikkje, sei det i rapporten i staden for å antyde at tunnelen vart verifisert.

Ta vare på simulatorversjonen, dei valde einingane og læringsmålet saman med topologifila. Det er den registreringa som gjer at nokon andre kan gjenskape øvinga og forstå kva delar som vart modellerte.

Produksjonskonfigurasjon treng sine eigne plattformsprov. Ein grøn simulert pakke er eit undervisningsresultat, ikkje ei kompatibilitetserklæring om maskinvara du kjem til å rulle ut.