IKEv2 NO_PROPOSAL_CHOSEN: vilket steg avvisade sviten?

NO_PROPOSAL_CHOSEN i en logg skickar folk till den fördelade nyckeln, och felet överlever ändringen. Det var aldrig ett problem med inloggningsuppgifter: peeren avvisade varje förslag som erbjöds för det utbytet, vilket är ett uttalande om algoritmer och inte om identitet. Den första användbara frågan är inte vilken algoritm som ska redigeras, utan vilket utbyte som avvisades. Svara på det innan du jämför något. Jämför sedan den fullständiga erbjudna sviten med den fullständiga svit som peeren tillåter.

Först: vilket utbyte som avvisades

IKEv2 förhandlar två typer av associationer. IKE SA skyddar själva förhandlingen, och CHILD SA skyddar trafiken. Var och en har sin egen förslaguppsättning, och var och en kan misslyckas med samma avisering. En avvisning under den inledande IKE-förhandlingen och en avvisning under CHILD-förhandlingen kräver olika korrigeringar, och loggen namnger vanligtvis utbytet en eller två rader ovanför aviseringen. Läs de två raderna tillsammans, annars redigerar du fel förslagslista.

Aviseringen ensam identifierar inte utbytet. Raden ovanför namnger den SA som förhandlas, och det namnet pekar på förslagslistan som ska granskas.

Jämför kompletta sviter, inte enskilda nyckelord

Ett förslag är en kombination: krypteringsalgoritm, integritet eller AEAD, nyckelutbytesgrupp och eventuell pseudoslumpfunktion. Att bara jämföra krypteringsnamnet är det vanliga felet, eftersom två peerar kan enas om AES-256 och fortfarande vara oense om SHA-1 kontra SHA-256. Skriv de erbjudna och tillåtna sviterna sida vid sida i det misslyckade steget och leta sedan efter den tomma snittmängden.

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

Kontrollera också att båda implementationerna stöder det du har konfigurerat. Ett namn som kopierats från en annan plattform kan se syntaktiskt bekant ut medan insticksprogrammet eller implementationen helt saknas.

IKE-sviten och ESP-sviten är olika objekt

Att redigera IKE-förslaget reparerar inte ett avvisat CHILD-förslag, och det omvända gäller också. I strongSwan är dessa separata inställningar, ungefär proposals = aes256-sha256-modp2048 för IKE SA och en separat ESP-lista för CHILD SA. Ändra listan som motsvarar det misslyckade utbytet och läs sedan loggen igen i stället för att anta att korrigeringen fungerade.

För CHILD SA är den relevanta inställningen ESP-förslagslistan, inte IKE-listan. Att kopiera IKE-raden dit ger en konfiguration som tolkas men förhandlar fel objekt.

En fungerande tunnel som misslyckas vid nyckelförnyelse

Om tunneln körde i en timme och sedan misslyckades är den inledande förhandlingen inte problemet. En nyckelförnyelse kan pröva andra villkor: en annan nyckelutbytesgrupp efter det första utbytet, en livstidsskillnad mellan peerarna eller en ändrad responder-policy. Behåll förnyelsens tidsstämpel och associationsidentifierarna från båda sidor. Det mönstret kräver en förslagsjämförelse vid förnyelsen, inte en längre timeout. En timeoutändring döljer symtomet och lämnar avvikelsen kvar.

ipsec statusall visar varje association och de algoritmer som faktiskt förhandlades. Den utskriften är det snabbaste sättet att bekräfta vilken lista som användes, och den skiljer ett konfigurationsfel från en föråldrad tunnel som aldrig förhandlades om.

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

Välj en snittmängd och bekräfta sedan båda faserna

Låt administratören välja en dokumenterad modern snittmängd som båda peerarna stöder och skriva ned den. Lös inte felet genom att aktivera alla gamla algoritmer eller genom att stänga av identitetsverifiering, eftersom ingen av dem följer av en avvisning. Efter ändringen upprättas en ny anslutning och därefter framtvingas en nyckelförnyelse. Enbart den första anslutningen bevisar inte att förnyelsevägen fungerar.

Behåll den accepterade kombinationen tillsammans med firmware-versionerna. Om nästa fel gäller trafikväljare, hantera det separat, eftersom enighet om kryptografi inte säger något om vilka subnät tunneln skyddar. strongSwans förslagsdokumentation täcker syntaxen för båda listorna.