Övervaka ett IPsec-tunnelgränssnitt: vad du ska läsa

En ruttbaserad IPsec-design installerar ett virtuellt gränssnitt, och det gränssnittet ger övervakningen ett konkret objekt: något med ett namn, räknare och en rutt kopplad till sig. Det är inte en hälsosignal i sig. Gränssnittet kan finnas medan ingen användbar association är installerad, och en association kan vara frisk medan ingen rutt skickar den intressanta trafiken dess väg. Det är att läsa fyra tillstånd tillsammans som gör en paketräknare till en diagnos.

Gå igenom dem i ordning och stanna vid det första som fallerar.

Vad gränssnittet tillför bilden

Med en principbaserad design bor urvalet i IPsec-principtabellen och kärnan avgör vad som skyddas utifrån trafikväljare. En ruttbaserad design lägger till ett gränssnitt och en rutt, så tcpdump och gränssnittsräknare ser en enda gräns i stället för en uppsättning väljare. Det är en verklig vinst för diagnostik och för routingprotokoll som behöver ett gränssnitt att peera över.

Vinsten är administrativ, inte kryptografisk. Gränssnittet rapporterar trafiken det bär och säger inget om huruvida motpartens skydd är användbart just nu.

Läs de fyra tillstånden innan du skyller på tunneln

Börja med gränssnittet och rutten, sedan med associationen, sedan med applikationen. Var och en har sitt eget kommando och sin egen felsignatur. Ett rent resultat på ett lager är inte ett rent resultat på nästa. Kör alla fyra innan du drar en slutsats. En grön rad avgör sällan något.

ip -s link show xfrm0
ip route get 10.20.30.40
ip xfrm state
ip xfrm policy
swanctl --list-sas
tcpdump -ni xfrm0 -c 20 host 10.20.30.40

Ett gränssnitt med en stigande räknare men utan matchande tillståndspost beskriver trafik som går in på en väg där inget skyddar den, vilket är värre än en tunnel som helt enkelt är nere. En tillståndspost utan en rutt som väljer gränssnittet betyder att kryptografin är redo och oanvänd.

Applikationstestet kommer sist och med avsikt: en lyckad ping till tunnelns andra sida bevisar inte att tjänsten bakom tar emot anslutningar.

Jämför inre räknare med yttre räknare

Räknare på tunnelgränssnittet mäter inre trafik; räknare och fångster på det fysiska gränssnittet visar det inkapslade utbytet. De två kommer inte att matcha ett till ett, eftersom inkapsling lägger till huvuden, omsändningar duplicerar vissa paket och implementeringens redovisning följer sina egna regler. Förvänta dig ett förhållande, inte likhet.

Fångstens placering avgör också vilka privata data du samlar in, så använd snäva filter och en ofarlig testadress i stället för en fullständig fångst av produktionstrafik.

Om de inre räknarna stiger och de yttre inte gör det, är det saknade steget oftast rutten eller principen som skickar paket in i tunneln, inte tunneln själv.

Följ det genom rekey och failover

Observera en rekey, en händelse för upptäckt av död motpart och en länkväxling medan du håller koll på samma fyra tillstånd. Ett gränssnitt kan förbli närvarande genom en rekey som aldrig slutförs, och en växling kan lämna en tillståndspost som pekar på en motpartsadress som inte längre går att nå.

Larma på den tjänsteväg du faktiskt är beroende av, med associationens tillstånd som kontext, i stället för på en enda upp- eller nerflagga. Behåll gränssnittsnamnet, motpartsadressen och rutten i larmets nyttolast, så att den som svarar inte behöver återskapa dem.

strongSwan dokumenterar sin egen XFRM-gränssnittsmodell, och andra plattformar namnger och implementerar det motsvarande objektet annorlunda. Läs den ruttbaserade jämförelsen för enheten framför dig innan du överför antaganden från en annan implementering. En övervakningsmall som passar en leverantörs räknare kommer tyst att vilseleda på en annan.