Wat zit er in een IPsec-voorstel? IKE- en ESP-velden

IKE start, beide peers adverteren AES, en de tunnel faalt toch met NO_PROPOSAL_CHOSEN. Het log noemt het voorstel maar niet het veld dat niet overeenkwam. Een voorstel is één compleet aanbod, en één incompatibel veld maakt de hele combinatie ongeldig in plaats van alleen die regel. Het lezen als een zak losse algoritmekeuzen is de gebruikelijke reden waarom de afwijking onzichtbaar blijft.

Twee onderhandelingen met aparte voorstellenlijsten

IKEv2 bouwt twee beveiligingsassociaties. De eerste is de IKE SA, die de controle-uitwisseling zelf beschermt, en de tweede is de CHILD SA, die uw verkeer via ESP vervoert. Elk heeft een eigen voorstellenlijst, en een peer kan de ene accepteren en de andere weigeren.

Die splitsing verklaart een veelvoorkomende verwarring: een werkende IKE SA bewijst alleen dat de algoritmen van het controlekanaal overeenkwamen. Als het CHILD-voorstel mislukt, vervoert de tunnel geen enkel pakket, ook al is fase één voltooid en zien de logboeken er bovenin gezond uit.

De volgorde binnen elke lijst is ook belangrijk. De responder kiest uit de geordende aanbiedingen van de initiator, dus een breed compatibele vermelding boven een smalle zetten verandert welke suite wordt geïnstalleerd zonder één algoritmenaam te wijzigen. Leg die volgorde vast in de configuratie in plaats van op standaardwaarden te vertrouwen. Een stabiele volgorde maakt ook logvergelijking tussen locaties zinvol.

Welke velden bij welk voorstel horen

De veldenset is klein, maar niet identiek in de twee onderhandelingen. Lees de tabel rij voor rij, want een veld in de ene kolom kan in de andere ontbreken. De syntaxis verschilt per implementatie; de voorsteldocumentatie van strongSwan is één concreet aanknopingspunt.

Het versleutelingsveld noemt de cipher en, in de meeste syntaxen, de sleutellengte. Het integriteitsveld noemt de hash waarmee de ciphertext wordt geauthenticeerd, en de PRF noemt de functie die sleutelmateriaal afleidt voor de IKE SA. De DH-groep stelt vers gedeeld geheim materiaal vast, daarom verschijnt die aan beide zijden maar met verschillende doelen.

Uitgebreide volgnummers horen alleen bij het datapad. Ze verruimen de volgorderuimte en worden onderhandeld als deel van het CHILD-voorstel, dus een afwijking daar weigert een CHILD-aanbod terwijl de IKE SA onaangetast blijft.

Hoe één volledig aanbod wordt geselecteerd

Elk voorstel is een set, en de responder zoekt een set waarin elk verplicht veld acceptabel is. Twee lijsten kunnen beide AES en SHA-256 bevatten en toch geen compatibele vermelding hebben, omdat de sleutellengte, de PRF of de DH-groep verschilt. De vergelijking gebeurt per voorstel, niet per algoritme.

Als niets overeenkomt, stuurt de responder NO_PROPOSAL_CHOSEN met het SA-type dat faalde. Lees op welke voorstellenlijst de melding betrekking heeft voordat u de configuratie aanpast; de ESP-algoritmen wijzigen terwijl het IKE-voorstel is geweigerd, verspilt een debug-cyclus.

Selectiegedrag is de moeite waard om te kennen wanneer u een profiel afstemt. Sommige implementaties geven de voorkeur aan de volgorde van de initiator, andere herordenen volgens lokaal beleid, dus een suite die tussen twee leveranciers werkt, kan verdwijnen wanneer u omdraait welke kant de verbinding start.

AEAD verwijdert een veld in plaats van er een toe te voegen

AES-GCM en ChaCha20-Poly1305 authenticeren en versleutelen in één bewerking. Wanneer een van beide voor ESP wordt gekozen, wordt het integriteitsalgoritme niet apart onderhandeld, omdat de AEAD-constructie het al dekt. Een voorstel dat AES-GCM met SHA-256 combineert is daarom op zijn best overbodig en op zijn slechtst geweigerd.

De PRF blijft aan de IKE-kant apart, omdat die sleutels afleidt voor het controlekanaal in plaats van payloads te beschermen. Daarom kan een IKE-voorstel een AEAD-cipher terecht combineren met een PRF en een DH-groep, terwijl het bijpassende ESP-voorstel alleen de AEAD-cipher en de optionele PFS-groep vermeldt.

De sleutellengte hoort bij het versleutelingstoken, dus AES-128-GCM en AES-256-GCM zijn verschillende aanbiedingen. Een profiel dat uit een gids is gekopieerd die 256-bit sleutels aannam, past niet bij een eindpunt dat voor 128-bit is geconfigureerd, ook al zeggen beide regels AES-GCM. Twee peers kunnen het eens worden over de cipher-familie en elkaar toch afwijzen vanwege het getal achter het streepje.

Lees de geïnstalleerde SA, niet de configuratie

De geconfigureerde voorstellenlijst is een aanbod; de geïnstalleerde SA is het resultaat. Op strongSwan en een Linux-kernel zijn beide weergaven beschikbaar:

sudo swanctl --list-sas
sudo ip xfrm state
sudo ip xfrm policy

swanctl --list-sas drukt de onderhandelde algoritmen per SA af, inclusief of de CHILD AEAD gebruikt. ip xfrm state laat zien wat de kernel werkelijk heeft geïnstalleerd, en daar bevestigt u dat een sleutelvernieuwing niet is teruggevallen op een andere suite dan de gedocumenteerde.

Bewaar die uitvoer na een correctie naast de configuratie. Wanneer een clientupdate zijn standaardwaarden wijzigt, geeft de vastgelegde suite u een basislijn om mee te vergelijken, en de vergelijking wijst het veld aan dat verschoof in plaats van het onderzoek van voren af aan te beginnen.