iOS IKEv2 v strongSwan: noben predlog ni izbran, popravite seznam
„Noben predlog ni izbran“ pomeni, da se dva seznama nikoli ne sekata. Prevedite SHA1 v SHA-96, modp1024 v group 2 in nastavite tudi podrejeni predlog.
iPhone dvigne tunel, prehod ne odgovori z ničimer, telefon pa pokaže splošno napako. Dnevnik strongSwana je natančnejši: no proposal chosen. To sporočilo pomeni, da se dva seznama sprejemljivih šifrirnih naborov nikoli nista prekrila, zato se je izmenjava končala, preden se je začela avtentikacija. To je težava ujemanja, rešitev pa je, da se seznama sekata.
Kje prehod razglasi svojo politiko
strongSwan zapiše svojo politiko v konfiguracijo, klicaj na koncu pa odloči, kako se ta politika bere. Z znakom je seznam izčrpen: sprejmejo se samo ti vnosi in nič drugega. Brez znaka je ista vrstica vrstni red prednosti in daemon lahko izbere nekaj, česar niste nameravali. Vprašajte, katera oblika je nameščena, preden karkoli prevedete, ker se obe obnašata drugače do istega odjemalca. Zapišite natančno vrstico z znakom in preizkusite proti njej.
Odjemalec s širšim seznamom se lahko še vedno poveže s pripetim prehodom, če se ena kombinacija pojavi na obeh straneh. Kar se ne more zgoditi, je pogajanje zunaj pripetega nabora.
Zato lahko profil, kopiran iz druge aplikacije VPN deluje tam, kjer vaš ne: druga aplikacija je pošiljala drug seznam.
Imena se morajo ujemati, ne izboljšati
Dva prevoda zavedeta ljudi, ki prenašajo vrednosti iz strongSwana v iOS. Algoritem celovitosti, zapisan kot SHA1 v predlogu IKE, potuje v skrajšani obliki, ki jo iOS imenuje .SHA96. Skupina Diffie-Hellman, zapisana kot modp1024, je skupina 2, ki jo iOS imenuje .group2. Zamenjava s SHA-256 ali skupino 14 se ne bo pogajala s prehodom, ki sprejema samo starejši par. Odjemalec mora opisati isti algoritem, ne močnejšega.
Te vrednosti nastavite izrecno v NEVPNProtocolIKEv2. Privzete vrednosti so lahko širše ali ožje od profila, ki ga zamenjujete, razlika pa se pokaže šele, ko rokovanje spodleti.
Podrejeni predlog spodleti pozneje in tišje
Konfigurirajte tudi podrejeno varnostno povezavo, ne le tiste za IKE. Ko se ujemajo samo parametri IKE, se tunel avtenticira in nato ne prenaša prometa, kar je veliko tišja okvara kot zavrnitev. Nastavite šifriranje, celovitost, skupino in življenjsko dobo podrejene v istem koraku. Držite življenjsko dobo odjemalca na vrednosti prehoda ali pod njo, ker vztrajanje pri daljši dá isto sporočilo no proposal chosen iz drugega vzroka. Neujemanje tam je videti enako kot neujemanje IKE v dnevniku.
Preverite, ali se profil avtenticira s potrdili ali s skupno skrivnostjo, medtem ko ste v konfiguraciji. Zavrnitev predloga in zavrnitev avtentikacije se pojavita v različnih vrsticah, popravljanje napačne pa stane en dan. Preizkusite z novo povezavo po vsaki spremembi, eno spremenljivko naenkrat, ker predpomnilnik skrije, kateri parameter se je premaknil.
Stari nabor pustite le toliko časa, dokler je potreben
Pripeti SHA-1 s 1024-bitno skupino je most, ne cilj. Oba sta zastarela in novejši odjemalci jih lahko povsem zavrnejo, kar pomeni, da bo profil spodletel na naslednji napravi brez kakršne koli spremembe na vaši strani. Pripetje obravnavajte kot začasno in to zapišite v zapis.
Če je strongSwan vaš, dodajte sodoben predlog in pustite obema koncema, da se pogajata navzgor, medtem ko stari vnos ostane za starejše naprave. Preberite izhod stanja daemona, da vidite, kateri nabor je vsaka povezava dejansko uporabila. Nato odstranite pripetje na strani odjemalca, ko je sodobni par potrjen. Dvignjen tunel ni dovolj dokazov, ker se lahko dvigne na naboru, ki ste ga poskušali upokojiti. Dokumentacija strongSwana za IKEv2 opisuje sintakso predlogov in oznako strict.