iOS avviste strongSwan-tunnelen din: samanlikn IKE-framlegga
Ei adresse som verkar og eit gyldig sertifikat kan framleis tape forhandlinga. Samanlikn ike- og esp-linjene med det telefonen godtek.
Ingenting i sertifikatet eller adressa forklarar kvifor ein iPhone som i fjor kopla til strongSwan feilar i år. Ingenting ved adressa, den førehandsdélte nøkkelen eller identiteten til klienten treng å ha endra seg. Det som flytta seg, er lista over transformasjonar som den innebygde klienten på telefonen er viljug til å forhandle om, og når den lista sluttar å overlappe server si liste, blir utvekslinga avslutta før nokon sin identitet blir granska.
Logglinja som avgjer det
Skru opp loggføringa for den tilkoplinga og finn dei to oppføringane som avgjer utfallet: kva telefonen baud på, og kva serveren valde. Viss loggen sluttar utan eit valt framlegg og melder at ingenting passa, vart autentisering aldri freista. Eit nytt sertifikat og eit nytt passord endrar ingenting på det punktet, fordi begge blir brukte på eit seinare stadium. Ingen av dei kan påverke eit resultat som vart avgjort før identiteten vart granska.
Hald dei to feilformene frå kvarandre før du redigerer noko. Inga endring av transformasjonane reddar avviste påloggingsdata, og inga retting av påloggingsdataa reddar ein avvist transformasjon. Loggoppføringa som namngjev eit valt framlegg, fortel deg kva av dei to du er i. Utan den oppføringa gissar du.
Den valde linja namngjev framlegget etter transformasjonssettet sitt i staden for ei venleg etikett. Samanlikn felta for kryptering, integritet og gruppe i den linja med lista telefonen sende, fordi avvik i eitt einskilt felt er nok til å tape.
Kva endra seg på telefonen
Éin iOS-utgåve kutta algoritmane klienten er viljug til å bruke. Svake integritetshasher, små Diffie-Hellman-grupper og framlegg som listar gamle val først, slutta å vere akseptable.
Lengre lister er ikkje tryggare her. Utvalet følgjer det aksepterte settet til telefonen og hans eigen preferanseorden, så ein server som annonserer ein brei katalog kan framleis tape forhandlinga når dei moderne oppføringane ikkje er dei som blir valde. Føretrekk ei kort liste med dei moderne oppføringane først. Ei lang liste som opnar med gamle val, inviterer nettopp den feilen du prøver å unngå. Det aksepterte settet er ei ytre avgrensing som flyttar seg kvar gong klienten blir oppdatert, så ein konfigurasjon som verka i går, er prov om i går.
Eitt par som framleis forhandlar
For dagens telefonar er éin moderne kombinasjon tilstrekkeleg. Eitt par som forhandlar ser slik ut:
ike=aes256-sha2_256-modp2048
esp=aes256-sha2_256
ike-linja ber krypteringa, integriteten og Diffie-Hellman-gruppa som blir brukte medan nøkkelutvekslinga går føre seg. esp-linja dekkjer berre datakanalen, fordi gruppa vart avgjort før ho gjeld. Last inn tilkoplinga på nytt eller start daemonen på nytt, og kople deretter telefonen til igjen. Hald den gruppeverdien berre viss kvar klient du tenar framleis aksepterer han, og ikkje utvid framlegget for alle fordi ein gammal peer treng meir.
Tre stader å rette det, eitt er vanlegvis lukka
- Eitt moderne framlegg for kvar peer. Riktig når alle klientar er dagens telefonar og skrivebord. Det slettar dei gamle transformasjonane i staden for å forhandle rundt dei.
- Ei anna tilkoplingsdefinisjon for Apple-klientar. Held ein gammal peer i live medan telefonen får eit framlegg han aksepterer. Det kostar ein ekstra tilkoplingsblokk og gjer unntaket synleg.
- Å byte klient. Sjeldan ope for deg: når eit styringssystem eller ein app leverer profilen, finst det ingen framleggsredigerar å ta på, og den innebygde klienten viser ingen.
Vel det andre alternativet når eit apparat utanfor din kontroll ikkje kan oppdaterast. Vel det første når du kan pensjonere den gamle peeren og heller vil bere éin politikk.
Uansett er valet synleg i konfigurasjonen, og det er poenget. Eit stille tilbakefall som forhandlar ned til ein gammal transformasjon er verre enn ein eksplisitt blokk, fordi ingen gjennomgang nokon gong vil avdekkje han.
Prov det, og skriv det så ned
Kople til igjen og kontroller tre separate fakta på serveren: eit framlegg vart valt, tilkoplinga viser seg som etablert, og klienten fekk ei adresse. Eit etablert handtrykk utan fjernadresse peikar på poolen eller trafikkveljarane, og det høyrer i si eiga endring. Blir dei to handsama saman, ser ei løyst forhandling uløyst ut.
Skriv ned transformasjonssettet som vart akseptert, når du endra det, og kva klientbygg du verifiserte. Neste oppdatering kan flytte kravet igjen, og verdiane som verka, er det første du vil ha ved sida av dei nye.