IKEv2 NO_PROPOSAL_CHOSEN: hvilket trin afviste sættet?

NO_PROPOSAL_CHOSEN i en log sender folk mod den forhåndsdelt nøgle, og fejlen overlever ændringen. Det var aldrig et legitimationsproblem: peer'en afviste hvert forslag, der blev tilbudt til den udveksling, hvilket er en udtalelse om algoritmer og ikke om identitet. Det første nyttige spørgsmål er ikke, hvilken algoritme der skal redigeres, men hvilken udveksling der blev afvist. Besvar det, før du sammenligner noget. Sammenlign derefter det fulde sæt, der blev tilbudt, med det fulde sæt, peer'en tillader.

Først: hvilken udveksling blev afvist

IKEv2 forhandler to slags associeringer. IKE SA beskytter selve forhandlingen, og CHILD SA beskytter trafikken. Hver har sit eget forslagssæt, og hver kan fejle med samme notifikation. En afvisning under den indledende IKE-forhandling og en afvisning under CHILD-forhandlingen kræver forskellige rettelser, og loggen navngiver normalt udvekslingen en linje eller to over notifikationen. Læs de to linjer sammen, ellers redigerer du den forkerte forslagsliste.

Notifikationen alene identificerer ikke udvekslingen. Linjen over den navngiver den SA, der forhandles, og navnet peger på den forslagsliste, der skal undersøges.

Sammenlign komplette sæt, ikke enkelte nøgleord

Et forslag er en kombination: krypteringsalgoritme, integritet eller AEAD, nøgleudvekslingsgruppe og eventuel pseudotilfældig funktion. At sammenligne kun krypteringsnavnet er den sædvanlige fejl, fordi to peers kan være enige om AES-256 og stadig uenige om SHA-1 kontra SHA-256. Skriv de tilbudte og tilladte sæt side om side på det trin, der fejlede, og led derefter efter den tomme fællesmængde.

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

Kontroller også, at begge implementeringer understøtter det, du har konfigureret. Et navn kopieret fra en anden platform kan se syntaktisk velkendt ud mens pluginnet eller implementeringen helt mangler.

IKE-sæt og ESP-sæt er forskellige objekter

Redigering af IKE-forslaget reparerer ikke et afvist CHILD-forslag, og det omvendte gælder også. I strongSwan er disse separate indstillinger, omtrent proposals = aes256-sha256-modp2048 til IKE SA og en separat ESP-liste til CHILD SA. Skift den liste, der svarer til den fejlede udveksling, og læs derefter loggen igen i stedet for at antage, at rettelsen virkede.

For CHILD SA er den relevante indstilling ESP-forslagslisten, ikke IKE-listen. Kopiering af IKE-linjen ind i den giver en konfiguration, der parser og forhandler det forkerte objekt.

En fungerende tunnel, der fejler ved rekey

Hvis tunnelen kørte i en time og derefter fejlede, er den indledende forhandling ikke problemet. En rekey kan udsætte for andre betingelser: en anden nøgleudvekslingsgruppe efter den første udveksling, en lifetime-uoverensstemmelse mellem peers eller en ændret responder-politik. Bevar fornyelsestidsstemplet og associerings-id'erne fra begge sider. Det mønster kræver en forslagssammenligning ved fornyelsen, ikke en længere timeout. En timeoutændring skjuler symptomet og lader uoverensstemmelsen blive.

ipsec statusall viser hver associering og de algoritmer, der faktisk blev forhandlet. Det output er den hurtigste måde at bekræfte, hvilken liste der blev brugt, og det adskiller en konfigurationsfejl fra en forældet tunnel, der aldrig blev genforhandlet.

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

Vælg en fællesmængde, og bekræft derefter begge faser

Lad administratoren vælge en dokumenteret moderne fællesmængde, som begge peers understøtter, og skriv den ned. Løs ikke fejlen ved at aktivere alle gamle algoritmer eller ved at deaktivere identitetsbekræftelse, for ingen af delene følger af en afvisning. Efter ændringen etableres en ny forbindelse, og derefter fremtvinges en rekey. Den første forbindelse alene beviser ikke, at fornyelsesvejen virker.

Bevar den accepterede kombination sammen med firmwareversionerne. Hvis den næste fejl handler om traffic selectors, skal den behandles separat, da enighed om kryptografi intet siger om, hvilke subnets tunnelen beskytter. strongSwans forslagsdokumentation dækker syntaksen for begge lister.