iOS avviste strongSwan-tunnelen din: sammenlign IKE-forslagene

Ingenting i sertifikatet eller adressen forklarer hvorfor en iPhone som i fjor koblet til strongSwan feiler i år. Ingenting ved adressen, den forhåndsdelte nøkkelen eller klientens identitet trenger å ha endret seg. Det som flyttet seg, er listen over transformasjoner som telefonens innebygde klient er villig til å forhandle om, og når den listen slutter å overlappe serverens, avsluttes utvekslingen før noens identitet blir undersøkt.

Logglinjen som avgjør det

Skru opp loggføringen for den tilkoblingen og finn de to oppføringene som avgjør utfallet: hva telefonen tilbød, og hva serveren valgte. Hvis loggen slutter uten et valgt forslag og melder at ingenting passet, ble autentisering aldri forsøkt. Et nytt sertifikat og et nytt passord endrer ingenting på det punktet, fordi begge brukes på et senere stadium. Ingen av dem kan påvirke et resultat som ble avgjort før identiteten ble undersøkt.

Hold de to feilformene fra hverandre før du redigerer noe. Ingen endring av transformasjonene redder avviste påloggingsdata, og ingen retting av påloggingsdataene redder en avvist transformasjon. Loggoppføringen som navngir et valgt forslag, forteller deg hvilken av de to du er i. Uten den oppføringen gjetter du.

Den valgte linjen navngir forslaget etter transformasjonssettet sitt i stedet for en vennlig etikett. Sammenlign feltene for kryptering, integritet og gruppe i den linjen med listen telefonen sendte, fordi avvik i ett enkelt felt er nok til å tape.

Hva endret seg på telefonen

Én iOS-utgivelse kuttet algoritmene klienten er villig til å bruke. Svake integritetshasher, små Diffie-Hellman-grupper og forslag som lister gamle valg først, sluttet å være akseptable.

Lengre lister er ikke tryggere her. Utvalget følger telefonens aksepterte sett og dens egen preferanseorden, så en server som annonserer en bred katalog kan fortsatt tape forhandlingen når de moderne oppføringene ikke er de som velges. Foretrekk en kort liste med de moderne oppføringene først. En lang liste som åpner med gamle valg, inviterer nøyaktig den feilen du prøver å unngå. Det aksepterte settet er en ytre begrensning som flytter seg hver gang klienten oppdateres, så en konfigurasjon som virket i går, er bevis om i går.

Ett par som fortsatt forhandler

For dagens telefoner er én moderne kombinasjon tilstrekkelig. Ett par som forhandler ser slik ut:

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

ike-linjen bærer krypteringen, integriteten og Diffie-Hellman-gruppen som brukes mens nøkkelutvekslingen pågår. esp-linjen dekker bare datakanalen, fordi gruppen ble avgjort før den gjelder. Last inn tilkoblingen på nytt eller start daemonen på nytt, og koble deretter til telefonen igjen. Behold den gruppeverdien bare hvis hver klient du betjener fortsatt aksepterer den, og ikke utvid forslaget for alle fordi én gammel peer trenger mer.

Tre steder å rette det, ett er vanligvis lukket

• Ett moderne forslag for hver peer. Riktig når alle klienter er dagens telefoner og skrivebord. Det sletter de gamle transformasjonene i stedet for å forhandle rundt dem.
• En annen tilkoblingsdefinisjon for Apple-klienter. Holder en gammel peer i live mens telefonen får et forslag den aksepterer. Det koster en ekstra tilkoblingsblokk og gjør unntaket synlig.
• Å bytte klient. Sjelden åpent for deg: når et styringssystem eller en app leverer profilen, finnes det ingen forslagsredigerer å ta på, og den innebygde klienten viser ingen.

Velg det andre alternativet når en enhet utenfor din kontroll ikke kan oppdateres. Velg det første når du kan pensjonere den gamle peeren og heller vil bære én policy.

Uansett er valget synlig i konfigurasjonen, og det er poenget. En stille tilbakefall som forhandler ned til en gammel transformasjon er verre enn en eksplisitt blokk, fordi ingen gjennomgang noen gang vil avdekke den.

Bevis det, og skriv det så ned

Koble til igjen og kontroller tre separate fakta på serveren: et forslag ble valgt, tilkoblingen vises som etablert, og klienten mottok en adresse. Et etablert håndtrykk uten fjernadresse peker på poolen eller trafikkvelgerne, og det hører i sin egen endring. Behandles de to sammen, ser en løst forhandling uløst ut.

Skriv ned transformasjonssettet som ble akseptert, når du endret det, og hvilken klientbuild du verifiserte. Neste oppdatering kan flytte kravet igjen, og verdiene som virket, er det første du vil ha ved siden av de nye.