IKEv2 nu este un singur schimb: IKE SA, autentificare, apoi CHILD SA

S-ar putea să crezi că o conexiune IKEv2 este un singur schimb care se termină cu traficul tău criptat. Sunt cel puțin două, iar primul nu autentifică pe nimeni. Perechile încep cu mesaje de control, cad de acord asupra parametrilor criptografici, își dovedesc identitatea și abia apoi negociază starea care transportă pachetele aplicației. Această ordine explică nepotrivirea pe care oamenii o raportează constant: gateway-ul răspunde, clientul spune conectat, iar aplicația privată tot expiră. Iată ce face de fapt fiecare etapă și ce trebuie să fie adevărat după ea.

Mitul: dacă gateway-ul răspunde, ești conectat

Un răspuns la primul mesaj dovedește că punctul final este accesibil și dispus să vorbească. Nu dovedește că un cont a fost acceptat, că un lanț de certificate a fost validat sau că vreo politică de date a fost instalată.

Acele eșecuri apar mai târziu și produc simptome diferite. Respingerea unui certificat sau o eroare EAP sosește după ce primul schimb a reușit deja, de aceea un ping către UDP 500 și o pictogramă verde în client spun atât de puțin.

IKE_SA_INIT: cad de acord asupra parametrilor, nu asupra identității

Primul schimb transportă propunerile pentru asocierea de securitate IKE: algoritmi de criptare și integritate, o funcție pseudoaleatoare și un grup Diffie-Hellman. Perechile schimbă și nonce-uri, iar fiecare parte derivă materialul de cheie pentru IKE SA din secretul comun pe care îl produc acele valori. Nimic din acest schimb nu stabilește cine este cealaltă parte. Stabilește doar că ambele părți pot calcula aceleași chei și că sunt de acord asupra unei propuneri. Un respondent căruia nu-i place nicio propunere respinge schimbul aici, de aceea o nepotrivire de versiune sau de algoritm arată ca un server căzut.

IKE SA creat în acest punct protejează toate schimburile de administrare ulterioare. Aceasta este treaba lui și este o altă treabă decât protejarea pachetelor tale.

IKE_AUTH: dovedește identitatea, apoi construiește primul CHILD SA

Al doilea schimb transportă identitatea. Cu certificate, fiecare parte semnează cu cheia sa privată și prezintă un lanț pe care cealaltă trebuie să îl valideze; cu EAP, respondentul provoacă inițiatorul prin metoda aleasă. Aici apar în sfârșit un nume de server greșit, un certificat expirat sau o parolă respinsă.

În cazul normal IKE_AUTH negociază și primul CHILD SA, așa că protecția datelor se agreează în același drum. Inițiatorul propune selectori de trafic, respondentul îi restrânge sau îi respinge, iar cheile pentru calea de date derivă din IKE SA. Asta înseamnă că un singur schimb poate eșua în două locuri foarte diferite: identitatea sau politica. Citește payload-ul de notificare sau eroarea, nu eșecul generic de handshake, pentru că remediul pentru unul este un certificat, iar pentru celălalt o nepotrivire de subrețea.

Două SA, două treburi

Ținerea lor separate explică două comportamente care par erori. Un tunel poate apărea ca stabilit în timp ce reînnoirea cheilor eșuează în fundal, iar un CHILD SA poate fi înlocuit fără ca clientul să piardă conexiunea.

Pe strongSwan, referința de configurare IKEv2 și swanctl --list-sas arată ambele niveluri, iar ip xfrm state împreună cu ip xfrm policy arată ce a instalat de fapt nucleul. Compararea acestor două vederi este cea mai rapidă cale de a vedea dacă negocierea s-a terminat sau doar a părut terminată. Dacă daemonul listează un CHILD SA pentru care nucleul nu are stare, instalarea a eșuat în tăcere. Dacă nucleul păstrează o stare pe care daemonul nu o cunoaște, te uiți la un rest dintr-o încercare anterioară.

Ce mai trebuie să fie adevărat după ce tunelul e sus

Selectorii de trafic definesc ce adrese sunt acoperite. Dacă clientul propune o subrețea, iar serverul așteaptă alta, CHILD SA se instalează, dar nu transportă nimic util, iar eroarea apare ca o problemă de rutare și nu de negociere. Apoi stiva locală trebuie să colaboreze: forwarding activat acolo unde gazda rutează, rute care indică tunelul, reguli de firewall care permit pachetele decapsulate și un resolver intern dacă sunt implicate nume private. Fiecare dintre acestea eșuează separat și niciunul nu se repară prin repornirea daemonului IKE.

Ține jurnalul vizibil în timp ce diagnostichezi: schimbul inițial, apoi validarea identității, apoi autentificarea utilizatorului unde se aplică, apoi instalarea CHILD și în final traficul aplicației. Etapa care se oprește este etapa de reparat, iar o eroare de rutare ulterioară nu este niciodată motiv să relaxezi verificările de identitate care au trecut deja.