IKEv2 NO_PROPOSAL_CHOSEN: welke fase wees de suite af?

NO_PROPOSAL_CHOSEN in een logboek stuurt mensen naar de vooraf gedeelde sleutel, en de fout overleeft de wijziging. Het was nooit een probleem met inloggegevens: de peer wees elk voorstel af dat voor die uitwisseling werd aangeboden, wat een uitspraak over algoritmen is en niet over identiteit. De eerste nuttige vraag is niet welk algoritme moet worden bewerkt, maar welke uitwisseling werd afgewezen. Beantwoord dat voordat u iets vergelijkt. Vergelijk daarna de volledige aangeboden suite met de volledige suite die de peer toestaat.

Eerst: welke uitwisseling werd afgewezen

IKEv2 onderhandelt twee soorten associaties. De IKE SA beschermt de onderhandeling zelf, en de CHILD SA beschermt het verkeer. Elk heeft zijn eigen voorstellenset, en elk kan mislukken met dezelfde melding. Een afwijzing tijdens de eerste IKE-onderhandeling en een afwijzing tijdens de CHILD-onderhandeling vereisen verschillende correcties, en het logboek noemt de uitwisseling meestal een of twee regels boven de melding. Lees die twee regels samen, anders bewerkt u de verkeerde voorstellenlijst.

De melding alleen identificeert de uitwisseling niet. De regel erboven noemt de SA die wordt onderhandeld, en die naam wijst naar de voorstellenlijst die moet worden gecontroleerd.

Vergelijk volledige suites, niet losse trefwoorden

Een voorstel is een combinatie: versleutelingsalgoritme, integriteit of AEAD, sleuteluitwisselingsgroep en een eventuele pseudorandomfunctie. Alleen de naam van de versleuteling vergelijken is de gebruikelijke fout, omdat twee peers het eens kunnen zijn over AES-256 en toch van mening kunnen verschillen over SHA-1 versus SHA-256. Schrijf de aangeboden en toegestane suites naast elkaar in de mislukte fase en zoek dan de lege doorsnede.

offered:   aes256-sha256-modp2048
permitted: aes256-sha1-modp2048

Controleer ook of beide implementaties ondersteunen wat u hebt geconfigureerd. Een naam die van een ander platform is gekopieerd, kan syntactisch vertrouwd lijken terwijl de plug-in of implementatie volledig ontbreekt.

De IKE-suite en de ESP-suite zijn verschillende objecten

Het bewerken van het IKE-voorstel herstelt een afgewezen CHILD-voorstel niet, en omgekeerd geldt hetzelfde. In strongSwan zijn dit aparte instellingen, ongeveer proposals = aes256-sha256-modp2048 voor de IKE SA en een aparte ESP-lijst voor de CHILD SA. Wijzig de lijst die bij de mislukte uitwisseling hoort en lees daarna het logboek opnieuw in plaats van aan te nemen dat de correctie werkte.

Voor de CHILD SA is de relevante instelling de ESP-voorstellenlijst, niet de IKE-lijst. Het kopiëren van de IKE-regel erin levert een configuratie op die wordt geparseerd maar het verkeerde object onderhandelt.

Een werkende tunnel die faalt bij sleutelvernieuwing

Als de tunnel een uur werkte en daarna faalde, is de eerste onderhandeling niet het probleem. Een sleutelvernieuwing kan andere voorwaarden testen: een andere sleuteluitwisselingsgroep na de eerste uitwisseling, een levensduurverschil tussen peers of een gewijzigd responder-beleid. Bewaar de vernieuwingstijdstempel en de associatie-identificatoren van beide kanten. Dat patroon vereist een voorstelvergelijking bij de vernieuwing, niet een langere time-out. Een time-outwijziging verbergt het symptoom en laat de mismatch staan.

ipsec statusall toont elke associatie en de algoritmen die daadwerkelijk zijn onderhandeld. Die uitvoer is de snelste manier om te bevestigen welke lijst is gebruikt, en scheidt een configuratiefout van een verouderde tunnel die nooit opnieuw is onderhandeld.

ipsec statusall | grep -E "IKE:|ESP:"

Kies een doorsnede en bevestig daarna beide fasen

Laat de beheerder een gedocumenteerde moderne doorsnede kiezen die beide peers ondersteunen, en die opschrijven. Los de fout niet op door elk oud algoritme in te schakelen of door identiteitsverificatie uit te schakelen, want geen van beide volgt uit een afwijzing. Na de wijziging wordt een nieuwe verbinding tot stand gebracht en vervolgens wordt een sleutelvernieuwing geforceerd. De eerste verbinding alleen bewijst niet dat het vernieuwingspad werkt.

Bewaar de geaccepteerde combinatie samen met de firmwareversies. Als de volgende fout over traffic selectors gaat, behandel die dan apart, want overeenstemming over cryptografie zegt niets over welke subnetten de tunnel beschermt. De voorsteldocumentatie van strongSwan behandelt de syntaxis voor beide lijsten.