IPsec i IPsec: vilka adresser den yttre tunneln måste bära

Nästlad IPsec är lättare att resonera om när de två lagren terminerar på olika maskiner. Fyra gateways, två tunnlar och en enda fråga som avgör om designen fungerar: vad ser den yttre tunneln egentligen när den inre har gjort klart med paketet? Svara på det och väljarna, rutterna och felsökningsordningen följer. Gör fel och du lägger en dag på att felsöka en tunnel som tekniskt sett är uppe.

Modellen med fyra gateways

De yttre gatewaysarna A och B bygger den första tunneln mellan de två platserna. Bakom A sitter den inre gatewayn C med transitadress 10.60.0.2; bakom B sitter den inre gatewayn D med transitadress 10.70.0.2. Applikationsnäten lever bakom C och D, och varje adress i exemplet överlappar medvetet inte.

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

Att dela upp lagren på fyra värdar innebär att varje maskin upprätthåller en gräns. En enda värd som kör båda lagren måste förena två uppsättningar policyer, två routingtabeller och två fellägen på en maskin, vilket är möjligt och mycket svårare att observera.

Varje lager tar bort bara sitt eget skydd

C krypterar ett applikationspaket för D. Resultatet adresseras från C till D, och det är det som når A. Allt nedströms beror på den omskrivningen.

A krypterar det igen för B. B dekrypterar det yttre lagret, ser ett paket från C till D och vidarebefordrar det fortfarande krypterat. D tar bort det inre skyddet och levererar applikationspaketet.

Så A och B ser de inre ändpunkterna och deras metadata, men är inte parterna som dekrypterar applikationens nyttolast. Det är en verklig egenskap hos designen och inte ett påstående att C, D eller applikationsvärdarna är pålitliga.

De yttre väljarna namnger de inre gatewaysarna

Det är här de flesta av dessa byggen misslyckas. För en policybaserad yttre tunnel måste de väljare du förhandlar innehålla adresserna som A och B faktiskt hanterar: 10.60.0.2/32 och 10.70.0.2/32, i rätt lokal och avlägsen ordning.

Att sätta de slutliga applikationssubnäten i de yttre väljarna fungerar inte, för när ett paket når A har den inre inkapslingen redan skrivit om det A måste skydda. Den yttre policyn skulle då inte matcha något, och tunneln skulle komma upp utan att bära data.

Snäva inte in det yttre tillståndet till UDP 500. Den inre anslutningen har sin egen dataväg, som använder ESP eller UDP-inkapsling beroende på vad som förhandlats, och den yttre policyn måste tillåta det protokollet.

Kontrollera resultatet med swanctl --list-sas på varje gateway och bekräfta att barnsäkerhetsassociationerna rapporterar de adresser du avsåg, inte de du antog. Om listan visar applikationssubnäten är den yttre policyn skriven för fel lager. Rätta väljarna innan du felsöker routingen, för routingen kommer att se bra ut och räknarna rör sig inte.

Vidarebefordran och rekursionsfällan

Väljare ersätter inte routing. A och B måste vidarebefordra trafik mellan C och D i båda riktningarna, vilket innebär aktiverad IP-vidarebefordran, rutter som pekar på tunneln och en returväg som finns på andra sidan.

Om den yttre tunneln använder XFRM-gränssnitt väljer rutterna gränssnittet medan de förhandlade policyerna fortfarande begränsar vad det bär. Ett gränssnitt utökar inte det skyddade; det ändrar bara hur kärnan plockar upp paketet.

Fällan är rekursion. A:s rutt till B:s yttre ändpunkt måste följa underlagret, inte tunneln A bygger, annars försöker inkapslingen resa inuti sig själv och anslutningen fullbordas aldrig.

Inspektera översättning innan du lägger till lager

Titta på all käll-NAT på A och B innan du justerar något annat. En regel som skriver om C:s adress innan IPsec-policyn tillämpas kan bryta de avtalade väljarna, och den kan också ändra vad D tar emot på andra sidan.

Bred maskering blir inte säkrare av att ha två lager. Den döljer vilken adress fjärrsidan ser, och det är precis den information du behöver när tunneln är uppe och applikationen inte är det.

Om en NAT-regel verkligen behövs, skriv ned vilken adress varje sida tror att den talar med. Den enda raden avgör de flesta diskussioner om det är tunneln eller översättningen som är skyldig. Den berättar också för nästa ingenjör var den ska titta när regeln tas bort ett år senare. En ping gör inget av detta.

Bevisa fail-closed och kontrollera MTU

En rutt som försvinner är inte i sig en fail-closed-policy. En annan tabell, en standardrutt eller en policyregel kan tyst ge en reservväg, och det enda sättet att veta är att ta ned den yttre tunneln och observera vad applikationstrafiken gör. Gör det med avsikt, i ett fönster, i stället för att upptäcka det av misstag.

Testa tre tillstånd: yttre tunnel nere, inre tunnel nere och återhämtning efter att båda kommer tillbaka. Använd policyräknare på varje gateway, för två etablerade IKE-sessioner bevisar bara att förhandlingen på kontrollplanet lyckades.

Budgetera för båda inkapslingarna. Fungerande IKE är ett småpaketsresultat, och applikationspaket i full storlek kan fortfarande misslyckas när två rubriker läggs till; testa med en känd nyttolaststorlek på den verkliga vägen i stället för att anta att siffrorna går ihop. Aritmetiken är lätt, vägen är det inte.