IKEv2 är inte ett enda handslag: IKE SA, autentisering och sedan CHILD SA
Gatewayens svar bevisar nåbarhet, inte identitet. Följ IKE_SA_INIT, IKE_AUTH och den första CHILD SA och kontrollera sedan vad som måste vara sant innan trafiken flyter.
Du tror kanske att en IKEv2-anslutning är ett enda utbyte som slutar med krypterad trafik. Det är minst två, och det första autentiserar ingen. Parterna börjar med kontrollmeddelanden, kommer överens om kryptografiska parametrar, bevisar identitet och förhandlar först därefter om tillståndet som bär applikationspaketen. Den ordningen förklarar missförhållandet som folk ständigt rapporterar: gatewayen svarar, klienten säger ansluten och den privata applikationen får ändå timeout. Här är vad varje steg faktiskt gör och vad som måste vara sant efter det.
Myten: om gatewayen svarar är du ansluten
Ett svar på det första meddelandet bevisar att ändpunkten är nåbar och villig att prata. Det bevisar inte att ett konto accepterades, att en certifikatkedja validerades eller att någon datapolicy installerades.
Dessa fel inträffar senare och ger olika symtom. En certifikatavvisning eller ett EAP-fel kommer efter att det första utbytet redan lyckats, därför säger en ping mot UDP 500 och en grön klientikon så lite.
IKE_SA_INIT: kom överens om parametrar, inte identitet
Det första utbytet bär förslagen till IKE-säkerhetsassociationen: krypterings- och integritetsalgoritmer, en pseudoslumpfunktion och en Diffie-Hellman-grupp. Parterna utbyter också nonce-värden, och varje sida härleder nyckelmaterial för IKE SA från den delade hemlighet som dessa värden skapar. Ingenting i detta utbyte fastställer vem den andra parten är. Det fastställer bara att båda sidor kan beräkna samma nycklar och att de är överens om ett förslag. En svarare som inte gillar något förslag avvisar utbytet här, därför ser en versions- eller algoritmavvikelse ut som en server som ligger nere.
Den IKE SA som skapas här skyddar alla senare hanteringsutbyten. Det är dess jobb, och det är ett annat jobb än att skydda dina paket.
IKE_AUTH: bevisa identitet och bygg sedan den första CHILD SA
Det andra utbytet bär identitet. Med certifikat signerar varje part med sin privata nyckel och visar en kedja som den andra måste validera; med EAP utmanar svararen initiativtagaren genom den valda metoden. Här dyker till slut ett felaktigt servernamn, ett utgånget certifikat eller ett avvisat lösenord upp.
Normalt förhandlar IKE_AUTH också den första CHILD SA, så dataskyddet avtalas i samma tur. Initiativtagaren föreslår trafikväljare, svararen snävar in eller avvisar dem, och nycklarna för datavägen härleds från IKE SA. Det betyder att ett enda utbyte kan misslyckas på två mycket olika ställen: identitet eller policy. Läs aviseringslasten eller felet i stället för det generiska handslagsfelet, eftersom rättelsen för det ena är ett certifikat och för det andra en subnätavvikelse.
Två SA, två jobb
| Association | Skyddar | Livstidsbeteende |
|---|---|---|
| IKE SA | Hanteringsutbyten: nyckelförnyelse, borttagning, konfigurationslaster | Förnyas enligt sitt eget schema; datavägen kan överleva ändringen |
| CHILD SA | Applikationstrafik som matchar trafikväljarna | Förnyas oberoende, ofta oftare |
Att hålla dem isär förklarar två beteenden som ser ut som buggar. En tunnel kan visas som upprättad medan nyckelförnyelse misslyckas i bakgrunden, och en CHILD SA kan bytas ut utan att klienten tappar anslutningen.
På strongSwan visar IKEv2-konfigurationsreferensen och swanctl --list-sas båda nivåerna, och ip xfrm state tillsammans med ip xfrm policy visar vad kärnan faktiskt installerade. Att jämföra dessa två vyer är det snabbaste sättet att se om förhandlingen slutfördes eller bara verkade slutförd. Om daemonen listar en CHILD SA som kärnan inte har något tillstånd för, misslyckades installationen tyst. Om kärnan har tillstånd som daemonen inte känner till ser du en rest från ett tidigare försök.
Vad som fortfarande måste vara sant när tunneln är uppe
Trafikväljarna definierar vilka adresser som täcks. Om klienten föreslår ett subnät och servern förväntar sig ett annat, installeras CHILD SA men bär ingenting användbart, och felet visas som ett routningsproblem och inte ett förhandlingsproblem. Sedan måste den lokala stacken samarbeta: vidarebefordran aktiverad där värden routar, rutter mot tunneln, brandväggsregler som tillåter de dekapsulerade paketen och en intern resolver om privata namn är inblandade. Var och en av dessa misslyckas separat och ingen av dem åtgärdas genom att starta om IKE-daemonen.
Håll loggen synlig medan du diagnostiserar: det första utbytet, sedan identitetsvalidering, sedan användarautentisering där det gäller, sedan CHILD-installation och till slut applikationstrafik. Steget som stannar är steget att åtgärda, och ett senare routningsfel är aldrig skäl att lätta på identitetskontrollerna som redan passerat.