Utgående ESP utan svar betyder inte att VPN:et är dött
ESP skyddar en riktning per association och bekräftar ingenting. Stäm av den inre konversationen och den inkommande SA:n innan du kallar servern oresponsiv.
Du fångade trafik på IPsec-värden, såg ESP-paket lämna, såg ingenting komma tillbaka och drog slutsatsen att andra sidan är trasig. Fångsten stöder inte den slutsatsen. ESP skyddar en riktning av en konversation och bekräftar ingenting på IP-nivå, så utebliven retur-ESP kan lika gärna betyda att applikationen inte hade något att säga som att tunneln är död. Läs den inre utväxlingen och tillståndet på mottagarsidan innan du skyller på någon av ändarna.
Myten: varje skyddat paket får ett svar
ESP är inte ett förfrågan-svar-protokoll. Det krypterar och autentiserar det policyn väljer, och mottagaren validerar, dekrypterar och levererar det inre paketet utan att själv generera ett paket. En UDP-förfrågan som målet ignorerar, eller en ICMP-ekko som inkommande policy kastar, ger tystnad i båda riktningarna som korrekt utfall. Att behandla den tystnaden som ett transportfel skickar dig att leta efter ett nätfel som aldrig fanns.
Vad en enkelriktad fångst faktiskt bevisar är att avsändarens stack krypterade något vid den observationspunkten. Ingenting om ankomst, och ingenting om avsikten att svara. Den användbara frågan är inte „varför kommer inget svar“ utan „vad borde den inre konversationen ha producerat“.
Två SA:er, två SPI:er, en konversation
IPsec-säkerhetsassociationer är enkelriktade, så ett normalt skyddat utbyte kör en inkommande association och en utgående association med separata identifierare och oberoende tillstånd. Att leta efter returtrafiken efter det utgående paketets SPI är därför ett kategorifel, eftersom varje svar reser under motpartens egen utgående SA med sin egen SPI. Matcha i stället paret efter trafikväljare och motpartens adresser.
Nyckelbyte komplicerar bilden i några sekunder åt gången, eftersom gammalt och ersättande tillstånd kan överlappa. Om symtomet började kring ett nyckelbyte, samla associationsidentifierare och tidsstämplar tillsammans i stället för bara anslutningsnamnet.
Vad mottagaren måste göra innan något 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" |
Varje rad misslyckas oberoende och varje fel har en annan ägare, vilket är varför en enda fångst inte kan skilja dem åt. Den inkommande räknaren är det enda direkta beviset på ankomst, eftersom ett paket som misslyckas med autentiseringen eller replay-kontrollen slängs utan något svar. En motpart vars inkommande räknare inte har rört sig ger dig därför ingen information alls om sin policy.
Leverans är ett separat steg från dekryptering. Tillståndet kan vara giltigt och paketet ändå senare slängas av en inkommande policy eller en rutt som inte omfattar den inre destinationen, så kontrollera om målvärden såg klartext i stället för att anta att en ren räknare betyder att paketet gick dit du ville.
Inbyggd ESP är inte UDP
Inbyggd ESP är IP-protokoll 50, som varken är TCP eller UDP och inte har några portar alls. En brandväggsregel som tillåter IKE på UDP 500 säger därför ingenting om datavägen, och ett filter skrivet kring portar kan låta en tunnel förhandla och sedan släppa allt som bärs inuti den. Testa datavägen för sig, i det läge du faktiskt observerade.
Bakom NAT ändras formen: den skyddade nyttolasten reser inuti UDP, vanligtvis på port 4500, som RFC 3948 definierar. Registrera det aktiva läget innan du skriver någon regel, eftersom en enhet på vägen kan behandla inbyggd ESP och UDP-inkapslad ESP helt olika, och vissa mellanburkar tillåter den ena medan de släpper den andra.
Läs räknare som hör till den här incidenten
På en strongSwan-värd rapporterar swanctl --list-sas paket- och byteräknare per association i båda riktningarna, vilket räcker för att skilja „aldrig anlänt“ från „anlänt och inte besvarat“. På Linux räknar /proc/net/xfrm_stat aggregerade fel som saknat tillstånd, saknad policy och protokollfel. Dessa summor ackumuleras sedan start och tillhör ett enda nätverksnamnrymd, så ett stort tal är ingen tillskrivning.
Ta två avläsningar runt incidentfönstret i rätt namnrymd och jämför deltan, annars fäster du förra veckans fel på eftermiddagens ärende. Sätt namnrymden och båda tidsstämplarna i ärendet så att nästa läsare kan återskapa jämförelsen i stället för att lita på en summa.
Namnge steget, inte den misstänkte
En användbar slutsats säger var paketet stannade: aldrig mottaget, mottaget och kastat, levererat men obesvarat, eller besvarat och förlorat på vägen tillbaka. Var och en av dessa pekar på en annan ägare och ett annat nästa kommando. „Inget svar från VPN-servern“ kollapsar fyra olika fel till en mening som fångsten aldrig rättfärdigade.
Håll fångsterna smala och håll rå kärntillstånd utanför ärenden, eftersom det kan bära nyckelmaterial som inte har något utanför värden att göra. Räknardeltan och tidsstämplarna är de delar som är värda att lämna vidare till nästa person.