IPsec i IPsec: hvilke adresser må den ytre tunnelen bære

Nestet IPsec er lettere å resonnere om når de to lagene terminerer på forskjellige maskiner. Fire gatewayer, to tunneler og ett spørsmål som avgjør om designet virker: hva ser den ytre tunnelen egentlig når den indre er ferdig med pakken? Svar på det, og selektorene, rutene og feilsøkingsrekkefølgen følger. Tar du feil, bruker du en dag på å feilsøke en tunnel som teknisk sett er oppe.

Modellen med fire gatewayer

De ytre gatewayene A og B bygger den første tunnelen mellom de to stedene. Bak A sitter den indre gatewayen C med transittadresse 10.60.0.2; bak B sitter den indre gatewayen D med transittadresse 10.70.0.2. Applikasjonsnettene ligger bak C og D, og hver adresse i eksemplet overlapper bevisst ikke.

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 lagene på fire verter betyr at hver maskin håndhever én grense. Én vert som kjører begge lagene må forene to sett med policyer, to rutetabeller og to feilmoduser på én maskin, noe som er mulig og mye vanskeligere å observere.

Hvert lag fjerner bare sin egen beskyttelse

C krypterer en applikasjonspakke for D. Resultatet er adressert fra C til D, og det er det som når A. Alt nedstrøms avhenger av den omskrivingen.

A krypterer den på nytt for B. B dekrypterer det ytre laget, ser en pakke fra C til D og videresender den fortsatt kryptert. D fjerner den indre beskyttelsen og leverer applikasjonspakken.

Så A og B ser de indre endepunktene og metadataene deres, men er ikke partene som dekrypterer applikasjonsnyttelasten. Det er en reell egenskap ved designet og ikke en påstand om at C, D eller applikasjonsvertene er pålitelige.

De ytre selektorene navngir de indre gatewayene

Det er her de fleste av disse oppsettene feiler. For en policybasert ytre tunnel må selektorene du forhandler inneholde adressene A og B faktisk håndterer: 10.60.0.2/32 og 10.70.0.2/32, i riktig lokal og ekstern rekkefølge.

Å sette de endelige applikasjonssubnettene i de ytre selektorene fungerer ikke, for når en pakke når A, har den indre innkapslingen allerede skrevet om det A må beskytte. Den ytre policyen ville da ikke matche noe, og tunnelen ville komme opp uten å bære data.

Ikke snevre inn den ytre tillatelsen til UDP 500. Den indre forbindelsen har sin egen datastil, som bruker ESP eller UDP-innkapsling avhengig av hva den forhandlet, og den ytre policyen må tillate den protokollen.

Kontroller resultatet med swanctl --list-sas på hver gateway og bekreft at child-sikkerhetsassosiasjonene rapporterer adressene du mente, ikke dem du antok. Hvis listen viser applikasjonssubnettene, er den ytre policyen skrevet for feil lag. Rett selektorene før du feilsøker ruting, for rutingen vil se fin ut og tellerne vil ikke flytte seg.

Videresending og rekursjonsfellen

Selektorer erstatter ikke ruting. A og B må videresende trafikk mellom C og D i begge retninger, noe som betyr aktivert IP-videresending, ruter som peker på tunnelen og en returvei som finnes på den andre siden.

Hvis den ytre tunnelen bruker XFRM-grensesnitt, velger rutene grensesnittet mens de forhandlede policyene fortsatt begrenser hva det bærer. Et grensesnitt utvider ikke det beskyttede; det endrer bare hvordan kjernen plukker opp pakken.

Fellen er rekursjon. A sin rute til B sin ytre endepunkt må følge underlaget, ikke tunnelen A bygger, ellers prøver innkapslingen å reise inne i seg selv, og forbindelsen fullføres aldri.

Inspiser oversettelse før du legger til lag

Se på enhver kilde-NAT på A og B før du justerer noe annet. En regel som skriver om C sin adresse før IPsec-policyen anvendes, kan ødelegge de avtalte selektorene, og den kan også endre hva D mottar på den andre siden.

Bred maskering blir ikke sikrere av å ha to lag. Den skjuler hvilken adresse fjernenden ser, og det er nettopp informasjonen du trenger når tunnelen er oppe og applikasjonen ikke er.

Hvis en NAT-regel virkelig er nødvendig, skriv ned hvilken adresse hver side tror den snakker med. Den ene linjen avgjør de fleste diskusjoner om det er tunnelen eller oversettelsen som er skyld i det. Den forteller også den neste ingeniøren hvor det skal ses når regelen fjernes et år senere. En ping gjør ingenting av dette.

Bevis fail-closed og kontroller MTU

En rute som forsvinner er ikke i seg selv en fail-closed-policy. En annen tabell, en standardrute eller en policyregel kan stille gi en reservevei, og den eneste måten å vite det på er å ta den ytre tunnelen ned og observere hva applikasjonstrafikken gjør. Gjør det med vilje, i et vindu, i stedet for å oppdage det ved et uhell.

Test tre tilstander: ytre tunnel nede, indre tunnel nede og gjenoppretting etter at begge kommer tilbake. Bruk policytellere på hver gateway, for to etablerte IKE-økter beviser bare at forhandlingen på kontrollplanet lyktes.

Budsjetter for begge innkapslingene. Fungerende IKE er et småpakkeresultat, og applikasjonspakker i full størrelse kan fortsatt feile når to headere legges til; test med en kjent nyttelaststørrelse på den virkelige veien i stedet for å anta at tallene går opp. Aritmetikken er lett, veien er ikke.