Utgående ESP uten svar betyr ikke at VPN-en er død
ESP beskytter én retning per assosiasjon og bekrefter ingenting. Still den indre samtalen og innkommende SA opp mot hverandre før du kaller serveren uresponsiv.
Du fanget trafikk på IPsec-verten, så ESP-pakker gå ut, så ingenting kom tilbake, og konkluderte med at den andre siden er ødelagt. Fangsten støtter ikke den konklusjonen. ESP beskytter én retning av en samtale og bekrefter ingenting på IP-nivå, så manglende retur-ESP kan like gjerne bety at applikasjonen ikke hadde noe å si som at tunnelen er død. Les den indre utvekslingen og tilstanden på mottakersiden før du klandrer noen av endene.
Myten: hver beskyttet pakke får et svar
ESP er ikke en forespørsel-svar-protokoll. Den krypterer og autentiserer det policyen velger, og mottakeren validerer, dekrypterer og leverer den indre pakken uten å generere en pakke selv. En UDP-forespørsel som målet ignorerer, eller en ICMP-ekko som innkommende policy forkaster, gir stillhet i begge retninger som riktig utfall. Å behandle den stillheten som en transportfeil sender deg på jakt etter en nettverksfeil som aldri var der.
Det en enveis fangst faktisk beviser, er at avsenderens stack krypterte noe på det observasjonspunktet. Ingenting om ankomst, og ingenting om intensjonen om å svare. Det nyttige spørsmålet er ikke „hvorfor er det ikke noe svar“ men „hva skulle den indre samtalen ha produsert“.
To SA-er, to SPI-er, én samtale
IPsec-sikkerhetsassosiasjoner er enveis, så en vanlig beskyttet utveksling kjører en innkommende assosiasjon og en utgående assosiasjon med separate identifikatorer og uavhengig tilstand. Å lete etter returtrafikken etter SPI-en til den utgående pakken er derfor en kategorifeil, fordi ethvert svar reiser under motpartens egen utgående SA med sin egen SPI. Match paret etter trafikkvelgere og motpartens adresser i stedet.
Nøkkelbytte kompliserer bildet i noen sekunder om gangen, siden gammel og erstattende tilstand kan overlappe. Hvis symptomet startet rundt et nøkkelbytte, samle assosiasjonsidentifikatorer og tidsstempler sammen i stedet for bare tilkoblingsnavnet.
Hva mottakeren må gjøre før noe svarer
| Stage | What to look at | Wrong conclusion if skipped |
|---|---|---|
| Sender encrypts | outbound SA packet counter | "the tunnel is up" |
| Peer receives | inbound SA counter and replay window | "the peer is down" |
| Inner delivery | target host or service logs | "routing is broken" |
| Application replies | the app's own trace | "the reply was dropped" |
| Protected return | the peer's outbound SA | "ESP only works one way" |
Hver rad feiler uavhengig, og hver feil har en annen eier, og derfor kan en enkelt fangst ikke skille dem. Innkommende teller er det eneste direkte beviset på ankomst, fordi en pakke som feiler autentiseringen eller replay-sjekken, forkastes uten noe svar. En motpart hvis innkommende teller ikke har beveget seg, gir deg derfor ingen informasjon om policyen sin i det hele tatt.
Levering er et eget trinn fra dekryptering. Tilstanden kan være gyldig og pakken likevel forkastes etterpå av en innkommende policy eller en rute som ikke omfatter den indre destinasjonen, så sjekk om målverten så klartekst i stedet for å anta at en ren teller betyr at pakken gikk dit du ville.
Innebygd ESP er ikke UDP
Innebygd ESP er IP-protokoll 50, som verken er TCP eller UDP og ikke har noen porter i det hele tatt. En brannmurregel som tillater IKE på UDP 500 sier derfor ingenting om datastien, og et filter skrevet rundt porter kan la en tunnel forhandle og deretter slippe alt som bæres inni den. Test datastien for seg, i den modusen du faktisk observerte.
Bak NAT endrer formen seg: den beskyttede nyttelasten reiser inne i UDP, vanligvis på port 4500, slik RFC 3948 definerer. Registrer den aktive modusen før du skriver noen regel, fordi en enhet på stien kan behandle innebygd ESP og UDP-innkapslet ESP helt forskjellig, og noen mellomledd tillater det ene mens de forkaster det andre.
Les tellere som hører til denne hendelsen
På en strongSwan-vert rapporterer swanctl --list-sas pakke- og byttetellere per assosiasjon i begge retninger, noe som er nok til å skille „aldri ankommet“ fra „ankommet og ikke besvart“. På Linux teller /proc/net/xfrm_stat samlede feil som manglende tilstand, manglende policy og protokollfeil. Disse totalene akkumuleres fra oppstart og tilhører ett nettverksnavnerom, så et stort tall er ikke en tilskrivning.
Ta to avlesninger rundt hendelsesvinduet i riktig navnerom og sammenlign deltaer, ellers fester du forrige ukes feil på ettermiddagens sak. Sett navnerommet og begge tidsstemplene i saken slik at neste leser kan gjenskape sammenligningen i stedet for å stole på en total.
Navngi trinnet, ikke den mistenkte
En nyttig konklusjon sier hvor pakken stoppet: aldri mottatt, mottatt og forkastet, levert men ubesvart, eller besvart og tapt på veien tilbake. Hvert av disse peker på en annen eier og en annen neste kommando. „Ingen respons fra VPN-serveren“ kollapser fire forskjellige feil til én setning som fangsten aldri rettferdiggjorde.
Hold fangstene smale, og hold rå kjernetilstand utenfor saker, siden den kan bære nøkkelmateriale som ikke har noe å gjøre utenfor verten. Tellerdeltaene og tidsstemplene er delene som er verdt å gi videre til neste person.