iOS IKEv2 naar strongSwan: geen voorstel gekozen, herstel de lijst

De iPhone brengt de tunnel op, de gateway antwoordt met niets, en de telefoon toont een algemene fout. Het log van strongSwan is specifieker: no proposal chosen. Die melding betekent dat de twee lijsten met aanvaardbare ciphersuites elkaar nooit overlapten, dus de uitwisseling eindigde voordat de authenticatie begon. Het is een afstemmingsprobleem, en de oplossing is de lijsten te laten overlappen.

Waar de gateway zijn beleid vastlegt

strongSwan schrijft zijn beleid in de configuratie, en het uitroepteken aan het eind bepaalt hoe dat beleid wordt gelezen. Met het teken is de lijst uitputtend: alleen die vermeldingen en niets anders worden geaccepteerd. Zonder het teken is dezelfde regel een voorkeursvolgorde, en dan kan de daemon iets kiezen dat je niet bedoelde. Vraag welke vorm is uitgerold voordat je iets vertaalt, want de twee gedragen zich anders tegenover dezelfde client. Noteer de exacte regel, teken inbegrepen, en test daartegen.

Een client met een bredere lijst kan nog steeds verbinden met een vastgezette gateway, zolang één combinatie aan beide kanten voorkomt. Wat niet kan, is onderhandelen buiten de vastgezette set.

Daarom kan een profiel dat uit een andere VPN-app is gekopieerd werken waar het jouwe dat niet doet: de andere app stuurde een andere lijst.

De namen moeten kloppen, niet verbeteren

Twee vertalingen laten mensen struikelen die waarden van strongSwan naar iOS overhevelen. Het integriteitsalgoritme dat in een IKE-voorstel SHA1 heet, reist in zijn afgekorte vorm, die iOS .SHA96 noemt. De Diffie-Hellman-groep die modp1024 heet, is groep 2, die iOS .group2 noemt. Vervangen door SHA-256 of groep 14 onderhandelt niet met een gateway die alleen het oudere paar accepteert. De client moet hetzelfde algoritme beschrijven, niet een sterker.

Stel die waarden expliciet in NEVPNProtocolIKEv2 in. Standaardwaarden kunnen breder of smaller zijn dan het profiel dat je vervangt, en het verschil komt pas aan het licht als de handshake mislukt.

Het kindvoorstel faalt later en stiller

Configureer ook de beveiligingsassociatie van het kind, niet alleen die van IKE. Als alleen de IKE-parameters overeenkomen, authenticeert de tunnel en vervoert daarna geen verkeer, wat een veel stiller falen is dan een weigering. Stel de versleuteling, integriteit, groep en levensduur van het kind in dezelfde ronde in. Houd de levensduur van de client gelijk aan of korter dan de waarde van de gateway, want aandringen op een langere levert dezelfde no proposal chosen-melding uit een andere oorzaak. Een afwijking daar ziet er identiek uit als een IKE-afwijking in het log.

Controleer of het profiel met certificaten of met een gedeeld geheim authenticeert terwijl je in de configuratie bent. Een voorstelafwijzing en een authenticatieafwijzing verschijnen op verschillende regels, en de verkeerde repareren kost een dag. Test met een nieuwe verbinding na elke wijziging, één variabele tegelijk, want de cache verbergt welke parameter verschoof.

Laat de oude suite alleen staan zolang die nodig is

SHA-1 vastzetten met een groep van 1024 bits is een brug, geen bestemming. Beide zijn verouderd, en nieuwere clients kunnen ze ronduit weigeren, wat betekent dat het profiel op het volgende apparaat faalt zonder enige wijziging aan jouw kant. Behandel de pin als tijdelijk en zeg dat in het verslag.

Als strongSwan van jou is, voeg een modern voorstel toe en laat beide kanten omhoog onderhandelen terwijl de oude vermelding voor oudere apparaten blijft. Lees de statusuitvoer van de daemon om te zien welke suite elke verbinding werkelijk gebruikte. Verwijder daarna de pin aan de clientkant zodra het moderne paar is bevestigd. Een tunnel die opkomt is niet genoeg bewijs, want hij kan opkomen op de suite die je probeerde uit te faseren. De IKEv2-documentatie van strongSwan beschrijft de voorstelsyntaxis en de strict-marker.