iOS avvisade din strongSwan-tunnel: jämför IKE-förslagen

Ingenting i certifikatet eller adressen förklarar varför en iPhone som anslöt till strongSwan i fjol misslyckas i år. Ingenting kring adressen, den fördelade nyckeln eller klientens identitet behöver ha ändrats. Det som flyttade sig är listan över transformationer som telefonens inbyggda klient är beredd att förhandla, och när den listan slutar överlappa serverns avslutas utbytet innan någons identitet har granskats.

Loggraden som avgör det

Höj loggningen för den anslutningen och hitta de två poster som avgör utfallet: vad telefonen erbjöd och vad servern valde. Om loggen slutar utan ett valt förslag och rapporterar att ingenting matchade gjordes aldrig något autentiseringsförsök. Ett färskt certifikat och ett nytt lösenord ändrar ingenting där, eftersom båda förbrukas i ett senare skede. Ingen av dem kan påverka ett utfall som avgjordes innan identiteten granskades.

Håll de två felformerna isär innan du redigerar något. Ingen transformändring räddar en avvisad uppgift, och ingen uppgiftsfix räddar en avvisad transformation. Loggposten som namnger ett valt förslag säger vilken av de två du är i. Utan den posten gissar du.

Den valda raden namnger förslaget efter sin transformuppsättning i stället för en vänlig etikett. Jämför fälten för kryptering, integritet och grupp i den raden med listan telefonen skickade, eftersom en avvikelse i ett enda fält räcker för att förlora.

Vad som ändrades i telefonen

En iOS-version skar ned algoritmerna som dess klient är beredd att använda. Svaga integritetshashar, små Diffie-Hellman-grupper och förslag som listar äldre alternativ först slutade vara acceptabla.

Längre listor är inte säkrare här. Urvalet följer telefonens accepterade mängd och dess egen preferensordning, så en server som annonserar en bred katalog kan ändå förlora förhandlingen när de moderna posterna inte är de som väljs. Föredra en kort lista med de moderna posterna först. En lång lista som inleds med äldre alternativ bjuder in precis det fel du försöker undvika. Den accepterade mängden är en yttre begränsning som flyttar sig varje gång klienten uppdateras, så gårdagens fungerande konfiguration är bevis om gårdagen.

Ett par som fortfarande förhandlar

För aktuella telefoner räcker en enda modern kombination. Ett par som förhandlar ser ut så här:

ike=aes256-sha2_256-modp2048
esp=aes256-sha2_256

Raden ike bär krypteringen, integriteten och Diffie-Hellman-gruppen som används medan nyckelutbytet pågår. Raden esp täcker bara datakanalen, eftersom gruppen avgjordes innan den tillämpas. Ladda om anslutningen eller starta om daemonen och anslut sedan telefonen igen. Behåll det gruppvärdet bara om varje klient du betjänar fortfarande accepterar det, och bredda inte förslaget för alla bara för att en gammal peer behöver mer.

Tre ställen att fixa det på, en är oftast stängd

• Ett modernt förslag för varje peer. Korrekt när alla klienter är aktuella telefoner och stationära datorer. Det tar bort de gamla transformationerna i stället för att förhandla runt dem.
• En andra anslutningsdefinition för Apple-klienter. Håller en gammal peer vid liv samtidigt som telefonen får ett förslag den accepterar. Det kostar ett extra anslutningsblock och gör undantaget synligt.
• Ändra klienten. Sällan öppet för dig: när ett hanteringssystem eller en app levererar profilen finns ingen förslagsredigerare att röra, och den inbyggda klienten exponerar ingen.

Välj det andra alternativet när en enhet utanför din kontroll inte kan uppdateras. Välj det första när du kan avveckla den gamla peeren och föredrar att bära en enda policy.

Hur som helst är valet synligt i konfigurationen, och det är poängen. En tyst nedfall som förhandlar ned till en gammal transformation är värre än ett uttryckligt block, eftersom ingen granskning någonsin kommer att synliggöra det.

Bevisa det, registrera det sedan

Anslut igen och kontrollera tre separata fakta på servern: ett förslag valdes, anslutningen visar upprättad och klienten fick en adress. Ett upprättat handskakning utan fjärradress pekar på poolen eller trafikväljarna, och hör hemma i en egen ändring. Behandlas de två tillsammans ser en löst förhandling olöst ut.

Skriv ner transformuppsättningen som accepterades, när du ändrade den och vilken klientbyggnad du verifierade. Nästa uppdatering kan flytta kravet igen, och värdena som fungerade är det första du vill ha bredvid de nya.