iOS IKEv2 către strongSwan: nicio propunere aleasă, repară lista

iPhone-ul ridică tunelul, gateway-ul nu răspunde cu nimic, iar telefonul afișează o eroare generică. Jurnalul strongSwan este mai precis: no proposal chosen. Acest mesaj înseamnă că cele două liste de suite de cifrare acceptabile nu s-au suprapus niciodată, așa că schimbul s-a încheiat înainte de a începe autentificarea. Este o problemă de potrivire, iar soluția este să faci listele să se intersecteze.

Unde gateway-ul își declară politica

strongSwan își scrie politica în configurație, iar semnul de exclamare de la final decide cum este citită acea politică. Cu semnul, lista este exhaustivă: sunt acceptate doar acele intrări și nimic altceva. Fără semn, aceeași linie este o ordine de preferință, iar demonul poate alege ceva ce nu ai intenționat. Întreabă ce formă este implementată înainte de a traduce orice, pentru că cele două se comportă diferit față de același client. Notează linia exactă, cu semnul inclus, și testează față de ea.

Un client care oferă o listă mai largă se poate conecta totuși la un gateway fixat, atâta timp cât o combinație apare pe ambele părți. Ce nu se poate întâmpla este o negociere în afara mulțimii fixate.

De aceea un profil copiat din altă aplicație VPN poate funcționa acolo unde al tău nu funcționează: cealaltă aplicație trimitea o listă diferită.

Numele trebuie să se potrivească, nu să se îmbunătățească

Două traduceri îi păcălesc pe cei care mută valori din strongSwan în iOS. Algoritmul de integritate scris SHA1 într-o propunere IKE călătorește în forma sa trunchiată, pe care iOS o numește .SHA96. Grupul Diffie-Hellman scris modp1024 este grupul 2, pe care iOS îl numește .group2. Înlocuirea cu SHA-256 sau cu grupul 14 nu va negocia cu un gateway care acceptă doar perechea mai veche. Clientul trebuie să descrie același algoritm, nu unul mai puternic.

Setează acele valori explicit în NEVPNProtocolIKEv2. Valorile implicite pot fi mai largi sau mai înguste decât profilul pe care îl înlocuiești, iar diferența apare doar când handshake-ul eșuează.

Propunerea copil eșuează mai târziu și mai silențios

Configurează și asociația de securitate copil, nu doar pe cea IKE. Când doar parametrii IKE se potrivesc, tunelul se autentifică și apoi nu transportă trafic, ceea ce este o eroare mult mai silențioasă decât un refuz. Setează criptarea, integritatea, grupul și durata de viață ale copilului în aceeași etapă. Ține durata de viață a clientului egală sau sub valoarea gateway-ului, fiindcă insistența pe una mai lungă produce același mesaj no proposal chosen dintr-o altă cauză. O nepotrivire acolo arată identic cu o nepotrivire IKE în jurnal.

Verifică dacă profilul se autentifică prin certificate sau printr-un secret partajat cât timp ești în configurație. Respingerea unei propuneri și respingerea autentificării apar pe linii diferite, iar repararea celei greșite costă o zi. Testează cu o conexiune nouă după fiecare modificare, o variabilă o dată, pentru că starea din cache ascunde ce parametru s-a mișcat.

Lasă suita veche doar atât timp cât este necesară

Fixarea SHA-1 cu un grup de 1024 de biți este un pod, nu o destinație. Ambele sunt depreciate, iar clienții mai noi le pot refuza direct, ceea ce înseamnă că profilul va eșua pe următorul dispozitiv fără nicio modificare din partea ta. Tratează fixarea ca temporară și spune asta în însemnare.

Dacă strongSwan este al tău, adaugă o propunere modernă și lasă ambele capete să negocieze în sus în timp ce intrarea veche rămâne pentru dispozitivele mai vechi. Citește ieșirea de stare a demonului ca să vezi ce suită a folosit efectiv fiecare conexiune. Apoi elimină fixarea din partea clientului după ce perechea modernă este confirmată. Un tunel care se ridică nu este dovadă suficientă, fiindcă se poate ridica pe suita pe care încercai să o retragi. Documentația strongSwan pentru IKEv2 descrie sintaxa propunerilor și marcajul strict.