Kva inngår i eit IPsec-framlegg? IKE- og ESP-felt

IKE startar, begge partar annonserer AES, og tunnelen feilar likevel med NO_PROPOSAL_CHOSEN. Loggen nemner framlegget, men ikkje feltet som ikkje passa. Eit framlegg er eitt komplett tilbod, og eitt inkompatibelt felt gjer heile kombinasjonen ugyldig i staden for berre den linja. Å lese det som ein pose med sjølvstendige algoritmeval er den vanlege grunnen til at usemja blir usynleg.

To forhandlingar med kvar si framleggsliste

IKEv2 byggjer to tryggingsforeiningar. Den første er IKE SA, som vernar sjølve kontrollutvekslinga, og den andre er CHILD SA, som ber trafikken din gjennom ESP. Kvar har si eiga framleggsliste, og ein part kan godta den eine og avvise den andre.

Denne delinga forklarar ei vanleg forvirring: ein fungerande IKE SA beviser berre at algoritmane i kontrollkanalen passa. Viss CHILD-framlegget feilar, ber tunnelen ikkje ein einaste pakke, sjølv om fase éin er fullført og loggane ser sunne ut øvst.

Rekkjefølgja inne i kvar liste har òg noko å seie. Svararen vel blant dei ordna tilboda til initiativtakaren, så å flytte ein breitt kompatibel oppføring over ein smal endrar kva sett som blir installert, utan å endre eit einaste algoritmenamn. Fest den rekkjefølgja i konfigurasjonen i staden for å stole på standardverdiane. Ei stabil rekkjefølgje gjer òg logsamanlikning mellom nettstadar meiningsfull.

Kva felt som høyrer til kva framlegg

Feltsettet er lite, men det er ikkje identisk i dei to forhandlingane. Les tabellen rad for rad, fordi eit felt i den eine kolonnen kan mangle i den andre. Syntaksen varierer etter implementasjon; strongSwan sin dokumentasjon for framlegg er éin konkret referanse.

Krypteringsfeltet oppgjev chifferen og, i dei fleste syntaksar, nøkkellengda. Integritetsfeltet oppgjev hashen som blir brukt til å autentisere chifferteksten, og PRF-en oppgjev funksjonen som utleier nøkkelmateriale for IKE SA-en. DH-gruppa etablerer ferskt felles hemmeleg materiale, og difor opptrer ho på begge sider, men til ulike føremål.

Utvida sekvensnummer høyrer berre til datastigen. Dei utvidar sekvensrommet og blir forhandla som ein del av CHILD-framlegget, så ei usemje der avviser eit CHILD-tilbod medan IKE SA-en blir urørd.

Korleis eitt komplett tilbod blir valt

Kvart framlegg er eit sett, og svararen leitar etter eit sett der kvart påkravde felt er akseptabelt. To lister kan begge innehalde AES og SHA-256 og likevel ikkje ha noka kompatibel oppføring, fordi nøkkellengda, PRF-en eller DH-gruppa er ulik. Samanlikninga skjer per framlegg, ikkje per algoritme.

Når ingenting passar, sender svararen NO_PROPOSAL_CHOSEN med SA-typen som feila. Les kva framleggsliste varselet gjeld før du redigerer konfigurasjonen; å endre ESP-algoritmane når IKE-framlegget vart avvist, kastar bort ein feilsøkingssyklus.

Valåtferd er verdt å kjenne når du justerer ein profil. Nokre implementasjonar føretrekkjer rekkjefølgja til initiativtakaren, andre sorterer om etter lokal policy, så eit sett som verkar mellom to leverandørar kan forsvinne når du snur kva side som startar tilkoplinga.

AEAD fjernar eit felt i staden for å leggje til eit

AES-GCM og ChaCha20-Poly1305 autentiserer og krypterer i éin operasjon. Når ein av dei blir vald for ESP, blir ikkje integritetsalgoritmen forhandla separat, fordi AEAD-konstruksjonen allereie dekkjer han. Eit framlegg som parar AES-GCM med SHA-256 er difor overflødig i beste fall og avvist i verste fall.

PRF-en er framleis separat på IKE-sida, sidan han utleier nøklar for kontrollkanalen i staden for å verne nyttelasta. Difor kan eit IKE-framlegg legitimt kombinere ein AEAD-chiffer med ein PRF og ei DH-gruppe, medan det samsvarande ESP-framlegget berre listar AEAD-chifferen og den valfrie PFS-gruppa.

Nøkkellengda er ein del av krypteringstokenet, så AES-128-GCM og AES-256-GCM er ulike tilbod. Ein profil kopiert frå ei rettleing som antok 256-bit nøklar, vil ikkje passe med eit endepunkt konfigurert for 128-bit, sjølv om begge linjene seier AES-GCM. To partar kan bli samde om chifferfamilien og likevel avvise kvarandre på grunn av talet etter bindestreken.

Les den installerte SA-en, ikkje konfigurasjonen

Den konfigurerte framleggslista er eit tilbod; den installerte SA-en er resultatet. På strongSwan og ein Linux-kjerne er begge visingane tilgjengelege:

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

swanctl --list-sas skriv ut dei forhandla algoritmane per SA, inkludert om CHILD-en brukar AEAD. ip xfrm state viser kva kjernen faktisk installerte, og det er staden for å stadfeste at ei nøkkelfornying ikkje fall tilbake til eit anna sett enn det du dokumenterte.

Lagre den utskrifta ved sida av konfigurasjonen etter ei retting. Når ein klientoppdatering endrar standardverdiane, gir det registrerte settet deg ei grunnlinje å samanlikne med, og samanlikninga peikar på feltet som flytta seg i staden for å starte granskinga på nytt.