iOS IKEv2 til strongSwan: ingen forslag valde, fiks lista

iPhone tek opp tunnelen, gatewayen svarar med ingenting, og telefonen viser ein generisk feil. Loggen til strongSwan er meir presis: no proposal chosen. Meldinga tyder at dei to listene over akseptable chiffer-sett aldri overlappa, så utvekslinga tok slutt før autentiseringa byrja. Det er eit matchingsproblem, og løysinga er å få listene til å overlappe.

Der gatewayen oppgir policyen sin

strongSwan skriv policyen sin i konfigurasjonen, og utropsteiknet til slutt avgjer korleis policyen blir lesen. Med teiknet er lista uttømmande: berre dei oppføringane og ingenting anna blir godtekne. Utan teiknet er same linja ein preferanserekkjefølgje, og daemonen kan velje noko du ikkje hadde tenkt. Spør kva form som er installert før du omset noko, fordi dei to oppfører seg ulikt mot same klient. Skriv ned den nøyaktige linja, med teiknet, og test mot henne.

Ein klient som tilbyr ei breiare liste kan framleis kople til ein fastlåst gateway, så lenge éin kombinasjon finst på begge sider. Det som ikkje kan skje, er forhandling utanfor det fastlåste settet.

Derfor kan ein profil kopiert frå ein annan VPN-app verke der din ikkje gjer det: den andre appen sende ei anna liste.

Namna må stemme, ikkje bli betre

To omsetjingar lurer folk som flyttar verdiar frå strongSwan til iOS. Integritetsalgoritmen som er skriven SHA1 i eit IKE-forslag, reiser i si avkorta form, som iOS kallar .SHA96. Diffie-Hellman-gruppa som er skriven modp1024, er gruppe 2, som iOS kallar .group2. Å bytte til SHA-256 eller gruppe 14 forhandlar ikkje med ein gateway som berre godtek det eldre paret. Klienten må skildre den same algoritmen, ikkje ein sterkare.

Set desse verdiane eksplisitt i NEVPNProtocolIKEv2. Standardverdiar kan vere breiare eller smalare enn profilen du erstattar, og skilnaden viser seg berre når handtrykket feilar.

Barneproposalen feilar seinare og stillare

Konfigurer også sikkerheitstilknytinga til barnet, ikkje berre IKE-en. Når berre IKE-parametrane stemmer, autentiserer tunnelen seg og fraktar deretter ingen trafikk, som er ein mykje stillare feil enn ei avvising. Set krypteringa, integriteten, gruppa og levetida til barnet i same omgang. Hald levetida til klienten på eller under verdien til gatewayen, sidan det å insistere på ei lengre gir same no proposal chosen-melding av ein annan årsak. Eit avvik der ser identisk ut som eit IKE-avvik i loggen.

Sjekk om profilen autentiserer med sertifikat eller ei delt løyndom medan du er i konfigurasjonen. Ei proposalforkasting og ei autentiseringsforkasting viser seg på ulike linjer, og å fikse den gale kostar ein dag. Test med ei fersk tilkopling etter kvar endring, éin variabel om gongen, fordi bufra tilstand skjuler kva parameter som flytta seg.

Lat den gamle suiten bli berre så lenge han trengst

Å låse SHA-1 med ei 1024-bitars gruppe er ei bru, ikkje eit mål. Begge er avvikla, og nyare klientar kan avvise dei heilt, noko som tyder at profilen vil feile på neste eining utan noka endring frå di side. Handsame låsinga som mellombels og seie det i protokollen.

Viss strongSwan er din, legg til eit moderne forslag og lat begge endar forhandle oppover medan den gamle oppføringa blir for eldre einingar. Les statusutdataa frå daemonen for å sjå kva suite kvar tilkopling faktisk brukte. Fjern deretter låsinga på klientsida når det moderne paret er stadfesta. Ein tunnel som kjem opp er ikkje bevis nok, fordi han kan kome opp på suiten du prøvde å pensjonere. strongSwan-dokumentasjonen for IKEv2 skildrar proposal-syntaksen og strict-markøren.