IPsec in IPsec: welke adressen de buitenste tunnel moet dragen

Genestelde IPsec is gemakkelijker te doordenken wanneer de twee lagen op verschillende machines eindigen. Vier gateways, twee tunnels en één vraag die beslist of het ontwerp werkt: wat ziet de buitenste tunnel werkelijk wanneer de binnenste klaar is met het pakket? Beantwoord dat en de selectors, de routes en de volgorde van probleemoplossing volgen. Doe je het fout, dan besteed je een dag aan het debuggen van een tunnel die technisch gezien overeind staat.

Het model met vier gateways

De buitenste gateways A en B bouwen de eerste tunnel tussen de twee locaties. Achter A zit de interne gateway C met transitzendadres 10.60.0.2; achter B zit de interne gateway D met transitzendadres 10.70.0.2. De applicatienetwerken leven achter C en D, en elk adres in het voorbeeld overlapt bewust niet.

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

De lagen over vier hosts verdelen betekent dat elke machine één grens handhaaft. Eén host die beide lagen draait, moet twee sets beleid, twee routingtabellen en twee storingsmodi op één machine verenigen, wat mogelijk en veel moeilijker waar te nemen is.

Elke laag verwijdert alleen zijn eigen bescherming

C versleutelt een applicatiepakket voor D. Het resultaat is geadresseerd van C naar D, en dat is wat A bereikt. Alles stroomafwaarts hangt van die herschrijving af.

A versleutelt het opnieuw voor B. B ontsleutelt de buitenste laag, ziet een pakket van C naar D en stuurt het nog steeds versleuteld door. D verwijdert de binnenste bescherming en levert het applicatiepakket af.

Dus A en B zien de interne eindpunten en hun metadata, maar zijn niet de partijen die de applicatielading ontsleutelen. Dat is een echte eigenschap van het ontwerp en geen bewering dat C, D of de applicatiehosts betrouwbaar zijn.

De buitenste selectors noemen de interne gateways

Hier falen de meeste van deze opstellingen. Voor een beleidsgebaseerde buitenste tunnel moeten de selectors die je onderhandelt de adressen bevatten die A en B werkelijk afhandelen: 10.60.0.2/32 en 10.70.0.2/32, in de juiste lokale en externe volgorde.

De uiteindelijke applicatiesubnetten in de buitenste selectors zetten werkt niet, want tegen de tijd dat een pakket A bereikt, heeft de binnenste inkapseling al herschreven wat A moet beschermen. Het buitenste beleid zou dan nergens op passen, en de tunnel zou omhoogkomen zonder gegevens te dragen.

Beperk de buitenste toestemming ook niet tot UDP 500. De interne verbinding heeft haar eigen datapad, dat ESP of UDP-inkapseling gebruikt afhankelijk van wat is onderhandeld, en het buitenste beleid moet dat protocol toestaan.

Controleer het resultaat met swanctl --list-sas op elke gateway en bevestig dat de child-beveiligingsassociaties de adressen rapporteren die je bedoelde, niet die je aannam. Als de lijst de applicatiesubnetten toont, is het buitenste beleid voor de verkeerde laag geschreven. Corrigeer de selectors voordat je routing debugt, want routing zal er goed uitzien en de tellers zullen niet bewegen.

Doorsturen en de recursieval

Selectors vervangen routing niet. A en B moeten verkeer tussen C en D in beide richtingen doorsturen, wat betekent dat IP-doorgifte is ingeschakeld, routes naar de tunnel wijzen en er aan de andere kant een terugweg bestaat.

Als de buitenste tunnel XFRM-interfaces gebruikt, selecteren routes de interface terwijl het onderhandelde beleid nog steeds beperkt wat die draagt. Een interface verbreedt niet wat beschermd is; het verandert alleen hoe de kernel het pakket oppakt.

De val is recursie. De route van A naar het buitenste eindpunt van B moet de onderlaag volgen, niet de tunnel die A opbouwt, anders probeert de inkapseling in zichzelf te reizen en komt de verbinding nooit tot stand.

Inspecteer vertaling voordat je lagen toevoegt

Kijk naar elke source-NAT op A en B voordat je iets anders afstelt. Een regel die het adres van C herschrijft voordat het IPsec-beleid van toepassing is, kan de afgesproken selectors breken, en kan ook veranderen wat D aan de andere kant ontvangt.

Brede masquerading wordt niet veiliger door twee lagen. Het verbergt welk adres de verre kant ziet, en dat is precies de informatie die je nodig hebt wanneer de tunnel omhoog is en de applicatie niet werkt.

Als een NAT-regel echt nodig is, schrijf dan op met welk adres elke kant denkt te praten. Die ene regel beslist de meeste discussies over of de tunnel of de vertaling schuld heeft. Het vertelt de volgende engineer ook waar te kijken wanneer de regel een jaar later wordt verwijderd. Een ping doet niets daarvan.

Bewijs fail-closed en controleer de MTU

Een route die verdwijnt is op zichzelf geen fail-closed-beleid. Een andere tabel, een standaardroute of een beleidsregel kan stil een terugval bieden, en de enige manier om dat te weten is de buitenste tunnel neer te halen en te kijken wat het applicatieverkeer doet. Doe dat met opzet, in een onderhoudsvenster, in plaats van het per ongeluk te ontdekken.

Test drie toestanden: buitenste tunnel neer, binnenste tunnel neer en herstel nadat beide terugkomen. Gebruik beleidstellers op elke gateway, want twee gevestigde IKE-sessies bewijzen alleen dat de onderhandeling op de controlevlak is geslaagd.

Begroot beide inkapselingen. Werkende IKE is een resultaat van kleine pakketten, en applicatiepakketten op volledige grootte kunnen alsnog falen zodra er twee headers bijkomen; test met een bekende payloadgrootte op het echte pad in plaats van aan te nemen dat de getallen kloppen. De rekensom is eenvoudig, het pad niet.