Udgående ESP uden svar betyder ikke, at VPN’en er død
ESP beskytter én retning per associering og anerkender intet. Afstem den indre samtale og den indgående SA, før du kalder serveren uresponsiv.
Du optog trafik på IPsec-værten, så ESP-pakker forlade den, så intet kom tilbage og konkluderede, at den anden side er i stykker. Optagelsen understøtter ikke den konklusion. ESP beskytter én retning af en samtale og anerkender intet på IP-laget, så manglende retur-ESP kan lige så let betyde, at applikationen ikke havde noget at sige, som at tunnelen er død. Læs den indre udveksling og modtagersidens tilstand, før du bebrejder nogen af enderne.
Myten: hver beskyttet pakke gør sig fortjent til et svar
ESP er ikke en anmodning-svar-protokol. Den krypterer og autentificerer, hvad politikken end vælger, og modtageren validerer, dekrypterer og leverer den indre pakke uden at generere en pakke selv. En UDP-forespørgsel, som destinationen ignorerer, eller et ICMP-ekko, som den indgående politik forkaster, giver tavshed i begge retninger som det korrekte resultat. Behandles den tavshed som en transportfejl, sendes du på jagt efter en netværksfejl, der aldrig var der.
Det, en envejsoptagelse faktisk beviser, er, at afsenderens stak krypterede noget på det observationspunkt. Intet om ankomst og intet om hensigten om at svare. Det nyttige spørgsmål er ikke "hvorfor er der intet svar", men "hvad burde den indre samtale have frembragt".
To SA'er, to SPI'er, én samtale
IPsec-sikkerhedsassocieringer er enrettede, så en normal beskyttet udveksling har en indgående og en udgående associering med adskilte identifikatorer og uafhængig tilstand. At lede efter returtrafikken efter den udgående pakkes SPI er derfor en kategorifejl, fordi ethvert svar rejser under peerens egen udgående SA med sin egen SPI. Par i stedet parret efter trafikvælgere og peerens adresser.
Genoprettelse af nøgler gør billedet kompliceret i nogle få sekunder ad gangen, da gammel og ny tilstand kan overlappe. Hvis symptomet begyndte omkring en nøglegenoprettelse, så indsaml associeringsidentifikatorer og tidsstempler sammen i stedet for kun forbindelsens navn.
Hvad modtageren skal gøre, før noget 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 række fejler uafhængigt, og hver fejl har en anden ejer, hvilket er grunden til, at en enkelt optagelse ikke kan skelne dem. Den indgående tæller er det eneste direkte bevis på ankomst, fordi en pakke, der fejler sin autentificering eller replay-kontrol, kasseres uden nogen respons. En peer, hvis indgående tæller ikke har rørt sig, sender dig derfor slet ingen information om sin politik.
Levering er et separat trin fra dekryptering. Tilstanden kan være gyldig, og pakken alligevel kasseres bagefter af en indgående politik eller en rute, der ikke omfatter den indre destination, så kontroller, om målværten så klartekst, i stedet for at antage, at en ren tæller betyder, at pakken gik, hvor du ville have den hen.
Indfødt ESP er ikke UDP
Indfødt ESP er IP-protokol 50, som hverken er TCP eller UDP og slet ingen porte har. En firewallregel, der tillader IKE på UDP 500, siger derfor intet om datastien, og et filter skrevet omkring porte kan lade en tunnel forhandle og derefter kassere alt, der bæres indeni. Test datastien for sig selv, i den tilstand du faktisk observerede.
Bag en NAT ændrer formen sig: den beskyttede nyttelast rejser inde i UDP, normalt på port 4500, som RFC 3948 definerer. Registrer den aktive tilstand, før du skriver nogen regel, fordi en enhed på stien kan behandle indfødt ESP og UDP-indkapslet ESP helt forskelligt, og nogle middleboxes tillader den ene og kaster den anden væk.
Læs tællere, der hører til denne hændelse
På en strongSwan-vært rapporterer swanctl --list-sas pakke- og bytetællere per associering i begge retninger, hvilket er nok til at skelne "aldrig ankommet" fra "ankommet og ikke besvaret". På Linux tæller /proc/net/xfrm_stat samlede fejl som manglende tilstand, manglende politik og protokolfejl. Disse totaler akkumuleres fra opstart og tilhører ét netværksnavnerum, så et stort tal er ikke en tilskrivning.
Tag to aflæsninger omkring hændelsesvinduet i det korrekte navnerum, og sammenlign forskellene, ellers klistrer du sidste uges fejl på eftermiddagens ticket. Skriv navnerummet og begge tidsstempler i ticketen, så den næste læser kan gengive sammenligningen i stedet for at stole på et total.
Navngiv trinnet, ikke den mistænkte
En nyttig konklusion siger, hvor pakken stoppede: aldrig modtaget, modtaget og kasseret, leveret men ubesvaret, eller besvaret og tabt på vejen tilbage. Hvert af disse peger på en anden ejer og en anden næste kommando. "Ingen respons fra VPN-serveren" presser fire forskellige fejl sammen i én sætning, som optagelsen aldrig retfærdiggjorde.
Hold optagelser snævre, og hold rå kernetilstand ude af tickets, da den kan bære nøglemateriale, som ikke har noget at gøre uden for værten. Tællerforskellene og tidsstemplerne er de dele, der er værd at give videre til den næste person.