Hva inngår i et IPsec-forslag? IKE- og ESP-felter

IKE starter, begge parter annonserer AES, og tunnelen feiler likevel med NO_PROPOSAL_CHOSEN. Loggen nevner forslaget, men ikke feltet som ikke samsvarte. Et forslag er ett komplett tilbud, og ett inkompatibelt felt ugyldiggjør hele kombinasjonen i stedet for bare den linjen. Å lese det som en pose uavhengige algoritmevalg er den vanlige grunnen til at uoverensstemmelsen forblir usynlig.

To forhandlinger med hver sin forslagsliste

IKEv2 bygger to sikkerhetsforeninger. Den første er IKE SA, som beskytter selve kontrollutvekslingen, og den andre er CHILD SA, som bærer trafikken din gjennom ESP. Hver har sin egen forslagsliste, og en part kan godta den ene og avvise den andre.

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

Rekkefølgen inne i hver liste betyr også noe. Svareren velger blant initiativtakerens ordnede tilbud, så å flytte en bredt kompatibel oppføring over en smal endrer hvilket sett som installeres, uten å endre et eneste algoritmenavn. Fest den rekkefølgen i konfigurasjonen i stedet for å stole på standardverdiene. En stabil rekkefølge gjør også logsammenligning mellom nettsteder meningsfull.

Hvilke felter som hører til hvilket forslag

Feldsettet 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 etter implementasjon; strongSwans dokumentasjon for forslag er én konkret referanse.

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

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

Hvordan ett komplett tilbud velges

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 samsvarer, sender svareren NO_PROPOSAL_CHOSEN med SA-typen som feilet. Les hvilken forslagsliste varselet gjelder før du redigerer konfigurasjonen; å endre ESP-algoritmene når IKE-forslaget ble avvist, kaster bort en feilsøkingssyklus.

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

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 parer 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 legitimt kombinere en AEAD-chiffer med en PRF og en DH-gruppe, mens det matchende 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 antok 256-bit nøkler, vil ikke samsvare 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 det er stedet for å bekrefte at en nøkkelfornyelse ikke falt tilbake til et annet sett enn det du dokumenterte.

Lagre den utskriften ved siden av konfigurasjonen etter en rettelse. Når en klientoppdatering endrer standardverdiene, gir det registrerte settet deg en basislinje å sammenligne med, og sammenligningen peker på feltet som flyttet seg i stedet for å starte undersøkelsen på nytt.