Hvad indgår i et IPsec-forslag? IKE- og ESP-felter

IKE starter, begge parter annoncerer AES, og tunnelen fejler stadig med NO_PROPOSAL_CHOSEN. Loggen nævner forslaget, men ikke det felt, der ikke matchede. Et forslag er ét komplet tilbud, og ét inkompatibelt felt gør hele kombinationen ugyldig frem for kun den linje. At læse det som en pose uafhængige algoritmevalg er den sædvanlige grund til, at uoverensstemmelsen forbliver usynlig.

To forhandlinger med hver sin forslagsliste

IKEv2 opbygger to sikkerhedsassociationer. Den første er IKE SA, som beskytter selve kontroludvekslingen, og den anden er CHILD SA, som bærer din trafik gennem ESP. Hver har sin egen forslagsliste, og en part kan acceptere den ene og afvise den anden.

Den opdeling forklarer en almindelig forvirring: en fungerende IKE SA beviser kun, at kontrolkanalens algoritmer matchede. Hvis CHILD-forslaget fejler, bærer tunnelen ikke en eneste pakke, selvom fase et er gennemført, og loggene ser sunde ud i toppen.

Rækkefølgen inden i hver liste betyder også noget. Svareren vælger blandt initiatorernes ordnede tilbud, så at flytte en bredt kompatibel post over en snæver ændrer, hvilket sæt der installeres, uden at ændre et eneste algoritmenavn. Fastlås den rækkefølge i konfigurationen i stedet for at stole på standardværdierne. En stabil rækkefølge gør også sammenligning af logs mellem lokaliteter meningsfuld.

Hvilke felter hører til hvilket forslag

Feltsættet er lille, men det er ikke identisk i de to forhandlinger. Læs tabellen række for række, fordi et felt i den ene kolonne kan mangle i den anden. Syntaksen varierer efter implementering; strongSwans dokumentation for forslag er én konkret reference.

Krypteringsfeltet angiver chifferen og i de fleste syntakser dens nøglelængde. Integritetsfeltet angiver den hash, der bruges til at autentificere chifferteksten, og PRF'en angiver den funktion, der udleder nøglemateriale til IKE SA'en. DH-gruppen etablerer fælles hemmeligt materiale, og derfor optræder den på begge sider, men til forskellige formål.

Udvidede sekvensnumre hører kun til datastien. De udvider sekvensrummet og forhandles som en del af CHILD-forslaget, så en uoverensstemmelse der afviser et CHILD-tilbud, mens IKE SA'en forbliver urørt.

Hvordan ét komplet tilbud bliver valgt

Hvert forslag er et sæt, og svareren leder efter et sæt, hvor hvert påkrævet felt er acceptabelt. To lister kan begge indeholde AES og SHA-256 og stadig ikke have en kompatibel post, fordi nøglelængden, PRF'en eller DH-gruppen er forskellig. Sammenligningen sker per forslag, ikke per algoritme.

Når intet matcher, sender svareren NO_PROPOSAL_CHOSEN med den SA-type, der fejlede. Læs hvilken forslagsliste meddelelsen henviser til, før du redigerer konfigurationen; at ændre ESP-algoritmerne, når IKE-forslaget blev afvist, spilder en fejlfindingscyklus.

Valgadfærd er værd at kende, når du finjusterer en profil. Nogle implementeringer foretrækker initiativtagerens rækkefølge, andre omordner efter lokal politik, så et sæt, der virker mellem to leverandører, kan forsvinde når du vender, hvilken side der starter forbindelsen.

AEAD fjerner et felt i stedet for at tilføje et

AES-GCM og ChaCha20-Poly1305 autentificerer og krypterer i én operation. Når en af dem vælges til ESP, forhandles integritetsalgoritmen ikke separat, fordi AEAD-konstruktionen allerede dækker den. Et forslag, der parrer AES-GCM med SHA-256, er derfor overflødigt i bedste fald og afvist i værste fald.

PRF'en er stadig adskilt på IKE-siden, da den udleder nøgler til kontrolkanalen frem for at beskytte nyttelasten. Derfor kan et IKE-forslag legitimt kombinere en AEAD-chiffer med en PRF og en DH-gruppe, mens det matchende ESP-forslag kun angiver AEAD-chifferen og den valgfrie PFS-gruppe.

Nøglelængden er en del af krypteringstokenet, så AES-128-GCM og AES-256-GCM er forskellige tilbud. En profil kopieret fra en guide, der forudsatte 256-bit nøgler, matcher ikke et endepunkt konfigureret til 128-bit, selvom begge linjer siger AES-GCM. To parter kan blive enige om chifferfamilien og alligevel afvise hinanden på grund af tallet efter bindestregen.

Læs den installerede SA, ikke konfigurationen

Den konfigurerede forslagsliste er et tilbud; den installerede SA er resultatet. På strongSwan og en Linux-kerne er begge visninger tilgængelige:

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

swanctl --list-sas udskriver de forhandlede algoritmer per SA, inklusive om CHILD'en bruger AEAD. ip xfrm state viser, hvad kernen faktisk installerede, og det er stedet at bekræfte, at en nøglefornyelse ikke faldt tilbage til et andet sæt end det, du dokumenterede.

Gem den output ved siden af konfigurationen efter en rettelse. Når en klientopdatering ændrer sine standardværdier, giver det registrerede sæt dig en baseline at sammenligne med, og sammenligningen peger på det felt, der flyttede sig, i stedet for at starte undersøgelsen forfra.