Een IPsec-tunnelinterface monitoren: wat je moet lezen

Een routegebaseerd IPsec-ontwerp installeert een virtuele interface, en die interface geeft monitoring een concreet object: iets met een naam, tellers en een route die eraan hangt. Het is op zichzelf geen gezondheidssignaal. De interface kan bestaan terwijl er geen bruikbare associatie is geïnstalleerd, en een associatie kan gezond zijn terwijl geen route het interessante verkeer ernaartoe stuurt. Vier toestanden samen lezen is wat een pakketteller in een diagnose verandert.

Werk ze op volgorde door en stop bij de eerste die faalt.

Wat de interface aan het beeld toevoegt

Bij een policygebaseerd ontwerp zit de selectie in de IPsec-beleidstabel en bepaalt de kernel wat er op basis van traffic selectors wordt beschermd. Een routegebaseerd ontwerp voegt een interface en een route toe, zodat tcpdump en interfacetellers één grens zien in plaats van een verzameling selectors. Dat is een echte winst voor diagnose en voor routingprotocollen die een interface nodig hebben om over te peeren.

De winst is administratief, niet cryptografisch. De interface rapporteert het verkeer dat hij draagt en zegt niets over of de bescherming van de peer op dit moment bruikbaar is.

Lees de vier toestanden voordat je de tunnel de schuld geeft

Begin met de interface en de route, dan de associatie, dan de applicatie. Elk heeft zijn eigen commando en zijn eigen faalhandtekening. Een schoon resultaat op de ene laag is geen schoon resultaat op de volgende. Voer alle vier uit voordat je een conclusie trekt. Eén groene regel beslecht zelden iets.

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

Een interface met een stijgende teller maar zonder bijbehorende state-entry beschrijft verkeer dat een pad binnenkomt waar niets het beschermt, wat erger is dan een tunnel die simpelweg down is. Een state-entry zonder route die de interface selecteert, betekent dat de cryptografie klaar en ongebruikt is.

De applicatietest komt bewust als laatste: een geslaagde ping naar de andere kant van de tunnel bewijst niet dat de dienst erachter verbindingen accepteert.

Binnenste tellers vergelijken met buitenste tellers

Tellers op de tunnelinterface meten binnenlands verkeer; tellers en captures op de fysieke interface tonen de ingekapselde uitwisseling. De twee zullen niet één op één overeenkomen, omdat inkapseling headers toevoegt, hertransmissies sommige pakketten dupliceren en de boekhouding van de implementatie eigen regels volgt. Verwacht een verhouding, geen gelijkheid.

De plaats van de capture bepaalt ook welke privégegevens je verzamelt, dus gebruik smalle filters en een onschadelijk testadres in plaats van een volledige capture van productieverkeer.

Als de binnenste tellingen stijgen en de buitenste niet, is de ontbrekende stap meestal de route of het beleid dat pakketten de tunnel in stuurt, niet de tunnel zelf.

Het volgen door rekey en failover heen

Observeer een rekey, een dead-peer-detectiegebeurtenis en een linkfailover terwijl je dezelfde vier toestanden in het oog houdt. Een interface kan aanwezig blijven tijdens een rekey die nooit voltooit, en een failover kan een state-entry achterlaten die naar een peeradres wijst dat niet meer bereikbaar is.

Alarmeer op het servicepad waar je echt van afhangt, met de associatiestatus als context, in plaats van op één up- of down-vlag. Houd de interfacenaam, het peeradres en de route in de alertpayload, zodat de responder ze niet hoeft te reconstrueren.

strongSwan documenteert zijn eigen XFRM-interfacemodel, en andere platforms noemen en implementeren het equivalente object anders. Lees de routegebaseerde vergelijking voor het apparaat dat voor je staat voordat je aannames van een andere implementatie overneemt. Een monitoringsjabloon dat bij de tellers van de ene leverancier past, misleidt stilzwijgend bij een andere.