iOS IKEv2 till strongSwan: inget förslag valt, rätta listan

iPhone tar upp tunneln, gatewayen svarar med ingenting och telefonen visar ett allmänt fel. strongSwans logg är mer specifik: no proposal chosen. Meddelandet betyder att de två listorna med godtagbara chifferuppsättningar aldrig överlappade, så utbytet tog slut innan autentiseringen började. Det är ett matchningsproblem och lösningen är att få listorna att överlappa.

Där gatewayen anger sin policy

strongSwan skriver sin policy i konfigurationen och utropstecknet i slutet avgör hur policyn läses. Med tecknet är listan uttömmande: bara de posterna och inget annat godtas. Utan tecknet är samma rad en preferensordning och daemonen kan välja något du inte avsåg. Fråga vilken form som är installerad innan du översätter något, eftersom de två beter sig olika mot samma klient. Skriv ned den exakta raden, med tecknet, och testa mot den.

En klient som erbjuder en bredare lista kan fortfarande ansluta till en fastnålad gateway, så länge en kombination finns på båda sidor. Det som inte kan hända är förhandling utanför den fastnålade mängden.

Det är därför en profil kopierad från en annan VPN-app kan fungera där din inte gör det: den andra appen skickade en annan lista.

Namnen måste stämma, inte förbättras

Två översättningar lurar dem som flyttar värden från strongSwan till iOS. Integritetsalgoritmen som skrivs SHA1 i ett IKE-förslag färdas i sin avkortade form, som iOS kallar .SHA96. Diffie-Hellman-gruppen som skrivs modp1024 är grupp 2, som iOS kallar .group2. Att byta till SHA-256 eller grupp 14 förhandlar inte med en gateway som bara accepterar det äldre paret. Klienten måste beskriva samma algoritm, inte en starkare.

Ställ in dessa värden uttryckligen i NEVPNProtocolIKEv2. Standardvärden kan vara bredare eller smalare än profilen du ersätter, och skillnaden syns först när handskakningen misslyckas.

Barnförslaget misslyckas senare och tystare

Konfigurera även barnets säkerhetsassociation, inte bara IKE:s. När bara IKE-parametrarna stämmer autentiseras tunneln och transporterar sedan ingen trafik, vilket är ett mycket tystare fel än ett avslag. Ställ in barnets kryptering, integritet, grupp och livslängd i samma steg. Håll klientens livslängd på eller under gatewayens värde, eftersom envishet med en längre ger samma no proposal chosen-meddelande av en annan orsak. En avvikelse där ser identisk ut som en IKE-avvikelse i loggen.

Kontrollera om profilen autentiserar med certifikat eller en delad hemlighet medan du är i konfigurationen. En förslagsavvisning och en autentiseringsavvisning visas på olika rader, och att rätta den felaktiga kostar en dag. Testa med en ny anslutning efter varje ändring, en variabel i taget, eftersom cachelagrat tillstånd döljer vilken parameter som flyttade.

Lämna den gamla sviten bara så länge den behövs

Att nåla fast SHA-1 med en 1024-bitars grupp är en bro, inte en destination. Båda är avskrivna och nyare klienter kan avvisa dem helt, vilket innebär att profilen misslyckas på nästa enhet utan någon ändring från din sida. Behandla nålen som tillfällig och säg det i protokollet.

Om strongSwan är din, lägg till ett modernt förslag och låt båda ändar förhandla uppåt medan den gamla posten finns kvar för äldre enheter. Läs daemonens statusutdata för att se vilken svit varje anslutning faktiskt använde. Ta sedan bort nålen på klientsidan när det moderna paret är bekräftat. En tunnel som kommer upp är inte tillräckligt bevis, eftersom den kan komma upp på sviten du försökte pensionera. strongSwans IKEv2-dokumentation beskriver förslagssyntaxen och strict-markören.