IPsec i IPsec: hvilke adresser skal den ydre tunnel bære

Indlejret IPsec er lettere at gennemskue, når de to lag terminerer på forskellige maskiner. Fire gateways, to tunneler og et enkelt spørgsmål, der afgør, om designet virker: hvad ser den ydre tunnel egentlig, når den indre er færdig med pakken? Svar på det, og selectors, ruter og fejlfindingsrækkefølgen følger. Tager du fejl, bruger du en dag på at fejlfinde en tunnel, der teknisk set er oppe.

Modellen med fire gateways

De ydre gateways A og B bygger den første tunnel mellem de to steder. Bag A sidder den indre gateway C med transitadresse 10.60.0.2; bag B sidder den indre gateway D med transitadresse 10.70.0.2. Applikationsnetværkene ligger bag C og D, og hver adresse i eksemplet overlapper bevidst 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

At dele lagene mellem fire hosts betyder, at hver maskine håndhæver én grænse. En enkelt host, der kører begge lag, skal forene to sæt politikker, to rutetabeller og to fejltilstande på én maskine, hvilket er muligt og meget sværere at observere.

Hvert lag fjerner kun sin egen beskyttelse

C krypterer en applikationspakke for D. Resultatet er adresseret fra C til D, og det er hvad der når A. Alt nedstrøms afhænger af den omskrivning.

A krypterer den igen for B. B dekrypterer det ydre lag, ser en pakke fra C til D og videresender den stadig krypteret. D fjerner den indre beskyttelse og leverer applikationspakken.

Så A og B ser de indre endepunkter og deres metadata, men de er ikke de parter, der dekrypterer applikationsnyttelasten. Det er en reel egenskab ved designet og ikke en påstand om, at C, D eller applikationsværterne er troværdige.

De ydre selectors navngiver de indre gateways

Det er her, de fleste af disse opsætninger fejler. For en politikbaseret ydre tunnel skal de selectors, du forhandler, indeholde de adresser, som A og B faktisk håndterer: 10.60.0.2/32 og 10.70.0.2/32, i den rigtige lokale og fjernede rækkefølge.

At sætte de endelige applikationssubnets i de ydre selectors virker ikke, for når en pakke når A, har den indre indkapsling allerede omskrevet det, A skal beskytte. Den ydre politik ville så ikke matche noget, og tunnelen ville komme op uden at bære data.

Indsnævr ikke den ydre tilladelse til UDP 500. Den indre forbindelse har sin egen datasti, som bruger ESP eller UDP-indkapsling afhængigt af, hvad den forhandlede, og den ydre politik skal tillade den protokol.

Kontroller resultatet med swanctl --list-sas på hver gateway og bekræft, at child-sikkerhedsassociationerne rapporterer de adresser, du havde til hensigt, ikke dem du antog. Hvis listen viser applikationssubnettene, er den ydre politik skrevet til det forkerte lag. Ret selectors, før du fejlfinder routing, for routing vil se fint ud, og tællerne flytter sig ikke.

Videresendelse og rekursionsfælden

Selectors erstatter ikke routing. A og B skal videresende trafik mellem C og D i begge retninger, hvilket betyder aktiveret IP-videresendelse, ruter der peger på tunnelen, og en returvej, der findes på den anden side.

Hvis den ydre tunnel bruger XFRM-interfaces, vælger ruterne interfacet, mens de forhandlede politikker stadig begrænser, hvad det bærer. Et interface udvider ikke det beskyttede; det ændrer kun, hvordan kernen samler pakken op.

Fælden er rekursion. A's rute til B's ydre endepunkt skal følge underlaget, ikke den tunnel A opretter, ellers forsøger indkapslingen at rejse inde i sig selv, og forbindelsen fuldføres aldrig.

Inspicér oversættelse, før du tilføjer lag

Se på enhver source NAT på A og B, før du justerer noget andet. En regel, der omskriver C's adresse, før IPsec-politikken anvendes, kan ødelægge de aftalte selectors, og den kan også ændre, hvad D modtager på den anden side.

Bred maskerering bliver ikke sikrere af at have to lag. Den skjuler, hvilken adresse fjernenden ser, og det er netop den information, du har brug for, når tunnelen er oppe, og applikationen ikke er.

Hvis en NAT-regel virkelig er nødvendig, så skriv ned, hvilken adresse hver side tror, den taler med. Den ene linje afgør de fleste diskussioner om, hvorvidt tunnelen eller oversættelsen er skyld i det. Den fortæller også den næste ingeniør, hvor der skal kigges, når reglen fjernes et år senere. En ping gør ingen af delene.

Bevis fail-closed, og kontrollér MTU

En rute, der forsvinder, er ikke i sig selv en fail-closed-politik. En anden tabel, en standardrute eller en politikregel kan stille give en fallback, og den eneste måde at vide det på er at tage den ydre tunnel ned og observere, hvad applikationstrafikken gør. Gør det med vilje, i et vindue, i stedet for at opdage det ved et uheld.

Test tre tilstande: ydre tunnel nede, indre tunnel nede, og genopretning efter begge kommer tilbage. Brug politikttællere på hver gateway, for to etablerede IKE-sessioner beviser kun, at forhandlingen på kontrolplanet lykkedes.

Budgetter for begge indkapslinger. Fungerende IKE er et småpakkeresultat, og applikationspakker i fuld størrelse kan stadig fejle, når der tilføjes to headere; test med en kendt nyttelaststørrelse på den rigtige vej i stedet for at antage, at tallene passer. Aritmetikken er let, vejen er ikke.