iOS hylkäsi strongSwan-tunnelisi: vertaa IKE-ehdotuksia

Mikään sertifikaatissa tai osoitteessa ei selitä, miksi iPhone, joka viime vuonna yhdisti strongSwaniin, epäonnistuu tänä vuonna. Osoitteen, ennalta jaetun avaimen tai asiakkaan identiteetin ei ole tarvinnut muuttua. Muuttunut on luettelo muunnoksista, joita puhelimen sisäänrakennettu asiakas on valmis neuvottelemaan, ja kun tuo luettelo lakkaa menemästä päällekkäin palvelimen luettelon kanssa, vaihto päättyy ennen kuin kenenkään identiteettiä tutkitaan.

Lokirivi, joka ratkaisee

Kasvata kyseisen yhteyden lokitusta ja etsi kaksi merkintää, jotka ratkaisevat tuloksen: mitä puhelin tarjosi ja mitä palvelin valitsi. Jos loki päättyy ilman valittua ehdotusta ja ilmoittaa, ettei mikään sopinut, todennusta ei koskaan yritetty. Uusi sertifikaatti ja uusi salasana eivät muuta siinä kohdassa mitään, koska molemmat kulutetaan myöhemmässä vaiheessa. Kumpikaan ei voi vaikuttaa tulokseen, joka ratkaistiin ennen identiteetin tutkimista.

Erottele kaksi vikamuotoa ennen kuin muokkaat mitään. Mikään muunnosten muokkaus ei pelasta hylättyjä tunnistetietoja, eikä mikään tunnistetietojen korjaus pelasta hylättyä muunnosta. Lokimerkintä, joka nimeää valitun ehdotuksen, kertoo, kummassa kahdesta olet. Ilman sitä merkintää arvaat.

Valittu rivi nimeää ehdotuksen sen muunnosjoukon perusteella eikä ystävällisen tunnisteen perusteella. Vertaa salauksen, eheyden ja ryhmän kenttiä tuolla rivillä puhelimen lähettämään luetteloon, koska ero yhdessäkin kentässä riittää häviämiseen.

Mikä puhelimessa muuttui

Yksi iOS-julkaisu karsi algoritmeja, joita sen asiakas on valmis käyttämään. Heikot eheyshashit, pienet Diffie-Hellman-ryhmät ja ehdotukset, jotka listaavat vanhat vaihtoehdot ensin, eivät enää olleet hyväksyttäviä.

Pidemmät luettelot eivät ole täällä turvallisempia. Valinta seuraa puhelimen hyväksyttyä joukkoa ja sen omaa etusijajärjestystä, joten laajaa luetteloa mainostava palvelin voi silti hävitä neuvottelun, kun nykyaikaiset merkinnät eivät ole niitä, jotka valitaan. Suosi lyhyttä luetteloa, jossa nykyaikaiset merkinnät ovat ensin. Pitkä luettelo, joka alkaa vanhoilla vaihtoehdoilla, kutsuu täsmälleen sen vian, jota yrität välttää. Hyväksytty joukko on ulkoinen rajoite, joka liikkuu aina asiakkaan päivittyessä, joten eilen toiminut kokoonpano on todiste eilisestä.

Yksi pari, joka vielä neuvottelee

Nykyisille puhelimille yksi nykyaikainen yhdistelmä riittää. Yksi neuvotteleva pari näyttää tältä:

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

ike-rivi kantaa salauksen, eheyden ja Diffie-Hellman-ryhmän, joita käytetään avainvaihdon aikana. esp-rivi kattaa vain datakanavan, koska ryhmä päätettiin ennen kuin se astuu voimaan. Lataa yhteys uudelleen tai käynnistä daemon uudelleen ja yhdistä sitten puhelin uudestaan. Pidä tuo ryhmän arvo vain, jos jokainen palvelemasi asiakas hyväksyy sen vielä, äläkä laajenna ehdotusta kaikille siksi, että yksi vanha vastapuoli tarvitsee enemmän.

Kolme paikkaa korjata, yksi on yleensä suljettu

• Yksi nykyaikainen ehdotus jokaiselle vastapuolelle. Oikein, kun kaikki asiakkaat ovat nykyisiä puhelimia ja työpöytiä. Se poistaa vanhat muunnokset sen sijaan, että neuvottelisi niiden ympärillä.
• Toinen yhteyden määritelmä Apple-asiakkaille. Pitää yhden vanhan vastapuolen elossa ja antaa puhelimelle ehdotuksen, jonka se hyväksyy. Se maksaa yhden yhteyslohkon lisää ja tekee poikkeuksesta näkyvän.
• Asiakkaan vaihtaminen. Harvoin sinulle avoin: kun hallintajärjestelmä tai sovellus toimittaa profiilin, ei ole ehdotuseditoria, jota koskettaa, eikä sisäänrakennettu asiakas paljasta sellaista.

Valitse toinen vaihtoehto, kun hallintasi ulkopuolella olevaa laitetta ei voi päivittää. Valitse ensimmäinen, kun voit poistaa vanhan vastapuolen käytöstä ja haluat mieluummin kantaa yhden käytännön.

Kummassakin tapauksessa valinta näkyy kokoonpanossa, ja siitä on kysymys. Hiljainen varautuminen, joka neuvottelee alas vanhaan muunnokseen, on pahempi kuin selkeä esto, koska mikään katselmus ei tuo sitä koskaan esiin.

Todista se ja kirjaa se sitten

Yhdistä uudelleen ja tarkista kolme erillistä tosiasiaa palvelimelta: ehdotus valittiin, yhteys näkyy muodostettuna ja asiakas sai osoitteen. Muodostettu kättely ilman etäosoitetta viittaa pooliin tai liikenteen valitsimiin, ja se kuuluu omaan muutokseensa. Molempien käsittely yhdessä saa ratkaistun neuvottelun näyttämään ratkaisemattomalta.

Kirjoita muistiin hyväksytty muunnosjoukko, milloin muutit sitä ja minkä asiakasbuildin varmistit. Seuraava päivitys voi siirtää vaatimusta taas, ja toimineet arvot ovat ensimmäinen asia, jonka haluat uusien viereen.