iOS IKEv2 na strongSwan: geen voorstel gekies, herstel die lys

Die iPhone bring die tonnel op, die gateway antwoord met niks, en die foon bied 'n generiese fout. strongSwan se log is meer spesifiek: geen voorstel gekies. Daardie boodskap beteken die twee lyste van aanvaarbare syfersuites het nooit oorvleuel nie, so die uitruiling het geëindig voordat verifikasie begin het. Dit is 'n passingprobleem, en die regstelling is om die lyste te laat sny.

Waar die gateway sy beleid stel

strongSwan skryf sy beleid in die konfigurasie, en die uitroepmerk aan die einde bepaal hoe daardie beleid gelees word. Met die merk is die lys volledig: daardie inskrywings en niks anders sal aanvaar word nie. Sonder dit is dieselfde reël 'n voorkeurorde, en die daemon kan iets kies wat jy nie bedoel het nie. Vra watter vorm ontplooi is voordat jy enigiets vertaal, want die twee tree anders op teen dieselfde kliënt. Teken die presiese reël op, merk ingesluit, en toets daarteen.

'n Kliint wat 'n wyer lys bied, kan steeds aan 'n vasgepen gateway koppel, solank een kombinasie aan beide kante voorkom. Wat nie kan gebeur nie, is onderhandeling buite die vasgepen stel.

Dit is waarom 'n profiel wat van 'n ander VPN-program gekopieer is kan werk waar joune nie werk nie: die ander program het 'n ander lys verskeep.

Die name moet pas, nie verbeter nie

Twee vertalings vang mense wat waardes van strongSwan na iOS skuif. Die integriteitsalgoritme wat in 'n IKE-voorstel as SHA1 geskryf word, reis in sy afgekorte vorm, wat iOS .SHA96 noem. Die Diffie-Hellman-groep wat as modp1024 geskryf word, is groep 2, wat iOS .group2 noem. Om SHA-256 of groep 14 te vervang, sal nie met 'n gateway onderhandel wat net die ouer paar aanvaar nie. Die kliënt moet dieselfde algoritme beskryf, nie 'n sterker een nie.

Stel daardie waardes eksplisiet in NEVPNProtocolIKEv2. Verstekke kan wyer of smaller as die profiel wees wat jy vervang, en die verskil wys eers wanneer die handdruk misluk.

Die kindvoorstel misluk later en stiller

Stel die kind-sekuriteitsvereniging sowel as die IKE-een op. Wanneer net die IKE-parameters ooreenstem, verifieer die tonnel en dra dan geen verkeer nie, wat 'n baie stiller mislukking is as 'n weiering. Stel die kind se enkripsie, integriteit, groep en leeftyd in dieselfde pas in. Hou die kliënt se leeftyd op of onder die gateway-waarde, want om op 'n langer een aan te dring lewer dieselfde geen-voorstel-gekies-boodskap uit 'n ander oorsaak. 'n Wanpassing daar lyk identies aan 'n IKE-wanpassing in die log.

Kyk of die profiel met sertifikate of 'n gedeelde geheim verifieer terwyl jy in die konfigurasie is. 'n Voorstelverwerping en 'n verifikasieverwerping verskyn op verskillende reëls, en om die verkeerde een reg te maak kos 'n dag. Toets met 'n vars verbinding na elke verandering, een veranderlike op 'n slag, want gekaste toestand verberg watter parameter beweeg het.

Laat die legacy-suite net staan solank dit nodig is

Om SHA-1 met 'n 1024-bis-groep vas te pen, is 'n brug, nie 'n bestemming nie. Albei is verouderd, en nuwer kliënte kan dit heeltemal weier, wat beteken die profiel sal op die volgende toestel misluk sonder enige verandering aan jou kant. Behandel die pen as tydelik en sê so in die rekord.

As strongSwan joune is, voeg 'n moderne voorstel by en laat beide kante opwaarts onderhandel terwyl die legacy-inskrywing vir ouer toestelle bly. Lees die daemon se statusuitvoer om te sien watter suite elke verbinding werklik gebruik het. Verwyder dan die kliëntkant-se-pen sodra die moderne paar bevestig is. 'n Tonnel wat opkom is nie genoeg bewyse nie, want dit kan opkom op die suite wat jy probeer aftree. Die strongSwan IKEv2-dokumentasie beskryf die voorstelsintaksis en die streng merker.