Vad ingår i ett IPsec-förslag? IKE- och ESP-fält

IKE startar, båda parterna annonserar AES, och tunneln misslyckas ändå med NO_PROPOSAL_CHOSEN. Loggen namnger förslaget men inte fältet som inte stämde. Ett förslag är ett komplett erbjudande, och ett enda inkompatibelt fält ogiltigförklarar hela kombinationen i stället för bara den raden. Att läsa det som en påse oberoende algoritmval är det vanliga skälet till att avvikelsen förblir osynlig.

Två förhandlingar med separata förslagslistor

IKEv2 bygger två säkerhetsassociationer. Den första är IKE SA, som skyddar själva kontrollutbytet, och den andra är CHILD SA, som bär din trafik genom ESP. Var och en har sin egen förslagslista, och en part kan acceptera den ena och avvisa den andra.

Den uppdelningen förklarar en vanlig förvirring: en fungerande IKE SA bevisar bara att kontrollkanalens algoritmer stämde. Om CHILD-förslaget misslyckas bär tunneln inte ett enda paket, trots att fas ett är klar och loggarna ser friska ut högst upp.

Ordningen inuti varje lista spelar också roll. Svararen väljer bland initiativtagarens ordnade erbjudanden, så att flytta en brett kompatibel post ovanför en smal ändrar vilken svit som installeras utan att ändra ett enda algoritmnamn. Lås den ordningen i konfigurationen i stället för att förlita dig på standardvärden. En stabil ordning gör också loggjämförelser mellan platser meningsfulla.

Vilka fält som hör till vilket förslag

Fältmängden är liten, men den är inte identisk i de två förhandlingarna. Läs tabellen rad för rad, eftersom ett fält i den ena kolumnen kan saknas i den andra. Syntaxen varierar mellan implementationer; strongSwans dokumentation för förslag är en konkret referens.

Krypteringsfältet anger chiffret och, i de flesta syntaxer, dess nyckellängd. Integritetsfältet anger hashen som används för att autentisera chiffertexten, och PRF:n anger funktionen som härleder nyckelmaterial för IKE SA. DH-gruppen etablerar färskt gemensamt hemligt material, vilket är varför den förekommer på båda sidor men för olika syften.

Utökade sekvensnummer hör bara till datavägen. De vidgar sekvensutrymmet och förhandlas som en del av CHILD-förslaget, så en avvikelse där avvisar ett CHILD-erbjudande medan IKE SA lämnas orörd.

Hur ett komplett erbjudande väljs

Varje förslag är en mängd, och svararen letar efter en mängd där varje obligatoriskt fält är acceptabelt. Två listor kan båda innehålla AES och SHA-256 och ändå inte ha någon kompatibel post, eftersom nyckellängden, PRF:n eller DH-gruppen skiljer sig. Jämförelsen sker per förslag, inte per algoritm.

När ingenting stämmer skickar svararen NO_PROPOSAL_CHOSEN med den SA-typ som misslyckades. Läs vilken förslagslista meddelandet avser innan du redigerar konfigurationen; att byta ESP-algoritmerna när IKE-förslaget avvisades slösar bort en felsökningscykel.

Valbeteendet är värt att känna till när du justerar en profil. Vissa implementationer föredrar initiativtagarens ordning, andra sorterar om enligt lokal policy, så en svit som fungerar mellan två leverantörer kan försvinna när du vänder vilken sida som startar anslutningen.

AEAD tar bort ett fält i stället för att lägga till ett

AES-GCM och ChaCha20-Poly1305 autentiserar och krypterar i en enda operation. När någon av dem väljs för ESP förhandlas inte integritetsalgoritmen separat, eftersom AEAD-konstruktionen redan täcker den. Ett förslag som parar AES-GCM med SHA-256 är därför överflödigt i bästa fall och avvisat i värsta fall.

PRF:n är fortfarande separat på IKE-sidan, eftersom den härleder nycklar för kontrollkanalen i stället för att skydda nyttolasten. Därför kan ett IKE-förslag legitimt kombinera ett AEAD-chiffer med en PRF och en DH-grupp, medan det matchande ESP-förslaget bara listar AEAD-chiffret och den valfria PFS-gruppen.

Nyckellängden är en del av krypteringstoken, så AES-128-GCM och AES-256-GCM är olika erbjudanden. En profil kopierad från en guide som antog 256-bit nycklar matchar inte en slutpunkt konfigurerad för 128-bit, även om båda raderna säger AES-GCM. Två parter kan enas om chifferfamiljen och ändå avvisa varandra på grund av talet efter bindestrecket.

Läs den installerade SA:n, inte konfigurationen

Den konfigurerade förslagslistan är ett erbjudande; den installerade SA:n är resultatet. På strongSwan och en Linux-kärna är båda vyerna tillgängliga:

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

swanctl --list-sas skriver ut de förhandlade algoritmerna per SA, inklusive om CHILD använder AEAD. ip xfrm state visar vad kärnan faktiskt installerade, och där bekräftar du att en nyckelförnyelse inte föll tillbaka på en annan svit än den du dokumenterade.

Spara utskriften bredvid konfigurationen efter en rättelse. När en klientuppdatering ändrar sina standardvärden ger den registrerade sviten dig en baslinje att jämföra mot, och jämförelsen pekar på fältet som flyttade sig i stället för att börja utredningen från början.