iOS IKEv2 til strongSwan: ingen forslag valgt, fiks listen

iPhone tar opp tunnelen, gatewayen svarer med ingenting, og telefonen viser en generisk feil. Loggen til strongSwan er mer presis: no proposal chosen. Meldingen betyr at de to listene over akseptable chiffer-sett aldri overlappet, så utvekslingen tok slutt før autentiseringen begynte. Det er et matchingsproblem, og løsningen er å få listene til å overlappe.

Der gatewayen oppgir policyen sin

strongSwan skriver policyen sin i konfigurasjonen, og utropstegnet til slutt avgjør hvordan policyen leses. Med tegnet er listen uttømmende: bare de oppføringene og ingenting annet godtas. Uten tegnet er samme linje en preferanserekkefølge, og daemonen kan velge noe du ikke hadde tenkt. Spør hvilken form som er installert før du oversetter noe, fordi de to oppfører seg ulikt mot samme klient. Skriv ned den nøyaktige linjen, med tegnet, og test mot den.

En klient som tilbyr en bredere liste kan fortsatt koble til en fastlåst gateway, så lenge én kombinasjon finnes på begge sider. Det som ikke kan skje, er forhandling utenfor det fastlåste settet.

Derfor kan en profil kopiert fra en annen VPN-app virke der din ikke gjør det: den andre appen sendte en annen liste.

Navnene må stemme, ikke forbedres

To oversettelser lurer folk som flytter verdier fra strongSwan til iOS. Integritetsalgoritmen som er skrevet SHA1 i et IKE-forslag, reiser i sin avkortede form, som iOS kaller .SHA96. Diffie-Hellman-gruppen som er skrevet modp1024, er gruppe 2, som iOS kaller .group2. Å bytte til SHA-256 eller gruppe 14 forhandler ikke med en gateway som bare godtar det eldre paret. Klienten må beskrive den samme algoritmen, ikke en sterkere.

Sett disse verdiene eksplisitt i NEVPNProtocolIKEv2. Standardverdier kan være bredere eller smalere enn profilen du erstatter, og forskjellen vises bare når håndtrykket feiler.

Barneproposalen feiler senere og stillere

Konfigurer også barnets sikkerhetstilknytning, ikke bare IKE-en. Når bare IKE-parameterne stemmer, autentiseres tunnelen og frakter deretter ingen trafikk, som er en mye stillere feil enn en avvisning. Sett barnets kryptering, integritet, gruppe og levetid i samme omgang. Hold klientens levetid på eller under gatewayens verdi, siden det å insistere på en lengre gir samme no proposal chosen-melding av en annen årsak. Et avvik der ser identisk ut som et IKE-avvik i loggen.

Sjekk om profilen autentiserer med sertifikater eller en delt hemmelighet mens du er i konfigurasjonen. En proposalforkastelse og en autentiseringsforkastelse vises på forskjellige linjer, og å fikse den gale koster en dag. Test med en fersk tilkobling etter hver endring, én variabel om gangen, fordi bufret tilstand skjuler hvilken parameter som flyttet seg.

La den gamle suiten bli bare så lenge den trengs

Å låse SHA-1 med en 1024-biters gruppe er en bro, ikke et mål. Begge er avviklet, og nyere klienter kan avvise dem helt, noe som betyr at profilen vil feile på neste enhet uten noen endring fra din side. Behandle låsingen som midlertidig og si det i protokollen.

Hvis strongSwan er din, legg til et moderne forslag og la begge ender forhandle oppover mens den gamle oppføringen blir for eldre enheter. Les statusutdataene fra daemonen for å se hvilken suite hver tilkobling faktisk brukte. Fjern deretter låsingen på klientsiden når det moderne paret er bekreftet. En tunnel som kommer opp er ikke bevis nok, fordi den kan komme opp på suiten du prøvde å pensjonere. strongSwan-dokumentasjonen for IKEv2 beskriver proposal-syntaksen og strict-markøren.