Uitgaande ESP zonder antwoord betekent niet dat de VPN dood is
ESP beschermt één richting per associatie en bevestigt niets. Leg het innerlijke gesprek en de inkomende SA naast elkaar voordat je de server onresponsief noemt.
Je hebt verkeer op de IPsec-host vastgelegd, ESP-pakketten zien vertrekken, niets terug zien komen en geconcludeerd dat de andere kant stuk is. De opname ondersteunt die conclusie niet. ESP beschermt één richting van een gesprek en bevestigt niets op IP-niveau, dus ontbrekende retour-ESP kan net zo goed betekenen dat de toepassing niets te zeggen had als dat de tunnel dood is. Lees de innerlijke uitwisseling en de toestand aan de ontvangstkant voordat je een van beide uiteinden de schuld geeft.
De mythe: elk beschermd pakket krijgt een antwoord
ESP is geen vraag-en-antwoordprotocol. Het versleutelt en authenticeert wat het beleid selecteert, en de ontvanger valideert, ontsleutelt en levert dat innerlijke pakket zonder zelf een pakket te genereren. Een UDP-query die de bestemming negeert, of een ICMP-echo die inkomend beleid verwijdert, levert in beide richtingen stilte op als de juiste uitkomst. Die stilte als transportstoring behandelen stuurt je op zoek naar een netwerkfout die er nooit was.
Wat een eenrichtingsopname werkelijk bewijst, is dat de stack van de afzender op dat observatiepunt iets versleutelde. Niets over aankomst, en niets over de bedoeling om te antwoorden. De nuttige vraag is niet „waarom is er geen antwoord“ maar „wat had het innerlijke gesprek moeten opleveren“.
Twee SA's, twee SPI's, één gesprek
IPsec-beveiligingsassociaties zijn unidirectioneel, dus een normale beschermde uitwisseling draait een inkomende associatie en een uitgaande associatie met afzonderlijke identificaties en onafhankelijke toestand. Het retourverkeer zoeken op de SPI van het uitgaande pakket is daarom een categoriefout, omdat elk antwoord onder de eigen uitgaande SA van de peer met zijn eigen SPI reist. Koppel het paar in plaats daarvan op verkeersselectoren en peeradressen.
Hersleuteling maakt het beeld telkens een paar seconden ingewikkelder, omdat oude en vervangende toestand kunnen overlappen. Als het symptoom rond een hersleuteling begon, verzamel dan associatie-identificaties en tijdstempels samen in plaats van alleen de verbindingsnaam.
Wat de ontvanger moet doen voordat er iets antwoordt
| 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" |
Elke rij faalt onafhankelijk en elke fout heeft een andere eigenaar, daarom kan één opname ze niet onderscheiden. De inkomende teller is het enige directe bewijs van aankomst, omdat een pakket dat zijn authenticatie of replay-controle niet haalt, zonder enig antwoord wordt verworpen. Een peer waarvan de inkomende teller niet is bewogen, geeft je dus helemaal geen informatie over zijn beleid.
Aflevering is een aparte stap van ontsleuteling. De toestand kan geldig zijn en het pakket kan daarna alsnog worden verworpen door een inkomend beleid of een route die de innerlijke bestemming niet omvat, dus controleer of de doelserver platte tekst zag in plaats van aan te nemen dat een schone teller betekent dat het pakket ging waar je wilde.
Native ESP is geen UDP
Native ESP is IP-protocol 50, dat noch TCP noch UDP is en helemaal geen poorten heeft. Een firewallregel die IKE op UDP 500 toestaat zegt daarom niets over het datapad, en een filter rond poorten kan een tunnel laten onderhandelen en vervolgens alles wat erin wordt vervoerd laten vallen. Test het datapad apart, in de modus die je werkelijk hebt waargenomen.
Achter NAT verandert de vorm: de beschermde payload reist binnen UDP, meestal op poort 4500, zoals RFC 3948 definieert. Registreer de actieve modus voordat je een regel schrijft, omdat een apparaat op het pad native ESP en UDP-ingekapselde ESP volstrekt anders kan behandelen, en sommige middenboxen het ene toestaan terwijl ze het andere laten vallen.
Lees tellers die bij dit incident horen
Op een strongSwan-host rapporteert swanctl --list-sas pakket- en bytetellers per associatie in beide richtingen, wat genoeg is om „nooit aangekomen“ van „aangekomen en niet beantwoord“ te scheiden. Op Linux telt /proc/net/xfrm_stat samengevoegde fouten zoals ontbrekende toestand, ontbrekend beleid en protocolfouten. Die totalen lopen op vanaf het opstarten en horen bij één netwerknaamruimte, dus een groot getal is geen toeschrijving.
Neem twee metingen rond het incidentvenster in de juiste naamruimte en vergelijk de delta's, anders schrijf je de fouten van vorige week toe aan de kaart van vanmiddag. Zet de naamruimte en beide tijdstempels in de kaart zodat de volgende lezer de vergelijking kan reproduceren in plaats van een totaal te vertrouwen.
Benoem de fase, niet de verdachte
Een nuttige conclusie zegt waar het pakket stopte: nooit ontvangen, ontvangen en verworpen, afgeleverd maar onbeantwoord, of beantwoord en onderweg terug verloren. Elk daarvan wijst naar een andere eigenaar en een ander volgend commando. „Geen antwoord van de VPN-server“ vouwt vier verschillende fouten samen tot één zin die de opname nooit rechtvaardigde.
Houd opnamen smal, en houd ruwe kerneltoestand uit kaarten, want die kan sleutelmateriaal bevatten dat de host niet hoort te verlaten. De tellerdelta's en de tijdstempels zijn de delen die de moeite waard zijn om aan de volgende persoon te geven.