iOS IKEv2 ir strongSwan: pasiūlymas nepasirinktas, pataisykite sąrašą

iPhone pakelia tunelį, šliuzas neatsako nieko, o telefonas rodo bendrą klaidą. strongSwan žurnalas yra konkretesnis: no proposal chosen. Šis pranešimas reiškia, kad du priimtinų šifravimo rinkinių sąrašai niekada nesusikirto, todėl mainai baigėsi prieš prasidedant autentifikacijai. Tai suderinimo problema, o sprendimas yra kad sąrašai susikirstų.

Kur šliuzas skelbia savo politiką

strongSwan savo politiką rašo konfigūracijoje, o baigiamasis šauktukas nusprendžia, kaip tą politiką skaityti. Su ženklu sąrašas yra išsamus: priimami tik tie įrašai ir nieko daugiau. Be ženklo ta pati eilutė yra pirmenybės tvarka, ir demonas gali pasirinkti tai, ko nenorėjote. Paklauskite, kuri forma įdiegta, prieš ką nors versdami, nes abi elgiasi skirtingai su tuo pačiu klientu. Užrašykite tikslią eilutę su ženklu ir testuokite pagal ją.

Klientas, siūlantis platesnį sąrašą, vis tiek gali prisijungti prie užfiksuoto šliuzo, jei bent viena kombinacija yra abiejose pusėse. Negali įvykti derybos už užfiksuotos aibės ribų.

Štai kodėl profilis, nukopijuotas iš kitos VPN programėlės gali veikti ten, kur jūsiškis neveikia: kita programėlė siuntė kitą sąrašą.

Vardai turi sutapti, o ne pagerėti

Du vertimai suklaidina tuos, kurie perkelia reikšmes iš strongSwan į iOS. IKE pasiūlyme kaip SHA1 parašytas vientisumo algoritmas keliauja sutrumpinta forma, kurią iOS vadina .SHA96. Kaip modp1024 parašyta Diffie-Hellman grupė yra 2 grupė, kurią iOS vadina .group2. Pakeitus į SHA-256 arba 14 grupę, derybos su šliuzu, kuris priima tik senesnę porą, nevyks. Klientas turi aprašyti tą patį algoritmą, o ne stipresnį.

Nustatykite tas reikšmes aiškiai NEVPNProtocolIKEv2. Numatytoji reikšmė gali būti platesnė arba siauresnė už keičiamą profilį, o skirtumas išryškėja tik tada, kai suspaudimas nepavyksta.

Vaikinis pasiūlymas nepavyksta vėliau ir tyliau

Konfigūruokite ir vaikinę saugos asociaciją, ne tik IKE. Kai sutampa tik IKE parametrai, tunelis autentifikuojasi ir tada neperduoda srauto, o tai daug tylesnė klaida nei atmetimas. Nustatykite vaikinio šifravimą, vientisumą, grupę ir galiojimo laiką tame pačiame etape. Laikykite kliento galiojimo laiką lygų šliuzo reikšmei arba mažesnį, nes reikalavimas ilgesnio duoda tą patį no proposal chosen pranešimą dėl kitos priežasties. Ten esantis neatitikimas atrodo taip pat kaip IKE neatitikimas žurnale.

Patikrinkite, ar profilis autentifikuojasi sertifikatais, ar bendru slaptuoju raktu, kol esate konfigūracijoje. Pasiūlymo atmetimas ir autentifikacijos atmetimas pasirodo skirtingose eilutėse, o neteisingo taisymas kainuoja dieną. Testuokite su nauju ryšiu po kiekvieno pakeitimo, po vieną kintamąjį, nes talpykloje esanti būsena paslepia, kuris parametras pasikeitė.

Palikite seną rinkinį tik tol, kol jo reikia

SHA-1 užfiksavimas su 1024 bitų grupe yra tiltas, o ne tikslas. Abi pasenusios, ir naujesni klientai gali jų tiesiog atsisakyti, o tai reiškia, kad profilis žlugs kitame įrenginyje be jokių jūsų pakeitimų. Laikykite fiksavimą laikinu ir taip įrašykite protokole.

Jei strongSwan yra jūsų, pridėkite modernų pasiūlymą ir leiskite abiem galams derėtis aukštyn, kol senas įrašas lieka senesniems įrenginiams. Perskaitykite demono būsenos išvestį, kad pamatytumėte, kurį rinkinį kiekvienas ryšys iš tikrųjų naudojo. Tada pašalinkite fiksavimą kliento pusėje, kai modernioji pora patvirtinta. Pakilęs tunelis nėra pakankamas įrodymas, nes jis gali kilti ant rinkinio, kurio bandėte atsisakyti. strongSwan IKEv2 dokumentacija aprašo pasiūlymų sintaksę ir strict žymeklį.