IKEv2 er ikke ét håndtryk: først IKE SA, derefter autentificering, derefter CHILD SA

Du tror måske, at en IKEv2-forbindelse er én udveksling, der slutter med, at din trafik er krypteret. Det er mindst to, og den første autentificerer ingen. Parterne begynder med kontrolmeddelelser, aftaler kryptografiske parametre, beviser identitet og forhandler først derefter den tilstand, der bærer applikationspakker. Den rækkefølge forklarer den uoverensstemmelse, folk konstant rapporterer: gatewayen svarer, klienten siger, den er forbundet, og den private applikation løber stadig tør for tid. Her er, hvad hvert trin faktisk gør, og hvad der skal være sandt bagefter.

Myten: hvis gatewayen svarer, er du forbundet

Et svar på den første meddelelse beviser, at endepunktet er tilgængeligt og villigt til at tale. Det beviser ikke, at en konto blev accepteret, at en certifikatkæde blev valideret, eller at en datapolitik blev installeret.

De fejl sker senere og giver forskellige symptomer. En certifikatafvisning eller en EAP-fejl ankommer, efter at den første udveksling allerede er lykkedes, og derfor siger en ping til UDP 500 og et grønt klientikon så lidt.

IKE_SA_INIT: enighed om parametre, ikke identitet

Den første udveksling bærer forslag til IKE-sikkerhedsassociationen: krypterings- og integritetsalgoritmer, en pseudorandomfunktion og en Diffie-Hellman-gruppe. Parterne udveksler også nonces, og hver side udleder nøglemateriale til IKE SA fra den fælles hemmelighed, som disse værdier skaber. Intet i denne udveksling fastslår, hvem den anden part er. Den fastslår, at begge sider kan beregne de samme nøgler, og at de er enige om et forslag. En responder, der ikke kan lide noget forslag, afviser udvekslingen her, og derfor ser en versions- eller algoritmeuoverensstemmelse ud som en server, der er nede.

Den IKE SA, der oprettes på dette punkt, beskytter alle senere kontroludvekslinger. Det er dens opgave, og det er en anden opgave end at beskytte dine pakker.

IKE_AUTH: bevis identitet, byg derefter den første CHILD SA

Den anden udveksling bærer identitet. Med certifikater signerer hver part med sin private nøgle og fremlægger en kæde, som den anden skal validere; med EAP udfordrer respondereren initiativtageren gennem den valgte metode. Det er her, et forkert servernavn, et udløbet certifikat eller en afvist adgangskode endelig dukker op.

I det normale tilfælde forhandler IKE_AUTH også den første CHILD SA, så databeskyttelsen aftales i samme runde. Initiativtageren foreslår trafikvælgere, respondereren indsnævrer eller afviser dem, og nøglerne til datastien udledes af IKE SA. Det betyder, at en enkelt udveksling kan fejle på to meget forskellige steder: identitet eller politik. Læs notify-payloaden eller fejlen i stedet for den generiske håndtryksfejl, fordi rettelsen for det ene er et certifikat, og rettelsen for det andet er en subnet-uoverensstemmelse.

To SA'er, to opgaver

At holde dem adskilt forklarer to adfærdsmønstre, der ligner fejl. En tunnel kan vise sig etableret, mens en nøglefornyelse fejler i baggrunden, og en CHILD SA kan udskiftes, uden at klienten mister forbindelsen.

På strongSwan viser IKEv2-konfigurationsreferencen og swanctl --list-sas begge niveauer, og ip xfrm state plus ip xfrm policy viser, hvad kernen faktisk installerede. At sammenligne disse to visninger er den hurtigste måde at se, om forhandlingen blev afsluttet, eller kun så afsluttet ud. Hvis daemonen viser en CHILD SA, som kernen ikke har tilstand for, mislykkedes installationen i stilhed. Hvis kernen har tilstand, som daemonen ikke kender, ser du en rest fra et tidligere forsøg.

Hvad der stadig skal være sandt, efter tunnelen er oppe

Trafikvælgere definerer, hvilke adresser der er dækket. Hvis klienten foreslår et subnet, og serveren forventer et andet, installeres CHILD SA, men bærer intet nyttigt, og fejlen vises som et routingproblem snarere end et forhandlingsproblem. Derefter skal den lokale stak samarbejde: videresendelse aktiveret, hvor værten router, ruter der peger mod tunnelen, firewallregler der tillader de afkapslede pakker, og en intern resolver, hvis private navne er involveret. Hver af disse fejler separat, og ingen af dem løses ved at genstarte IKE-daemonen.

Hold loggen synlig, mens du diagnosticerer: den indledende udveksling, derefter identitetsvalidering, derefter brugerautentificering, hvor det gælder, derefter CHILD-installation, derefter applikationstrafik. Det trin, der stopper, er det trin, der skal rettes, og en senere routingfejl er aldrig en grund til at lempe identitetskontrollen, som allerede er bestået.