iOS afviste din strongSwan-tunnel: sammenlign IKE-forslagene

Intet i certifikatet eller adressen forklarer, hvorfor en iPhone, der sidste år kunne forbinde til strongSwan, fejler i år. Intet ved adressen, den foruddelte nøgle eller klientens identitet behøver at være ændret. Det, der har flyttet sig, er listen over transformationer, som telefonens indbyggede klient er parat til at forhandle om, og når den liste holder op med at overlappe serverens, slutter udvekslingen, før nogens identitet bliver undersøgt.

Loglinjen, der afgør det

Skru op for logningen af den forbindelse og find de to poster, der afgør udfaldet: hvad telefonen tilbød, og hvad serveren valgte. Hvis loggen slutter uden et valgt forslag og melder, at intet passede, blev der aldrig forsøgt autentificering. Et nyt certifikat og en ny adgangskode ændrer intet på det punkt, fordi begge bruges i en senere fase. Ingen af dem kan påvirke et resultat, der blev afgjort, før identiteten blev undersøgt.

Hold de to fejlformer adskilt, før du redigerer noget. Ingen ændring af transformationerne redder legitimationsoplysninger, der er afvist, og ingen rettelse af legitimationsoplysningerne redder en transformation, der er afvist. Logposten, der navngiver et valgt forslag, fortæller dig, hvilken af de to du er i. Uden den post gætter du.

Den valgte linje navngiver forslaget ud fra dets sæt af transformationer i stedet for en venlig etiket. Sammenlign felterne for kryptering, integritet og gruppe i den linje med den liste, telefonen sendte, fordi uoverensstemmelse i et enkelt felt er nok til at tabe.

Hvad ændrede sig på telefonen

En iOS-udgivelse skar de algoritmer ned, som dens klient er villig til at bruge. Svage integritetshashes, små Diffie-Hellman-grupper og forslag, der lister gamle muligheder først, holdt op med at være acceptable.

Længere lister er ikke sikrere her. Udvælgelsen følger telefonens accepterede sæt og dens egen præferenceorden, så en server, der annoncerer et bredt katalog, kan stadig tabe forhandlingen, når de moderne poster ikke er dem, der bliver valgt. Foretræk en kort liste med de moderne poster først. En lang liste, der åbner med gamle muligheder, indbyder præcis den fejl, du prøver at undgå. Det accepterede sæt er en ydre begrænsning, der flytter sig, hver gang klienten opdateres, så en konfiguration, der virkede i går, er bevis om i går.

Et par, der stadig forhandler

For nuværende telefoner er en enkelt moderne kombination tilstrækkelig. Et par, der forhandler, ser sådan ud:

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

ike-linjen bærer krypteringen, integriteten og Diffie-Hellman-gruppen, der bruges, mens nøgleudvekslingen kører. esp-linjen dækker kun datakanalen, fordi gruppen blev fastlagt, før den gælder. Genindlæs forbindelsen, eller genstart daemonen, og tilslut derefter telefonen igen. Behold kun den gruppeværdi, hvis hver klient, du betjener, stadig accepterer den, og udvid ikke forslaget for alle, fordi en gammel peer har brug for mere.

Tre steder at rette det, ét er normalt lukket

• Et moderne forslag til hver peer. Korrekt når alle klienter er nuværende telefoner og skriveborde. Det sletter de gamle transformationer i stedet for at forhandle uden om dem.
• En anden forbindelsesdefinition til Apple-klienter. Holder en gammel peer i live, mens telefonen får et forslag, den accepterer. Det koster en ekstra forbindelsesblok og gør undtagelsen synlig.
• At skifte klienten. Sjældent åbent for dig: når et styringssystem eller en app leverer profilen, er der ingen forslagseditor at røre, og den indbyggede klient udstiller ingen.

Vælg den anden mulighed, når en enhed uden for din kontrol ikke kan opdateres. Vælg den første, når du kan pensionere den gamle peer og hellere vil bære én politik.

Uanset hvad er valget synligt i konfigurationen, og det er pointen. Et tavst fallback, der forhandler ned til en gammel transformation, er værre end en eksplicit blok, fordi ingen gennemgang nogensinde vil afsløre det.

Bevis det, og skriv det så ned

Forbind igen, og kontroller tre separate fakta på serveren: der blev valgt et forslag, forbindelsen vises som etableret, og klienten modtog en adresse. Et etableret handshake uden fjernadresse peger på poolen eller trafikvælgerne, og det hører i sin egen ændring. Behandles de to sammen, ser en løst forhandling uløst ud.

Skriv det sæt transformationer ned, der blev accepteret, hvornår du ændrede det, og hvilket klientbuild du verificerede. Den næste opdatering kan flytte kravet igen, og de værdier, der virkede, er det første, du vil have ved siden af de nye.