IPsec ESP: hvad det bærer, og hvordan man beviser, at det løber

ESP bærer trafikken i en IPsec-VPN, og dens runbook begynder med én regel: læs sikkerhedsassociationen, før du ændrer en politik. Det meste uforklarede ESP-adfærd kan føres tilbage til en selector, der ikke matchede, en tilstand, der blev antaget i stedet for læst, eller en tæller, som ingen kontrollerede, mens en enkelt strøm blev sendt. De tre trin nedenfor fastslår, hvad der bærer hvad, beviser, at én strøm bruger det, og efterlader en tilbagerulning, der ikke afhænger af hukommelsen. Hvert trin giver én observation, der er værd at skrive ned.

Kend felterne, før du læser dem

ESP sætter et header foran de beskyttede data og en trailer bag dem. Headeret bærer et sikkerhedsparameterindeks, der identificerer, hvilken association modtageren skal bruge, et sekvensnummer til genafspilningsdetektion og udfyldning i traileren, der holder nyttelasten justeret til cifret. Feltet med næste header i traileren fortæller, hvad det beskyttede indhold er, og det er sådan, modtageren ved, hvad den har afkapslet.

Tilstanden ændrer, hvad der ligger inde i den beskyttelse. I tunneltilstand er det beskyttede materiale en komplet indre IP-pakke, og et nyt ydre header bærer den mellem endepunkterne. I transporttilstand pakker beskyttelsen den øverste lags nyttelast i en eksisterende pakke, så der er intet andet IP-header at pakke ud. Hvilken tilstand der bruges, er en konfigurationskendsgerning, ikke et spørgsmål om fortolkning. Læs den fra tilstandsindgangen i stedet for at udlede den af et diagram.

Ingen af tilstandene skjuler den ydre adressering, der skal levere pakken. Det er en egenskab ved designet og ikke en mangel, og derfor kan en mellemliggende observatør stadig se, hvilke to adresser der taler, selv når nyttelasten er uigennemsigtig.

Trin et: læs tilstanden, derefter politikken

Tilstandsindgangene holder nøglerne og tællerne; politikindgangene holder selectorerne, der bestemmer, hvad der må bruge dem. På Linux er begge synlige uden pakkefangst, og at læse dem i den rækkefølge holder de to spørgsmål adskilt.

ip xfrm state
ip xfrm policy

I tilstandsoutputtet skal du kontrollere associationens kilde og destination, tilstanden og om indkapslingen viser UDP-porte. De porte betyder, at NAT-gennemtrængning bruges, hvilket ændrer, hvad en mellemliggende firewall skal tillade, men ikke hvilke selectorer eller nøgler der gælder ved endepunkterne.

Læs derefter selectorerne i politikken. En selector, der angiver et smallere præfiks end den trafik, du tester, er den mest almindelige grund til, at en fungerende tunnel ser ud til at ignorere en strøm, og en selector til den forkerte protokol giver samme tavshed.

Leverandørværktøjer udskriver de samme oplysninger i en venligere form. ipsec statusall på strongSwan viser child-associationerne, deres selectorer og deres byttetællere, hvilket ofte er hurtigere end at læse rå xfrm-output, når du allerede ved, hvilket child du skal se på.

Trin to: bevis, at én strøm flytter tællerne

Tællere er kun meningsfulde, hvis du ved, hvad der burde have flyttet dem, så vælg en kilde og destination, som selectoren helt sikkert dækker, og send én harmløs anmodning. Læs derefter den samme indgang igen og sammenlign.

ip -s xfrm state
tcpdump -ni any esp

To aflæsninger fortæller forskellige historier. Pakker, der stiger på den udgående side men aldrig på den indgående, peger på et videresendelses- eller returvejsproblem snarere end et nøgleproblem, fordi pakken blev indkapslet og forlod stedet. Hvis ingen tæller flytter sig, har trafikken aldrig matchet politikken, og selectoren er stedet at se på.

Fangsten i samme trin bekræfter indkapslingen på ledningen, inklusive om de ydre pakker er ESP eller UDP-indkapslet ESP. Den viser dig også de adresser, der faktisk bar strømmen, og de afviger lejlighedsvis fra dem i den konfiguration, du læste.

Trin tre: ændr én ting og behold en tilbagerulning

Noter associationens kilde, destination, tilstand, selectorer og tællere, før du redigerer noget. Hvis en ændring gør tingene værre, er den note det, der lader dig gendanne den tidligere tilstand i stedet for at genopbygge en fungerende konfiguration ud fra et gæt. Noten tager et minut at skrive og sparer en time senere. Det er også det eneste artefakt, der overlever personen, der lavede ændringen.

Ændr én selector eller én parameter, genindlæs den, og gentag trin to mod den samme strøm. Sletning af en association river hver strøm ned, der bruger den, så en målrettet redigering og en genindlæsning af childet er næsten altid bedre end at tømme tilstanden for at se, hvad der sker.

Tilbagerulning af en selectorredigering er at gendanne den forrige politik og genindlæse den, med forbehold for at peer'en kan have brug for en tilsvarende ændring, hvis selectoren forhandles i stedet for at være lokal. Skriv den afhængighed ned, mens den er frisk, for et halvt gendannet par er sværere at ræsonnere om end nogen af de to sluttilstande.

Endelig: hold omfanget ærligt. En løbende ESP-association beviser, at de to gateways beskytter og leverer segmentet, og den siger intet om, hvorvidt applikationen ovenover autentificerer sine brugere eller krypterer det, den gemmer. Det er separate kontroller med separate beviser, og runbooken er først færdig, når den næste person kan gentage den ud fra noterne.