IPsec ESP: kva det ber og korleis prova at det flyt

ESP ber trafikken i ein IPsec-VPN, og runbooken byrjar med éin regel: les tryggingsassosiasjonen før du endrar ein policy. Mest uforklara ESP-åtferd går tilbake til ein selektor som ikkje passa, ein modus som vart antatt i staden for lesen, eller ein teljar som ingen kontrollerte medan éin straum vart send. Dei tre trinna nedanfor fastslår kva som ber kva, provar at éin straum brukar det, og lèt etter seg ei tilbakerulling som ikkje er avhengig av minnet. Kvart trinn gir éi observasjon som er verdt å skrive ned.

Kjenn felta før du les dei

ESP set ein header framfor dei verna dataa og ein trailer bak dei. Headaren ber ein tryggingsparameterindeks som identifiserer kva assosiasjon mottakaren skal bruke, eit sekvensnummer for gjenoppspelingsdeteksjon, og utfylling i traileren som held nyttelasta justert for chifferen. Feltet for neste header i traileren seier kva det verna innhaldet er, og slik veit mottakaren kva han har dekapsla.

Modusen endrar kva som ligg inne i den vernet. I tunnellmodus er det verna materialet ein fullstendig indre IP-pakke, og ein ny ytre header ber han mellom endepunkta. I transportmodus pakkar vernet nyttelasta i det øvre laget av ein eksisterande pakke, så det er ingen andre IP-header å pakke ut. Kva modus som vert brukt, er eit konfigurasjonsfaktum, ikkje eit tolkingstema. Les han frå tilstandsoppføringa i staden for å utleie han frå eit diagram.

Ingen av modusane skjuler den ytre adresseringa som må levere pakken. Det er ein eigenskap ved designet og ikkje ein mangel, og difor kan ein mellomliggjande observatør framleis sjå kva to adresser som snakkar saman, sjølv når nyttelasta er ugjennomsiktig.

Trinn éin: les tilstanden, deretter policyen

Tilstandsoppføringane held nøklane og teljarane; policyoppføringane held selektorane som avgjer kva som har lov til å bruke dei. På Linux er begge synlege utan pakkefangst, og å lese dei i den rekkjefølgja held dei to spørsmåla åtskilde.

ip xfrm state
ip xfrm policy

I tilstandsutdataa, kontroller kjelda og målet for assosiasjonen, modusen, og om innkapslinga viser UDP-portar. Desse portane tyder at NAT-gjennomtrenging vert brukt, noko som endrar kva ein mellomliggjande brannmur må tillate, men ikkje kva selektorar eller nøklar som gjeld ved endepunkta.

Les deretter selektorane i policyen. Ein selektor som nemner eit smalare prefiks enn trafikken du testar, er den vanlegaste grunnen til at ein fungerande tunnel ser ut til å ignorere ein straum, og ein selektor for feil protokoll gir same stille.

Leverandørverktøy skriv ut dei same opplysningane i ei venlegare form. ipsec statusall på strongSwan viser det barnassosiasjonane, selektorane deira og bytteteljarane deira, noko som ofte er raskare enn å lese rå xfrm-utdata når du allereie veit kva barn du skal sjå på.

Trinn to: prov at éin straum flyttar teljarane

Teljarar er berre meiningsfulle om du veit kva som skulle ha flytta dei, så vel ei kjelde og eit mål som selektoren definitivt dekkjer, og send éin ufarleg førespurnad. Les deretter den same oppføringa igjen og samanlikn.

ip -s xfrm state
tcpdump -ni any esp

To avlesingar fortel ulike historier. Pakkar som aukar på den utgåande sida men aldri på den inngåande, peikar på eit vidaresendings- eller returvegsproblem snarare enn eit nøkkelproblem, fordi pakken vart innkapsla og forlét staden. Om ingen teljar rører seg, har trafikken aldri passa til policyen, og selektoren er staden å sjå på.

Fangsten i same trinn stadfestar innkapslinga på leiinga, inkludert om dei ytre pakkane er ESP eller UDP-innkapsla ESP. Han viser deg også adressene som faktisk bar straumen, og dei avvik av og til frå dei i konfigurasjonen du las.

Trinn tre: endre éin ting og behald ei tilbakerulling

Noter kjelda, målet, modusen, selektorane og teljarane til assosiasjonen før du redigerer noko. Om ei endring gjer ting verre, er den nota det som lèt deg gjenopprette den førre tilstanden i staden for å byggje ein fungerande konfigurasjon på nytt frå ein gjetting. Nota tek eit minutt å skrive og sparar ein time seinare. Det er også det einaste artefaktet som overlever personen som gjorde endringa.

Endre éin selektor eller éin parameter, last han på nytt, og gjenta trinn to mot den same straumen. Sletting av ein assosiasjon riv ned kvar straum som brukar han, så ei målretta redigering og ei omlasting av barnet er nesten alltid betre enn å tømme tilstanden for å sjå kva som skjer.

Tilbakerulling av ei selektorredigering er å gjenopprette den førre policyen og laste han på nytt, med atterhald om at motparten kan trenge ei tilsvarande endring om selektoren vert forhandla i staden for å vere lokal. Skriv ned den avhengigheita medan ho er fersk, for eit halvt gjenoppretta par er vanskelegare å resonnere om enn nokon av dei to sluttilstandane.

Til slutt, hald omfanget ærleg. Ein flytande ESP-assosiasjon provar at dei to gatewayane vernar og leverer segmentet, og han seier ingenting om korvidt applikasjonen over autentiserer brukarane sine eller krypterer det han lagrar. Det er separate kontrollar med separate prov, og runbooken er først ferdig når den neste personen kan gjenta han ut frå notata.