iOS IKEv2 és strongSwan: nincs kiválasztott ajánlat – javítsd a listát

Az iPhone felépíti az alagutat, az átjáró semmivel sem válaszol, a telefon pedig általános hibát jelez. A strongSwan naplója konkrétabb: no proposal chosen. Ez az üzenet azt jelenti, hogy az elfogadható titkosítási csomagok két listája soha nem fedte egymást, így a csere már a hitelesítés előtt véget ért. Ez illesztési probléma, a megoldás pedig az, hogy a listák metszék egymást.

Hol hirdeti meg az átjáró a szabályzatát

A strongSwan a konfigurációban írja le a szabályzatát, és a záró felkiáltójel dönti el, hogyan kell azt olvasni. A jellel a lista kimerítő: kizárólag ezeket a bejegyzéseket fogadja el, semmi mást nem. Jel nélkül ugyanaz a sor preferenciasorrend, és a démon olyasmit is választhat, amit nem szándékoztál. Kérdezd meg, melyik forma van telepítve, mielőtt bármit is lefordítasz, mert a kettő másképp viselkedik ugyanazzal az ügyféllel szemben. Jegyezd fel a pontos sort, a jelet is beleértve, és ahhoz mérten tesztelj.

Egy szélesebb listát kínáló ügyfél is csatlakozhat egy rögzített átjáróhoz, amennyiben legalább egy kombináció mindkét oldalon szerepel. Az nem történhet meg, hogy a tárgyalás a rögzített halmazon kívülre kerüljön.

Ezért működhet az egy másik VPN-alkalmazásból átvett profil, ahol a tiéd nem: a másik alkalmazás más listát szállított.

A neveknek egyezniük kell, nem javulniuk

Két fordítás okoz fejfájást, amikor valaki értékeket visz át a strongSwanból az iOS-be. Az IKE-ajánlatban SHA1-ként írt integritásalgoritmus csonkolt formájában utazik, amit az iOS .SHA96 néven nevez. A modp1024-ként írt Diffie–Hellman-csoport a 2-es csoport, amit az iOS .group2 néven nevez. A SHA-256 vagy a 14-es csoport behelyettesítése nem fog tárgyalni egy olyan átjáróval, amely csak a régebbi párt fogadja el. Az ügyfélnek ugyanazt az algoritmust kell leírnia, nem egy erősebbet.

Ezeket az értékeket kifejezetten a NEVPNProtocolIKEv2 elemben állítsd be. Az alapértelmezések szélesebbek vagy szűkebbek lehetnek a lecserélt profilnál, és a különbség csak akkor derül ki, amikor a kézfogás meghiúsul.

A gyermekajánlat később és halkabban hibázik

A gyermek-biztonsági társítást is konfiguráld, nem csak az IKE-t. Ha csak az IKE-paraméterek illeszkednek, az alagút hitelesít, majd forgalmat nem visz, ami sokkal halkabb hiba az elutasításnál. A gyermek titkosítását, integritását, csoportját és élettartamát ugyanabban a menetben állítsd be. Az ügyfél élettartamát tartsd az átjáró értékén vagy az alatt, mert a hosszabb ragaszkodás ugyanazt a no proposal chosen üzenetet adja, más okból. Az ottani eltérés pontosan úgy néz ki, mint egy IKE-eltérés a naplóban.

A konfigurációban azt is ellenőrizd, hogy a profil tanúsítványokkal vagy megosztott titokkal hitelesít-e. Az ajánlat elutasítása és a hitelesítés elutasítása külön sorokon jelenik meg, és ha a rosszat javítod, az egy napodba kerül. Minden módosítás után friss kapcsolattal tesztelj, egyszerre egy változóval, mert a gyorsítótárazott állapot elrejti, melyik paraméter mozdult el.

A régi csomagot csak addig hagyd meg, amíg szükség van rá

A SHA-1 rögzítése 1024 bites csoporttal híd, nem célállomás. Mindkettő elavult, és az újabb ügyfelek simán elutasíthatják őket, ami azt jelenti, hogy a profil a következő eszközön el fog hasalni, anélkül hogy bármit változtatnál. Kezeld a rögzítést ideiglenesként, és írd is le a feljegyzésben.

Ha a strongSwan a tiéd, adj hozzá egy modern ajánlatot, és hagyd, hogy mindkét vég felfelé tárgyaljon, miközben a régi bejegyzés a régebbi eszközöknek marad. Olvasd ki a démon állapotkimenetét, hogy lásd, melyik csomagot használta valójában az egyes kapcsolat. Utána távolítsd el az ügyféloldali rögzítést, amint a modern pár megerősítést nyert. Az, hogy egy alagút feljön, nem elég bizonyíték, mert éppen azon a csomagon is feljöhet, amelyet ki akartál vonni. A strongSwan IKEv2 dokumentáció ismerteti az ajánlat szintaxisát és a strict jelölőt.