Skal routeren mellem to IPsec-peers have IPsec?

En laboratorieøvelse, der siger “konfigurer IPsec mellem to steder”, skjuler to forskellige opgaver. De to endepunkter afslutter tunnelen: de forhandler, autentificerer, krypterer og dekrypterer. Enhver router ind imellem videresender pakker, hvis ydre header tilhører endepunkterne, og den gør det uden at vide, at tunnelen findes.

At afgøre, hvilken opgave en enhed bliver bedt om, er det første skridt i øvelsen. Det meste forvirring i laboratorierapporter, og en god del af forvirringen i produktionsdiagrammer, kommer af at behandle “understøtter IPsec” som én egenskab i stedet for to.

Videresendelse er ikke afslutning

I tunnelmode er den ydre IP-header adresseret til de afsluttende enheder. En router i midten slår destinationen op og videresender, præcis som for enhver anden pakke, og den nyttelast, den bærer, er uigennemsigtig for den.

Den uigennemsigtighed er bevidst. Routeren har ikke peerens hemmelighed, kører ikke en forhandling og har ikke brug for en politikdatabase. Den har brug for en rute mod det fjerne endepunkt og tilladelse til at videresende pakken.

At forveksle de to fører til reelle fejl: at bede en transitfirewall om at “tillade IPsec”, når det faktiske krav er at tillade protokol 50 mellem bestemte adresser, eller at forvente, at en mellemenhed dekrypterer til inspektion, når den ikke har nogen nøgle.

Hvad mellemenheden stadig skal have styr på

Videresendelse har sine egne krav. Ruter skal nå begge eksterne endepunkter, og enhver politik undervejs skal tillade den faktiske ydre trafik i stedet for et gættet portnummer. En regel skrevet mod TCP 443, fordi nogen antog TLS, vil ikke matche protokol 50.

Indfødt ESP er IP-protokol 50. Det er ikke TCP 50 og ikke UDP 50, og en regel, der blokerer ikke-TCP-trafik, vil droppe den. Hvis designet bruger UDP-indkapsling, ændres den synlige transport til indkapslingsporten, og politikken skal matche det valgte design.

Pakkestørrelse betyder også noget. En rute, der bærer en lille probe, beviser ikke, at hele den indkapslede udveksling kan være der. En vej, der dropper store pakker, kan lade forhandlingen lykkes og arbejdsbyrden fejle, hvilket ligner et applikationsproblem. Test med trafik af samme størrelse som den reelle arbejdsbyrde, før du giver tunnelen skylden.

Hvorfor simulatoren ændrer spørgsmålet

En simulator er ikke en router med en kortere funktionsliste; det er en model med en dokumenteret delmængde og sine egne regler for, hvad en given enhed kan konfigureres til at gøre. Ciscos Packet Tracer-FAQ siger udtrykkeligt, at enheder og protokoller er forenklede modeller.

Så spørgsmålet bliver tre spørgsmål. Videresender den simulerede enhed de pakker, scenariet har brug for? Tilbyder samme enhed den konfigurationsflade, lektionen forudsætter? Og betyder den accepterede kommando, at adfærden faktisk simuleres, eller kun parses?

En manglende kommando kan være en modelbegrænsning snarere end en fejl i din konfiguration. En tilstedeværende kommando kan acceptere syntaks uden at gengive enhver produktionsadfærd. Kontroller den installerede versions enhedshjælp, før du konkluderer noget.

At skrive en beståelsesbetingelse til laboratoriet

For en underlay-lektion er beståelsesbetingelsen, at endepunkterne kan nås, plus at de ydre pakker krydser mellemenheden. Bevis det med simulatorens egne tællere eller en pakkevisning, og navngiv den protokol, du forventer at se.

For en IPsec-lektion tilføjer du forhandlingstilstanden og et beskyttet LAN-til-LAN-flow. Hvis simulatoren viser sikkerhedsassociationer, skal du registrere dem. Hvis ikke, så sig det i rapporten i stedet for at antyde, at tunnelen blev verificeret.

Gem simulatorversionen, de valgte enheder og læringsmålet sammen med topologifilen. Den registrering er det, der lader andre genskabe øvelsen og forstå, hvilke dele der blev modelleret.

Produktionskonfiguration kræver sine egne platformbeviser. En grøn simuleret pakke er et undervisningsresultat, ikke en kompatibilitetserklæring om det hardware, du vil udrulle.