IKEv2 dead peer detection test je app niet

De IKEv2-livenesscontrole stelt één vraag: antwoordt de andere peer nog op de beveiligde controlrelatie. Ze meet niet of een interne applicatie gezond is, of er een route achter de gateway bestaat, of browsen snel aanvoelt. De controle kan slagen terwijl alles wat nuttig is achter de tunnel faalt.

Lees de twee soorten bewijs apart voordat je een timer wijzigt.

Wat de livenesscontrole werkelijk vraagt

Een liveness-uitwisseling wordt binnen de gevestigde IKE-beveiligingsassociatie verzonden en verwacht een antwoord binnen een geconfigureerd venster. Succes betekent dat de IKE-implementatie van de peer er nog is en nog bereid is te praten. Ze zegt niets over de child-beveiligingsassociaties die verkeer dragen, niets over routering voorbij de gateway, en niets over de dienst waarvoor je de tunnel opende. Dat zijn drie aparte vragen met drie aparte faalwijzen.

Dat onderscheid bepaalt waar je kijkt wanneer een sessie stil wordt. Een peer die blijft antwoorden terwijl een datapad kapot is, wijst op beleid, routering of een dienst stroomafwaarts. Een peer die stopt met antwoorden wijst op bereikbaarheid of op de eigen toestand van het verre uiteinde.

Lees de beveiligingsassociaties vóór de browser

De controlestatus en de datastatus worden apart vermeld zodra je de daemon vraagt, en de tellers zeggen of er überhaupt iets is geprobeerd. Een child-associatie die nooit is geïnstalleerd ziet er totaal anders uit dan een die is geïnstalleerd en daarna stopte met pakketten doorlaten, ook al geven beide dezelfde gebruikersklacht.

ipsec statusall | head -n 40
swanctl --list-sas
ip xfrm state | grep -E 'proto|mode'

Noteer de statusnamen letterlijk in het ticket, samen met de tellers op het moment van de klacht. Een omschrijving als tunnel neer verbergt welke van de twee associaties eindigde, en dat is meestal het enige feit dat de moeite waard is.

Een routefout ziet er precies uit als een dode peer

De gateway kan controle-uitwisselingen beantwoorden terwijl een privéserver offline is, een doorgestuurde route ontbreekt of interne naamresolutie volledig faalt. Vanuit de client gezien ziet elk daarvan eruit als een sessie die aan staat en een bestemming die dat niet doet. Controleer het retourpad net zo zorgvuldig als het heenpad, want asymmetrische routering aan de verre kant veroorzaakt stilte in slechts één richting.

Test de bedoelde applicatie rechtstreeks en noem het adres dat ze probeerde, in plaats van te testen of de tunnel aan staat. Een ping naar de gateway bewijst dat de gateway antwoordt; het heeft nooit bewezen dat de applicatie dat deed. Noteer het exacte adres dat de applicatie probeerde. Die string vernauwt later het zoeken, en het is het enige feit dat het ticket meestal weglaat.

Houd timers buiten de diagnose

Een detectie-interval verkorten is geen prestatieverandering en voegt geen capaciteit toe. Bij pakketverlies verandert het hoe snel een fout wordt herkend, wat een symptoom anders kan laten lijken zonder iets te verbeteren. Noteer eerst de werkelijke tijd van de fout en beslis dan of de tolerantie verkeerd is voor de verbinding die je echt hebt.

NAT-mapping-verversingen horen in dezelfde categorie. Ze houden een vertaald pad bruikbaar, en ze zijn geen bewijs dat de externe applicatie werkt.

Een volledig herstelbeleid zegt wat de client moet doen wanneer een peer dood wordt verklaard: herstarten, sluiten of vasthouden, en wat ander verkeer mag doen terwijl dat gebeurt. Zonder dat wordt hetzelfde incident elk kwartaal opnieuw vanaf nul gediagnosticeerd.