IPsec ESP: vad det bär och hur man bevisar att det flödar

ESP bär trafiken i en IPsec-VPN, och dess runbook börjar med en regel: läs säkerhetsassociationen innan du ändrar en policy. Det mesta oförklarade ESP-beteendet går tillbaka till en selektor som inte matchade, ett läge som antogs i stället för att läsas, eller en räknare som ingen kontrollerade medan en enda ström skickades. De tre stegen nedan fastställer vad som bär vad, bevisar att en ström använder det och lämnar en återställning som inte beror på minnet. Varje steg ger en observation som är värd att skriva ned.

Känn till fälten innan du läser dem

ESP sätter ett huvud före de skyddade uppgifterna och en släp efter dem. Huvudet bär ett säkerhetsparameterindex som identifierar vilken association mottagaren ska använda, ett sekvensnummer för återuppspelningsdetektering och i släpet utfyllnad som håller nyttolasten justerad för chifferet. Fältet för nästa huvud i släpet säger vad det skyddade innehållet är, och så vet mottagaren vad den har dekapslat.

Läget ändrar vad som ligger inuti det skyddet. I tunnelläge är det skyddade materialet ett fullständigt inre IP-paket, och ett nytt yttre huvud bär det mellan ändpunkterna. I transportläge omsluter skyddet nyttolasten i det övre lagret av ett befintligt paket, så det finns inget andra IP-huvud att packa upp. Vilket läge som används är ett konfigurationsfaktum, inte en tolkningsfråga. Läs det från tillståndsposten i stället för att härleda det från ett diagram.

Inget av lägena döljer den yttre adressering som måste leverera paketet. Det är en egenskap hos designen och ingen brist, och därför kan en mellanliggande observatör fortfarande se vilka två adresser som talar även när nyttolasten är ogenomskinlig.

Steg ett: läs tillståndet, sedan policyn

Tillståndsposterna håller nycklarna och räknarna; policyposterna håller selektorerna som avgör vad som får använda dem. På Linux är båda synliga utan paketfångst, och att läsa dem i den ordningen håller de två frågorna åtskilda.

ip xfrm state
ip xfrm policy

I tillståndsutdata, kontrollera källan och målet för associationen, läget och om inkapslingen visar UDP-portar. Dessa portar betyder att NAT-genomträngning används, vilket ändrar vad en mellanliggande brandvägg måste tillåta, men inte vilka selektorer eller nycklar som gäller vid ändpunkterna.

Läs sedan selektorerna i policyn. En selektor som anger ett smalare prefix än trafiken du testar är den vanligaste orsaken till att en fungerande tunnel verkar ignorera en ström, och en selektor för fel protokoll ger samma tystnad.

Leverantörsverktyg skriver ut samma information i en vänligare form. ipsec statusall på strongSwan listar det barnassociationerna, deras selektorer och deras byteräknare, vilket ofta är snabbare än att läsa rå xfrm-utdata när du redan vet vilket barn du ska titta på.

Steg två: bevisa att en ström flyttar räknarna

Räknare är bara meningsfulla om du vet vad som borde ha flyttat dem, så välj en källa och ett mål som selektorn säkert täcker och skicka en ofarlig begäran. Läs sedan samma post igen och jämför.

ip -s xfrm state
tcpdump -ni any esp

Två avläsningar berättar olika historier. Paket som ökar på den utgående sidan men aldrig på den inkommande pekar på ett vidarebefordran- eller returvägsproblem snarare än ett nyckelproblem, eftersom paketet kapslades in och lämnade platsen. Om ingen räknare rör sig har trafiken aldrig matchat policyn, och selektorn är platsen att titta på.

Fångsten i samma steg bekräftar inkapslingen på tråden, inklusive om de yttre paketen är ESP eller UDP-inkapslad ESP. Den visar dig också adresserna som faktiskt bar strömmen, och de avviker ibland från dem i konfigurationen du läste.

Steg tre: ändra en sak och behåll en återställning

Anteckna associationens källa, mål, läge, selektorer och räknare innan du redigerar något. Om en ändring förvärrar saker är det anteckningen som låter dig återställa det tidigare tillståndet i stället för att bygga om en fungerande konfiguration från en gissning. Anteckningen tar en minut att skriva och sparar en timme senare. Det är också den enda artefakt som överlever personen som gjorde ändringen.

Ändra en selektor eller en parameter, ladda om den och upprepa steg två mot samma ström. Att ta bort en association river ned varje ström som använder den, så en riktad redigering och en omladdning av barnet är nästan alltid bättre än att tömma tillståndet för att se vad som händer.

Återställningen av en selektorredigering är att återställa den tidigare policyn och ladda om den, med förbehållet att motparten kan behöva en motsvarande ändring om selektorn förhandlas i stället för att vara lokal. Skriv ned det beroendet medan det är färskt, för ett halvt återställt par är svårare att resonera om än något av de två sluttillstånden.

Håll till sist omfattningen ärlig. En flödande ESP-association bevisar att de två gatewayerna skyddar och levererar segmentet, och den säger ingenting om huruvida applikationen ovanpå autentiserar sina användare eller krypterar det den lagrar. Det är separata kontroller med separata bevis, och runbooken är först klar när nästa person kan upprepa den utifrån anteckningarna.