Utgåande ESP utan svar tyder ikkje at VPN-en er død
ESP vernar éi retning per assosiasjon og stadfestar ingenting. Still den indre samtalen og innkomande SA mot kvarandre før du kallar tenaren uresponsiv.
Du fanga trafikk på IPsec-verten, såg ESP-pakkar gå ut, såg ingenting kome attende, og konkluderte med at den andre sida er øydelagd. Fangsten støttar ikkje den konklusjonen. ESP vernar éi retning av ein samtale og stadfestar ingenting på IP-nivå, så manglande retur-ESP kan like gjerne tyde at applikasjonen ikkje hadde noko å seie som at tunnelen er død. Les den indre utvekslinga og tilstanden på mottakarsida før du klandrar nokon av endane.
Myten: kvar verna pakke får eit svar
ESP er ikkje ein førespurnad-svar-protokoll. Han krypterer og autentiserer det policyen vel, og mottakaren validerer, dekrypterer og leverer den indre pakken utan å generere ein pakke sjølv. Ein UDP-førespurnad som målet ignorerer, eller ein ICMP-ekko som innkomande policy forkastar, gir stille i begge retningar som rett utfall. Å handsame den stilla som ein transportfeil sender deg på jakt etter ein nettverksfeil som aldri var der.
Det ein einveg-fangst faktisk beviser, er at stakken til avsendaren krypterte noko på det observasjonspunktet. Ingenting om ankomst, og ingenting om intensjonen om å svare. Det nyttige spørsmålet er ikkje „kvifor er det ikkje noko svar“ men „kva skulle den indre samtalen ha produsert“.
To SA-ar, to SPI-ar, éin samtale
IPsec-tryggingsassosiasjonar er einvegs, så ein vanleg verna utveksling køyrer ein innkomande assosiasjon og ein utgåande assosiasjon med separate identifikatorar og uavhengig tilstand. Å leite etter returtrafikken etter SPI-en til den utgåande pakken er derfor ein kategorifeil, fordi eitkvart svar reiser under partnaren sin eigen utgåande SA med sin eigen SPI. Match paret etter trafikkveljarar og adressene til partnaren i staden.
Nøkkelbyte kompliserer biletet i nokre sekund om gongen, sidan gammal og erstattande tilstand kan overlappe. Viss symptomet starta rundt eit nøkkelbyte, samle assosiasjonsidentifikatorar og tidsstempel saman i staden for berre tilkoplingsnamnet.
Kva mottakaren må gjere før noko svarar
| 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" |
Kvar rad feilar uavhengig, og kvar feil har ein annan eigar, og derfor kan ein einaste fangst ikkje skilje dei. Innkomande teljar er det einaste direkte beviset på ankomst, fordi ein pakke som feilar autentiseringa eller replay-sjekken, blir forkasta utan noko svar. Ein partnar der den innkomande teljaren ikkje har flytta seg, gir deg derfor ingen informasjon om policyen sin i det heile.
Levering er eit eige steg frå dekryptering. Tilstanden kan vere gyldig og pakken likevel bli forkasta etterpå av ein innkomande policy eller ei rute som ikkje omfattar den indre destinasjonen, så sjekk om målverten såg klartekst i staden for å anta at ein rein teljar tyder at pakken gjekk dit du ville.
Innebygd ESP er ikkje UDP
Innebygd ESP er IP-protokoll 50, som korkje er TCP eller UDP og ikkje har nokon portar i det heile. Ein brannmurregel som tillèt IKE på UDP 500 seier derfor ingenting om datastien, og eit filter skrive rundt portar kan la ein tunnel forhandle og deretter sleppe alt som blir bore inni han. Test datastien for seg, i den modusen du faktisk observerte.
Bak NAT endrar forma seg: den verna nyttelasta reiser inne i UDP, vanlegvis på port 4500, slik RFC 3948 definerer. Registrer den aktive modusen før du skriv nokon regel, fordi ei eining på stien kan handsame innebygd ESP og UDP-innkapsla ESP heilt ulikt, og nokre mellomledd tillèt det eine medan dei forkastar det andre.
Les teljarar som høyrer til denne hendinga
På ein strongSwan-vert rapporterer swanctl --list-sas pakke- og bytteteljarar per assosiasjon i begge retningar, noko som er nok til å skilje „aldri komen“ frå „komen og ikkje svara“. På Linux tel /proc/net/xfrm_stat samla feil som manglande tilstand, manglande policy og protokollfeil. Desse totalane blir akkumulerte frå oppstart og høyrer til eitt nettverksnamnerom, så eit stort tal er ikkje ei tilskriving.
Ta to avlesingar rundt hendingsvindauget i rett namnerom og samanlikn delta, elles festar du førre vekes feil på saka frå i ettermiddag. Set namnerommet og begge tidsstempla i saka slik at neste lesar kan gjenskape samanlikninga i staden for å stole på ein total.
Namngi trinnet, ikkje den mistenkte
Ein nyttig konklusjon seier kvar pakken stoppa: aldri motteken, motteken og forkasta, levert men ubesvara, eller svara og tapt på vegen tilbake. Kvart av desse peikar på ein annan eigar og ein annan neste kommando. „Ingen respons frå VPN-tenaren“ kollapsar fire ulike feil til éi setning som fangsten aldri rettferdiggjorde.
Hald fangstane smale, og hald rå kjernetilstand utanfor saker, sidan han kan bere nøkkelmateriale som ikkje har noko å gjere utanfor verten. Teljardeltaa og tidsstempla er delane som er verd å gi vidare til neste person.