IPsec ESP: hva det bærer og hvordan bevise at det flyter

ESP bærer trafikken i en IPsec-VPN, og runbooken begynner med én regel: les sikkerhetsassosiasjonen før du endrer en policy. Mest uforklart ESP-atferd går tilbake til en selektor som ikke passet, en modus som ble antatt i stedet for lest, eller en teller som ingen kontrollerte mens én strøm ble sendt. De tre trinnene nedenfor fastslår hva som bærer hva, beviser at én strøm bruker det, og etterlater en tilbakerulling som ikke avhenger av hukommelsen. Hvert trinn gir én observasjon som er verdt å skrive ned.

Kjenn feltene før du leser dem

ESP setter en header foran de beskyttede dataene og en trailer bak dem. Headeren bærer en sikkerhetsparameterindeks som identifiserer hvilken assosiasjon mottakeren skal bruke, et sekvensnummer for gjenoppspillingsdeteksjon, og utfylling i traileren som holder nyttelasten justert for chifferen. Feltet for neste header i traileren sier hva det beskyttede innholdet er, og slik vet mottakeren hva den har dekapslet.

Modusen endrer hva som ligger inne i den beskyttelsen. I tunnellmodus er det beskyttede materialet en fullstendig indre IP-pakke, og en ny ytre header bærer den mellom endepunktene. I transportmodus pakker beskyttelsen nyttelasten i det øvre laget av en eksisterende pakke, så det er ingen andre IP-header å pakke ut. Hvilken modus som brukes, er et konfigurasjonsfaktum, ikke et tolkningsspørsmål. Les den fra tilstandsoppføringen i stedet for å utlede den fra et diagram.

Ingen av modusene skjuler den ytre adresseringen som må levere pakken. Det er en egenskap ved designet og ikke en mangel, og derfor kan en mellomliggende observatør fortsatt se hvilke to adresser som snakker sammen, selv når nyttelasten er ugjennomsiktig.

Trinn én: les tilstanden, deretter policyen

Tilstandsoppføringene holder nøklene og tellerne; policyoppføringene holder selektorene som avgjør hva som har lov til å bruke dem. På Linux er begge synlige uten pakkefangst, og å lese dem i den rekkefølgen holder de to spørsmålene adskilt.

ip xfrm state
ip xfrm policy

I tilstandsutdataene, kontroller kilden og målet for assosiasjonen, modusen, og om innkapslingen viser UDP-porter. Disse portene betyr at NAT-gjennomtrengning brukes, noe som endrer hva en mellomliggende brannmur må tillate, men ikke hvilke selektorer eller nøkler som gjelder ved endepunktene.

Les deretter selektorene i policyen. En selektor som nevner et smalere prefiks enn trafikken du tester, er den vanligste grunnen til at en fungerende tunnel ser ut til å ignorere en strøm, og en selektor for feil protokoll gir samme stillhet.

Leverandørverktøy skriver ut de samme opplysningene i en vennligere form. ipsec statusall på strongSwan viser det barnassosiasjonene, selektorene deres og byttetellerne deres, noe som ofte er raskere enn å lese rå xfrm-utdata når du allerede vet hvilket barn du skal se på.

Trinn to: bevis at én strøm flytter tellerne

Tellere er bare meningsfulle hvis du vet hva som skulle ha flyttet dem, så velg en kilde og et mål som selektoren definitivt dekker, og send én ufarlig forespørsel. Les deretter den samme oppføringen igjen og sammenlign.

ip -s xfrm state
tcpdump -ni any esp

To avlesninger forteller forskjellige historier. Pakker som øker på den utgående siden men aldri på den inngående, peker på et videresendings- eller returveisproblem snarere enn et nøkkelproblem, fordi pakken ble innkapslet og forlot stedet. Hvis ingen teller beveger seg, har trafikken aldri passet til policyen, og selektoren er stedet å se på.

Fangsten i samme trinn bekrefter innkapslingen på ledningen, inkludert om de ytre pakkene er ESP eller UDP-innkapslet ESP. Den viser deg også adressene som faktisk bar strømmen, og de avviker av og til fra dem i konfigurasjonen du leste.

Trinn tre: endre én ting og behold en tilbakerulling

Noter assosiasjonens kilde, mål, modus, selektorer og tellere før du redigerer noe. Hvis en endring gjør ting verre, er den noten det som lar deg gjenopprette den forrige tilstanden i stedet for å bygge en fungerende konfigurasjon på nytt fra en gjetning. Noten tar et minutt å skrive og sparer en time senere. Det er også det eneste artefaktet som overlever personen som gjorde endringen.

Endre én selektor eller én parameter, last den på nytt, og gjenta trinn to mot den samme strømmen. Sletting av en assosiasjon river ned hver strøm som bruker den, så en målrettet redigering og en omlasting av barnet er nesten alltid bedre enn å tømme tilstanden for å se hva som skjer.

Tilbakerulling av en selektorredigering er å gjenopprette den forrige policyen og laste den på nytt, med forbehold om at motparten kan trenge en tilsvarende endring hvis selektoren forhandles i stedet for å være lokal. Skriv ned den avhengigheten mens den er fersk, for et halvt gjenopprettet par er vanskeligere å resonnere om enn noen av de to sluttilstandene.

Til slutt, hold omfanget ærlig. En flytende ESP-assosiasjon beviser at de to gatewayene beskytter og leverer segmentet, og den sier ingenting om hvorvidt applikasjonen over autentiserer brukerne sine eller krypterer det den lagrer. Det er separate kontroller med separate bevis, og runbooken er først ferdig når den neste personen kan gjenta den ut fra notatene.