Hva består et IPsec-forslag av? IKE- og ESP-felt

IKE starter, begge sider annonserer AES, og tunnelen feiler fortsatt med NO_PROPOSAL_CHOSEN. Loggen navngir forslaget, men ikke feltet som ikke stemte. Et forslag er ett fullstendig tilbud, og ett inkompatibelt felt gjør hele kombinasjonen ugyldig, ikke bare den ene linjen. Å lese det som en sekk med uavhengige algoritmevalg er den vanlige årsaken til at mismatchen forblir usynlig.

To forhandlinger med separate forslagslister

IKEv2 bygger to sikkerhetsforbindelser. Den første er IKE SA, som beskytter selve kontrollutvekslingen, og den andre er CHILD SA, som frakter trafikken din gjennom ESP. Hver av dem har sin egen forslagsliste, og en motpart kan godta den ene og avvise den andre.

Denne delingen forklarer en vanlig forvirring: en fungerende IKE SA beviser bare at kontrollkanalens algoritmer stemte. Hvis CHILD-forslaget feiler, frakter tunnelen ikke én eneste pakke, selv om fase én er fullført og loggene ser friske ut øverst.

Rekkefølgen inne i hver liste spiller også en rolle. Svareren velger blant initiativtakerens ordnede tilbud, så det å flytte en bredt kompatibel oppføring over en smal endrer hvilket sett som installeres, uten å endre ett eneste algoritmenavn. Lås den rekkefølgen i konfigurasjonen i stedet for å stole på standardverdier. En stabil rekkefølge gjør også sammenligning av logger mellom anlegg meningsfull.

Hvilke felt tilhører hvilket forslag

Feltsettet er lite, men det er ikke identisk i de to forhandlingene. Les tabellen rad for rad, fordi et felt i den ene kolonnen kan mangle i den andre. Syntaksen varierer mellom implementasjoner; strongSwans dokumentasjon om forslag er en konkret referanse.

Krypteringsfeltet angir chifferen og, i de fleste syntakser, nøkkellengden. Integritetsfeltet angir hashen som brukes for å autentisere chifferteksten, og PRF-en angir funksjonen som utleder nøkkelmateriale for IKE SA-en. DH-gruppen etablerer ferskt felles hemmelig materiale, og derfor dukker den opp på begge sider, men med ulike formål.

Utvidede sekvensnumre tilhører bare datastien. De utvider sekvensrommet og forhandles som en del av CHILD-forslaget, så en mismatch der avviser et CHILD-tilbud mens IKE SA-en forblir urørt.

Hvordan ett fullstendig tilbud blir valgt

Hvert forslag er et sett, og svareren leter etter et sett der hvert påkrevde felt er akseptabelt. To lister kan begge inneholde AES og SHA-256 og likevel ikke ha noen kompatibel oppføring, fordi nøkkellengden, PRF-en eller DH-gruppen er forskjellig. Sammenligningen skjer per forslag, ikke per algoritme.

Når ingenting stemmer, sender svareren NO_PROPOSAL_CHOSEN med SA-typen som feilet. Les hvilken forslagsliste varselet gjelder før du redigerer konfigurasjonen; å bytte ESP-algoritmene når IKE-forslaget ble avvist, sløser bort en feilsøkingssyklus.

Valgatferd er nyttig å kjenne når du justerer en profil. Noen implementasjoner foretrekker initiativtakerens rekkefølge, andre sorterer på nytt etter lokal policy, så et sett som fungerer mellom to leverandører kan forsvinne når du snur hvilken side som starter forbindelsen.

AEAD fjerner et felt i stedet for å legge til ett

AES-GCM og ChaCha20-Poly1305 autentiserer og krypterer i én operasjon. Når en av dem velges for ESP, forhandles ikke integritetsalgoritmen separat, fordi AEAD-konstruksjonen allerede dekker den. Et forslag som kombinerer AES-GCM med SHA-256 er derfor overflødig i beste fall og avvist i verste fall.

PRF-en er fortsatt separat på IKE-siden, siden den utleder nøkler for kontrollkanalen i stedet for å beskytte nyttelasten. Derfor kan et IKE-forslag lovlig kombinere en AEAD-chiffer med en PRF og en DH-gruppe, mens det tilhørende ESP-forslaget bare lister AEAD-chifferen og den valgfrie PFS-gruppen.

Nøkkellengden er en del av krypteringstokenet, så AES-128-GCM og AES-256-GCM er forskjellige tilbud. En profil kopiert fra en veiledning som forutsatte 256-bit nøkler, vil ikke stemme med et endepunkt konfigurert for 128-bit, selv om begge linjene sier AES-GCM. To parter kan bli enige om chifferfamilien og likevel avvise hverandre på grunn av tallet etter bindestreken.

Les den installerte SA-en, ikke konfigurasjonen

Den konfigurerte forslagslisten er et tilbud; den installerte SA-en er resultatet. På strongSwan og en Linux-kjerne er begge visningene tilgjengelige:

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

swanctl --list-sas skriver ut de forhandlede algoritmene per SA, inkludert om CHILD-en bruker AEAD. ip xfrm state viser hva kjernen faktisk installerte, og der bekrefter du at en nøkkelfornyelse ikke falt tilbake til et annet sett enn det du dokumenterte.

Ta vare på utskriften ved siden av konfigurasjonen etter en rettelse. Når en klientoppdatering endrer standardverdiene, gir det registrerte settet deg en grunnlinje å sammenligne mot, og sammenligningen peker på feltet som flyttet seg i stedet for å starte undersøkelsen fra begynnelsen.