IPsec ESP: wat het draagt en hoe je bewijst dat het stroomt

ESP draagt het verkeer in een IPsec-VPN, en de runbook ervan begint met één regel: lees de beveiligingsassociatie voordat je een beleid wijzigt. Het meeste onverklaarde ESP-gedrag valt terug op een selector die niet overeenkwam, een modus die werd aangenomen in plaats van gelezen, of een teller die niemand controleerde terwijl één stroom werd verzonden. De drie stappen hieronder stellen vast wat wat draagt, bewijzen dat één stroom het gebruikt, en laten een terugdraai achter die niet van het geheugen afhangt. Elke stap levert één observatie op die het noteren waard is.

Ken de velden voordat je ze leest

ESP zet een header voor de beschermde gegevens en een trailer erachter. De header draagt een beveiligingsparameterindex die aangeeft welke associatie de ontvanger moet gebruiken, een volgnummer voor het herkennen van herhaling, en in de trailer opvulling die de payload voor het cijfer uitgelijnd houdt. Het veld voor de volgende header in de trailer zegt wat de beschermde inhoud is, en zo weet de ontvanger wat hij heeft gedecapsuleerd.

De modus verandert wat binnen die bescherming zit. In tunnelmodus is het beschermde materiaal een volledig binnenste IP-pakket, en een nieuwe buitenste header draagt het tussen de eindpunten. In transportmodus wikkelt de bescherming de payload van de bovenste laag van een bestaand pakket, dus er is geen tweede IP-header om te openen. Welke modus in gebruik is, is een configuratiegegeven en geen kwestie van interpretatie. Lees het uit de statusregel in plaats van het uit een diagram af te leiden.

Geen van beide modi verbergt de buitenste adressering die het pakket moet afleveren. Dat is een eigenschap van het ontwerp en geen tekortkoming, en daarom kan een waarnemer ertussen nog steeds zien welke twee adressen praten, zelfs wanneer de payload ondoorzichtig is.

Stap één: lees de status, dan het beleid

De statusregels houden de sleutels en tellers; de beleidsregels houden de selectors die bepalen wat ze mag gebruiken. Op Linux zijn beide zichtbaar zonder pakketopname, en ze in die volgorde lezen houdt de twee vragen gescheiden.

ip xfrm state
ip xfrm policy

Controleer in de statusuitvoer de bron en bestemming van de associatie, de modus, en of de inkapseling UDP-poorten toont. Die poorten betekenen dat NAT-traversal wordt gebruikt, wat verandert wat een firewall ertussen moet toestaan, maar niet welke selectors of sleutels op de eindpunten gelden.

Lees dan de selectors in het beleid. Een selector die een smaller prefix noemt dan het verkeer dat je test, is de meest voorkomende reden dat een werkende tunnel een stroom lijkt te negeren, en een selector voor het verkeerde protocol geeft dezelfde stilte.

Leveranciershulpmiddelen drukken dezelfde informatie af in een vriendelijker vorm. ipsec statusall op strongSwan somt het de kindassociaties, hun selectors en hun bytetellers op, wat vaak sneller is dan ruwe xfrm-uitvoer lezen wanneer je al weet welk kind je moet bekijken.

Stap twee: bewijs dat één stroom de tellers verzet

Tellers zijn alleen betekenisvol als je weet wat ze had moeten verzetten, dus kies een bron en bestemming die de selector zeker dekt en stuur één onschadelijk verzoek. Lees dan dezelfde regel opnieuw en vergelijk.

ip -s xfrm state
tcpdump -ni any esp

Twee metingen vertellen verschillende verhalen. Pakketten die aan de uitgaande kant oplopen maar nooit aan de inkomende, wijzen op een doorstuur- of terugwegprobleem in plaats van een sleutelprobleem, omdat het pakket werd ingekapseld en vertrok. Als geen enkele teller beweegt, heeft het verkeer nooit bij het beleid gepast, en de selector is de plek om te kijken.

De opname in dezelfde stap bevestigt de inkapseling op de lijn, inclusief of de buitenste pakketten ESP zijn of UDP-ingekapselde ESP. Ze toont je ook de adressen die de stroom werkelijk droegen, en die verschillen soms van die in de configuratie die je las.

Stap drie: verander één ding en houd een terugdraai

Noteer de bron, bestemming, modus, selectors en tellers van de associatie voordat je iets bewerkt. Als een wijziging de zaak verslechtert, is juist die notitie wat je in staat stelt de vorige toestand te herstellen in plaats van een werkende configuratie uit een gok opnieuw op te bouwen. Die notitie kost een minuut en bespaart later een uur. Het is ook het enige artefact dat de persoon die de wijziging maakte overleeft.

Verander één selector of één parameter, herlaad hem, en herhaal stap twee op dezelfde stroom. Een associatie verwijderen sloopt elke stroom die hem gebruikt, dus een gerichte bewerking en een herlaad van het kind zijn bijna altijd beter dan de status leegmaken om te zien wat er gebeurt.

De terugdraai van een selectorwijziging is het vorige beleid herstellen en opnieuw laden, met de kanttekening dat de peer een overeenkomstige wijziging nodig kan hebben als de selector wordt onderhandeld en niet lokaal is. Schrijf die afhankelijkheid op zolang ze vers is, want een half hersteld paar is moeilijker te doordenken dan elk van beide eindtoestanden.

Houd ten slotte de reikwijdte eerlijk. Een stromende ESP-associatie bewijst dat de twee gateways het segment beschermen en afleveren, en ze zegt niets over of de applicatie erboven haar gebruikers authenticeert of versleutelt wat ze opslaat. Dat zijn afzonderlijke controles met afzonderlijk bewijs, en de runbook is pas af als de volgende persoon hem vanuit de notities kan herhalen.