iOS IKEv2 te strongSwan: asnjë propozim i zgjedhur, rregullo listën

iPhone ngre tunelin, portali nuk përgjigjet me asgjë dhe telefoni shfaq një dështim të përgjithshëm. Regjistri i strongSwan është më i saktë: no proposal chosen. Ky mesazh do të thotë që dy listat e grupeve të pranueshme të kriptimit nuk u mbivendosën kurrë, prandaj shkëmbimi përfundoi para se të fillonte vërtetimi. Është problem përputhjeje dhe zgjidhja është t'i bësh listat të kryqëzohen.

Ku portali shpall politikën e tij

strongSwan e shkruan politikën e tij në konfigurim dhe pikëçuditësja në fund vendos si lexohet ajo politikë. Me shenjën lista është shteruese: pranohen vetëm ato zëra dhe asgjë tjetër. Pa shenjën e njëjta rresht është një rend preferencash dhe demoni mund të zgjedhë diçka që nuk e ke synuar. Pyet cila formë është vendosur përpara se të përkthesh çdo gjë, sepse të dyja sillen ndryshe me të njëjtin klient. Regjistro rreshtin e saktë, shenjën përfshirë, dhe testo kundrejt tij.

Një klient që ofron një listë më të gjerë mund të lidhet ende me një portal të fiksuar, për sa kohë një kombinim shfaqet në të dyja anët. Ajo që nuk mund të ndodhë është një negociim jashtë grupit të fiksuar.

Kjo është arsyeja pse një profil i kopjuar nga një aplikacion tjetër VPN mund të funksionojë atje ku i yti nuk funksionon: ai aplikacion dërgonte një listë tjetër.

Emrat duhet të përputhen, jo të përmirësohen

Dy përkthime i hutojnë ata që kalojnë vlera nga strongSwan në iOS. Algoritmi i integritetit i shkruar SHA1 në një propozim IKE udhëton në formën e tij të shkurtuar, të cilën iOS e quan .SHA96. Grupi Diffie-Hellman i shkruar modp1024 është grupi 2, të cilin iOS e quan .group2. Zëvendësimi me SHA-256 ose me grupin 14 nuk do të negociojë me një portal që pranon vetëm çiftin më të vjetër. Klienti duhet të përshkruajë të njëjtin algoritëm, jo një më të fortë.

Vendosi ato vlera në mënyrë eksplicite në NEVPNProtocolIKEv2. Vlerat e parazgjedhura mund të jenë më të gjera ose më të ngushta se profili që po zëvendëson, dhe ndryshimi shfaqet vetëm kur shtrëngimi i duarve dështon.

Propozimi fëmijë dështon më vonë dhe më i qetë

Konfiguro edhe shoqatën e sigurisë së fëmijës, jo vetëm atë të IKE. Kur përputhen vetëm parametrat e IKE, tuneli vërtetohet dhe pastaj nuk mbart trafik, që është një dështim shumë më i qetë sesa një refuzim. Vendos kriptimin, integritetin, grupin dhe kohëzgjatjen e fëmijës në të njëjtin hap. Mbaje kohëzgjatjen e klientit në ose nën vlerën e portalit, sepse këmbëngulja për një më të gjatë jep të njëjtin mesazh no proposal chosen nga një shkak tjetër. Një mospërputhje atje duket identike me një mospërputhje IKE në regjistër.

Kontrollo nëse profili vërtetohet me certifikata ose me një sekret të përbashkët ndërsa je në konfigurim. Refuzimi i propozimit dhe refuzimi i vërtetimit shfaqen në rreshta të ndryshëm, dhe rregullimi i të gabuarit kushton një ditë. Testo me një lidhje të re pas çdo ndryshimi, një variabël në herë, sepse gjendja e ruajtur në memorje fsheh cili parametër lëvizi.

Lëre grupin e vjetër vetëm sa kohë që është i nevojshëm

Fiksimi i SHA-1 me një grup 1024-bitësh është urë, jo destinacion. Të dyja janë të vjetruara dhe klientët më të rinj mund t'i refuzojnë plotësisht, që do të thotë se profili do të dështojë në pajisjen tjetër pa asnjë ndryshim nga ana jote. Trajto fiksimin si të përkohshëm dhe shkruaje këtë në procesverbal.

Nëse strongSwan është i yti, shto një propozim modern dhe lëri të dy skajet të negociojnë lart ndërsa zëri i vjetër mbetet për pajisjet e vjetra. Lexo daljen e gjendjes së demonit për të parë cilin grup përdori vërtet çdo lidhje. Pastaj hiq fiksimin në anën e klientit pasi çifti modern të konfirmohet. Një tunel që ngrihet nuk është provë e mjaftueshme, sepse mund të ngrihet në grupin që po përpiqeshe të tërhiqje. Dokumentacioni i strongSwan për IKEv2 përshkruan sintaksën e propozimeve dhe shenjën strict.