iOS IKEv2 til strongSwan: intet forslag valgt, ret listen

iPhone rejser tunnelen, gatewayen svarer med intet, og telefonen viser en generisk fejl. strongSwans log er mere konkret: intet forslag valgt. Denne meddelelse betyder, at de to lister over acceptable cipher suites aldrig overlappede, så udvekslingen sluttede, før godkendelsen begyndte. Det er et matchningsproblem, og løsningen er at få listerne til at overlappe.

Hvor gatewayen erklærer sin politik

strongSwan skriver sin politik i konfigurationen, og udråbstegnet til sidst afgør, hvordan politikken læses. Med mærket er listen udtømmende: de poster og intet andet accepteres. Uden det er samme linje en præferenceorden, og daemonen kan vælge noget, du ikke havde tænkt dig. Spørg, hvilken form der er udrullet, før du oversætter noget, for de to opfører sig forskelligt over for samme klient. Notér den nøjagtige linje, mærket inkluderet, og test imod den.

En klient, der tilbyder en bredere liste, kan stadig forbinde til en fastlåst gateway, så længe én kombination findes på begge sider. Det, der ikke kan ske, er forhandling uden for det fastlåste sæt.

Derfor kan en profil kopieret fra en anden VPN-app virke, hvor din ikke gør: den anden app leverede en anden liste.

Navnene skal passe, ikke forbedres

To oversættelser fanger folk, der flytter værdier fra strongSwan til iOS. Integritetsalgoritmen, der skrives SHA1 i et IKE-forslag, rejser i sin afkortede form, som iOS kalder .SHA96. Diffie-Hellman-gruppen, der skrives modp1024, er group 2, som iOS kalder .group2. At erstatte med SHA-256 eller group 14 forhandler ikke mod en gateway, der kun accepterer det ældre par. Klienten skal beskrive den samme algoritme, ikke en stærkere.

Sæt disse værdier eksplicit i NEVPNProtocolIKEv2. Standardværdier kan være bredere eller smallere end den profil, du erstatter, og forskellen viser sig først, når håndtrykket fejler.

Barnets forslag fejler senere og mere stille

Konfigurer barnets sikkerhedsassociation såvel som IKE'ens. Når kun IKE-parametrene passer, godkendes tunnelen og bærer derefter ingen trafik, hvilket er en meget mere stille fejl end en afvisning. Sæt barnets kryptering, integritet, gruppe og levetid i samme gennemløb. Hold klientens levetid på gatewayens værdi eller derunder, fordi insisteren på en længere giver samme meddelelse om intet valgt forslag af en anden årsag. Uoverensstemmelse der ser identisk ud med en IKE-uoverensstemmelse i loggen.

Kontroller, om profilen godkender med certifikater eller en delt hemmelighed, mens du er i konfigurationen. En forslagsafvisning og en godkendelsesafvisning vises på forskellige linjer, og at rette den forkerte koster en dag. Test med en frisk forbindelse efter hver ændring, én variabel ad gangen, fordi cachet tilstand skjuler, hvilken parameter der flyttede sig.

Lad det gamle sæt blive kun så længe, det er nødvendigt

At fastlåse SHA-1 med en 1024-bit gruppe er en bro, ikke en destination. Begge er forældede, og nyere klienter kan afvise dem helt, hvilket betyder, at profilen fejler på den næste enhed uden ændring på din side. Behandl fastlåsningen som midlertidig, og sig det i posten.

Hvis strongSwan er din, tilføj et moderne forslag, og lad begge ender forhandle opad, mens den gamle post bliver for ældre enheder. Læs daemonens statusoutput for at se, hvilket sæt hver forbindelse faktisk brugte. Fjern derefter fastlåsningen på klientsiden, når det moderne par er bekræftet. En tunnel, der kommer op, er ikke bevis nok, fordi den kan komme op på det sæt, du forsøgte at udfase. strongSwans IKEv2-dokumentation beskriver forslagssyntaksen og det strenge mærke.