iOS IKEv2 na strongSwan: žádná nabídka vybrána, opravte seznam

iPhone vynese tunel, brána neodpoví ničím a telefon zobrazí obecnou chybu. Protokol strongSwan je konkrétnější: žádná nabídka vybrána. Tato zpráva znamená, že se oba seznamy přijatelných šifrových sad nikdy nepřekryly, takže výměna skončila dřív, než začalo ověřování. Je to problém shody a řešením je přimět seznamy, aby se protnuly.

Kde brána vyhlašuje svou politiku

strongSwan zapisuje svou politiku do konfigurace a vykřičník na konci rozhoduje o tom, jak se tato politika čte. S vykřičníkem je seznam vyčerpávající: přijmou se tyto položky a nic jiného. Bez něj je stejný řádek pořadím preferencí a démon může vybrat něco, co jste nezamýšleli. Než cokoli přeložíte, zeptejte se, která forma je nasazená, protože obě se vůči stejnému klientovi chovají jinak. Zapište přesný řádek včetně vykřičníku a testujte proti němu.

Klient nabízející širší seznam se stále může připojit k připnuté bráně, pokud se jedna kombinace objeví na obou stranách. Co nastat nemůže, je vyjednávání mimo připnutou množinu.

Proto profil zkopírovaný z jiné VPN aplikace může fungovat tam, kde váš ne: jiná aplikace dodala jiný seznam.

Názvy musí odpovídat, ne zlepšovat

Dva překlady chytají lidi, kteří přenášejí hodnoty ze strongSwanu do iOS. Algoritmus integrity zapsaný v IKE nabídce jako SHA1 cestuje ve zkrácené podobě, kterou iOS nazývá .SHA96. Skupina Diffie-Hellmana zapsaná jako modp1024 je group 2, kterou iOS nazývá .group2. Nahrazení SHA-256 nebo group 14 nevyjedná nic proti bráně, která přijímá jen starší dvojici. Klient musí popsat stejný algoritmus, ne silnější.

Nastavte tyto hodnoty výslovně v NEVPNProtocolIKEv2. Výchozí hodnoty mohou být širší nebo užší než profil, který nahrazujete, a rozdíl se ukáže, až když handshake selže.

Nabídka pro potomka selhává později a tišeji

Nakonfigurujte bezpečnostní asociaci potomka stejně jako tu pro IKE. Když se shodnou jen parametry IKE, tunel se ověří a potom nenese žádný provoz, což je mnohem tišší selhání než odmítnutí. Nastavte šifrování, integritu, skupinu a životnost potomka ve stejném kroku. Držte životnost klienta na hodnotě brány nebo níž, protože trvání na delší dává stejnou zprávu o nevybrané nabídce z jiné příčiny. Nesoulad tam vypadá stejně jako nesoulad IKE v protokolu.

Zkontrolujte, zda se profil ověřuje certifikáty, nebo sdíleným tajemstvím, dokud jste v konfiguraci. Odmítnutí nabídky a odmítnutí ověření se objevují na různých řádcích a oprava toho špatného stojí den. Testujte novým připojením po každé změně, vždy jednu proměnnou, protože uložený stav skrývá, který parametr se pohnul.

Nechte starou sadu jen dokud je potřeba

Připnutí SHA-1 se 1024bitovou skupinou je most, ne cíl. Obojí je zastaralé a novější klienti je mohou rovnou odmítnout, což znamená, že profil selže na dalším zařízení bez jakékoli změny na vaší straně. Berte připnutí jako dočasné a řekněte to v záznamu.

Pokud je strongSwan váš, přidejte moderní nabídku a nechte obě strany vyjednávat nahoru, zatímco stará položka zůstává pro starší zařízení. Přečtěte si stavový výstup démona, abyste viděli, kterou sadu každé připojení skutečně použilo. Potom odstraňte připnutí na straně klienta, jakmile je moderní dvojice potvrzena. Tunel, který se vynese, není dostatečný důkaz, protože se může vynést na sadě, kterou jste se snažili vyřadit. Dokumentace strongSwan k IKEv2 popisuje syntaxi nabídek a striktní značku.