IKEv2 no és una sola encaixada de mans: primer IKE SA, després autenticació, després CHILD SA
Una resposta de la passarel·la demostra abastabilitat, no identitat. Seguiu IKE_SA_INIT, IKE_AUTH i la primera CHILD SA i comproveu després què ha de ser cert abans que passi el trànsit.
Potser penseu que una connexió IKEv2 és un sol intercanvi que acaba amb el vostre trànsit xifrat. En realitat són com a mínim dos, i el primer no autentica ningú. Els parells comencen amb missatges de control, acorden paràmetres criptogràfics, proven la identitat i només després negocien l'estat que transporta els paquets de les aplicacions. Aquest ordre explica la discrepància que la gent reporta constantment: la passarel·la respon, el client diu que està connectat i l'aplicació privada encara acaba amb un temps d'espera esgotat. Aquí teniu què fa realment cada etapa i què ha de ser cert després.
El mite: si la passarel·la respon, esteu connectats
Una resposta al primer missatge demostra que el punt final és accessible i que vol parlar. No demostra que s'hagi acceptat un compte, que s'hagi validat una cadena de certificats ni que s'hagi instal·lat cap política de dades.
Aquests errors arriben més tard i produeixen símptomes diferents. Un rebuig de certificat o un error d'EAP arriba després que el primer intercanvi ja hagi tingut èxit, i per això un ping a UDP 500 i una icona verda del client diuen tan poc.
IKE_SA_INIT: acordar paràmetres, no identitat
El primer intercanvi porta propostes per a l'associació de seguretat IKE: algorismes de xifratge i integritat, una funció pseudoaleatòria i un grup Diffie-Hellman. Els parells també intercanvien nonces, i cada costat deriva material de clau per a la IKE SA a partir del secret compartit que produeixen aquests valors. Res en aquest intercanvi estableix qui és l'altra part. Estableix que tots dos costats poden calcular les mateixes claus i que estan d'acord amb una proposta. Un responedor a qui no li agrada cap proposta rebutja l'intercanvi aquí, i per això una discrepància de versió o d'algorisme sembla que el servidor estigui caigut.
La IKE SA creada en aquest moment protegeix tots els intercanvis de gestió posteriors. Aquesta és la seva feina, i és una feina diferent de protegir els vostres paquets.
IKE_AUTH: demostrar la identitat i després construir la primera CHILD SA
El segon intercanvi porta la identitat. Amb certificats, cada parell signa amb la seva clau privada i presenta una cadena que l'altre ha de validar; amb EAP, el responedor desafia l'iniciador mitjançant el mètode triat. Aquí finalment surt un nom de servidor incorrecte, un certificat caducat o una contrasenya rebutjada.
En el cas normal, IKE_AUTH també negocia la primera CHILD SA, de manera que la protecció de dades s'acorda en el mateix viatge. L'iniciador proposa selectors de trànsit, el responedor els estreny o els rebutja, i les claus per al camí de dades es deriven de la IKE SA. Això vol dir que un sol intercanvi pot fallar en dos llocs molt diferents: la identitat o la política. Llegiu la càrrega útil de notify o l'error en lloc del fracàs genèric de l'encaixada, perquè la solució d'un és un certificat i la de l'altre és una discrepància de subxarxa.
Dues SA, dues feines
| Association | Protects | Lifetime behaviour |
|---|---|---|
| IKE SA | Management exchanges: rekeying, delete, configuration payloads | Rekeyed on its own schedule; the data path can survive the change |
| CHILD SA | Application traffic matching the traffic selectors | Rekeyed independently, often more frequently |
Mantenir-les separades explica dos comportaments que semblen errors. Un túnel pot aparèixer establert mentre una renovació de claus falla en segon pla, i una CHILD SA es pot substituir sense que el client perdi la connexió.
A strongSwan, la referència de configuració d'IKEv2 i swanctl --list-sas mostren tots dos nivells, i ip xfrm state més ip xfrm policy mostren què ha instal·lat realment el nucli. Comparar aquestes dues vistes és la manera més ràpida de veure si la negociació ha acabat o només ho semblava. Si el dimoni llista una CHILD SA per a la qual el nucli no té estat, la instal·lació ha fallat en silenci. Si el nucli té estat que el dimoni no coneix, esteu veient una resta d'un intent anterior.
Què encara ha de ser cert després d'aixecar el túnel
Els selectors de trànsit defineixen quines adreces queden cobertes. Si el client proposa una subxarxa i el servidor n'espera una altra, la CHILD SA s'instal·la però no porta res d'útil, i l'error apareix com un problema d'encaminament i no de negociació. Després la pila local ha de col·laborar: reenviament activat on l'amfitrió encamina, rutes apuntant al túnel, regles de tallafocs que permetin els paquets desencapsulats i un resolutor intern si hi ha noms privats. Cadascun d'aquests falla per separat i cap es corregeix reiniciant el dimoni IKE.
Manteniu el registre visible mentre diagnostiqueu: l'intercanvi inicial, després la validació d'identitat, després l'autenticació d'usuari quan correspongui, després la instal·lació de la CHILD i després el trànsit de les aplicacions. L'etapa que s'atura és l'etapa que cal corregir, i un error d'encaminament posterior no és mai una raó per relaxar les comprovacions d'identitat que ja han passat.