IPsec i IPsec: kva adresser den ytre tunnelen må bera

Nesta IPsec er lettare å tenkje gjennom når dei to laga terminerer på ulike maskinar. Fire gatewayar, to tunnelar og eitt spørsmål som avgjer om designet verkar: kva ser den ytre tunnelen eigentleg når den indre er ferdig med pakken? Svar på det, og selektorane, rutene og feilsøkingsrekkjefølgja følgjer. Tek du feil, brukar du ein dag på å feilsøkje ein tunnel som teknisk sett er oppe.

Modellen med fire gatewayar

Dei ytre gatewayane A og B byggjer den første tunnelen mellom dei to stadene. Bak A sit den indre gatewayen C med transittadresse 10.60.0.2; bak B sit den indre gatewayen D med transittadresse 10.70.0.2. Applikasjonsnetta ligg bak C og D, og kvar adresse i dømet overlappar med vilje ikkje.

application net -> C -> A == outer IPsec == B -> D -> application net
                       \---------- inner IPsec ----------/

C transit: 10.60.0.2      D transit: 10.70.0.2
A and B:    underlay addresses only

Å dele laga på fire vertar tyder at kvar maskin handhevar éi grense. Éin vert som køyrer begge laga må sameine to sett policyar, to rutetabellar og to feilmodusar på éi maskin, noko som er mogleg og mykje vanskelegare å observere.

Kvart lag fjernar berre si eiga vern

C krypterer ein applikasjonspakke for D. Resultatet er adressert frå C til D, og det er det som når A. Alt nedstraums avheng av den omskrivinga.

A krypterer han på nytt for B. B dekrypterer det ytre laget, ser ein pakke frå C til D og videresender han framleis kryptert. D fjernar det indre vernet og leverer applikasjonspakken.

Så A og B ser dei indre endepunkta og metadataa deira, men er ikkje partane som dekrypterer applikasjonsnyttelasta. Det er ein reell eigenskap ved designet og ikkje ein påstand om at C, D eller applikasjonsvertane er pålitelege.

Dei ytre selektorane namngjev dei indre gatewayane

Det er her dei fleste av desse oppsetta feilar. For ein policybasert ytre tunnel må selektorane du forhandlar innehalde adressene A og B faktisk handterer: 10.60.0.2/32 og 10.70.0.2/32, i rett lokal og ekstern rekkjefølgje.

Å setje dei endelege applikasjonssubnetta i dei ytre selektorane verkar ikkje, for når ein pakke når A, har den indre innkapslinga alt skrive om det A må verne. Den ytre policyen ville då ikkje matche noko, og tunnelen ville kome opp utan å bera data.

Ikkje snevra inn den ytre løyva til UDP 500. Den indre sambindinga har sin eigen datastig, som brukar ESP eller UDP-innkapsling avhengig av kva ho forhandla, og den ytre policyen må tillate den protokollen.

Kontroller resultatet med swanctl --list-sas på kvar gateway og stadfest at child-tryggingsassosiasjonane rapporterer adressene du meinte, ikkje dei du antok. Viss lista viser applikasjonssubnetta, er den ytre policyen skriven for feil lag. Rett selektorane før du feilsøkjer ruting, for rutinga vil sjå fin ut og teljarane vil ikkje flytte seg.

Videresending og rekursjonsfella

Selektorar erstattar ikkje ruting. A og B må videresende trafikk mellom C og D i begge retningar, noko som tyder aktivert IP-videresending, ruter som peikar på tunnelen og ein returveg som finst på den andre sida.

Viss den ytre tunnelen brukar XFRM-grensesnitt, vel rutene grensesnittet medan dei forhandla policyane framleis avgrensar kva det ber. Eit grensesnitt utvidar ikkje det verna; det endrar berre korleis kjernen plukkar opp pakken.

Fella er rekursjon. Ruta til A til det ytre endepunktet til B må fylgje underlaget, ikkje tunnelen A byggjer, elles prøver innkapslinga å reise inne i seg sjølv, og sambindinga blir aldri fullført.

Inspiser omsetjing før du legg til lag

Sjå på kvar kjelde-NAT på A og B før du justerer noko anna. Ein regel som skriv om adressa til C før IPsec-policyen blir brukt, kan øydeleggje dei avtalte selektorane, og han kan òg endre kva D mottek på den andre sida.

Brei masking blir ikkje tryggare av å ha to lag. Ho skjuler kva adresse fjernenden ser, og det er nettopp informasjonen du treng når tunnelen er oppe og applikasjonen ikkje er det.

Viss ein NAT-regel verkeleg er nødvendig, skriv ned kva adresse kvar side trur ho snakkar med. Den eine linja avgjer dei fleste diskusjonane om det er tunnelen eller omsetjinga som er skuld i det. Ho fortel òg den neste ingeniøren kvar det skal sjåast når regelen blir fjerna eit år seinare. Ein ping gjer ingenting av dette.

Prov fail-closed og kontroller MTU

Ei rute som forsvinn er ikkje i seg sjølv ein fail-closed-policy. Ein annan tabell, ei standardrute eller ein policyregel kan stille gje ein reserveveg, og den einaste måten å vite det på er å ta den ytre tunnelen ned og observere kva applikasjonstrafikken gjer. Gjer det med vilje, i eit vindauge, i staden for å oppdage det ved eit uhell.

Test tre tilstandar: ytre tunnel nede, indre tunnel nede og attoppretting etter at begge kjem tilbake. Bruk policyteljarar på kvar gateway, for to etablerte IKE-øktar beviser berre at forhandlinga på kontrollplanet lukkast.

Budsjetter for begge innkapslingane. Fungerande IKE er eit småpakkeresultat, og applikasjonspakkar i full storleik kan framleis feile når to headarar blir lagde til; test med ein kjend nyttelaststorleik på den verkelege vegen i staden for å anta at tala går opp. Aritmetikken er lett, vegen er ikkje.