iOS odmietol váš tunel strongSwan: porovnajte návrhy IKE

Nič v certifikáte ani v adrese nevysvetľuje, prečo iPhone, ktorý sa vlani pripájal k strongSwan, tento rok zlyháva. Na adrese, vopred zdieľanom kľúči ani identite klienta sa nič nemuselo zmeniť. Zmenil sa zoznam transformácií, o ktorých je vstavaný klient telefónu ochotný rokovať, a keď sa tento zoznam prestane prekrývať so zoznamom servera, výmena sa skončí skôr, než sa overí niečia identita.

Riadok v logu, ktorý to rozhodne

Zvýšte úroveň logovania pre toto spojenie a nájdite dva záznamy, ktoré rozhodujú o výsledku: čo ponúkol telefón a čo vybral server. Ak sa log skončí bez vybraného návrhu a hlási, že sa nič nezhodovalo, autentifikácia sa vôbec neskúšala. Nový certifikát a nové heslo na tom mieste nič nezmenia, pretože oboje sa spotrebúva v neskoršej fáze. Ani jedno nemôže ovplyvniť výsledok, ktorý bol rozhodnutý pred overením identity.

Rozlíšte oba tvary zlyhania skôr, než čokoľvek upravíte. Žiadna úprava transformácií nezachráni odmietnuté prihlasovacie údaje a žiadna oprava údajov nezachráni odmietnutú transformáciu. Záznam v logu, ktorý pomenuje vybraný návrh, vám povie, v ktorej z dvoch situácií ste. Bez toho záznamu hádáte.

Vybraný riadok pomenúva návrh podľa jeho sady transformácií, nie podľa priateľského označenia. Porovnajte polia šifrovania, integrity a skupiny v tomto riadku so zoznamom, ktorý telefón poslal, pretože nezhoda v ktoromkoľvek jednom poli stačí na prehru.

Čo sa na telefóne zmenilo

Jedno vydanie iOS orezalo algoritmy, ktoré je jeho klient ochotný používať. Slabé hashe integrity, malé skupiny Diffie-Hellman a návrhy, ktoré uvádzajú staré možnosti ako prvé, prestali byť prijateľné.

Dlhšie zoznamy tu nie sú bezpečnejšie. Výber sa riadi prijímanou množinou telefónu a jeho vlastným poradím preferencií, takže server, ktorý inzeruje široký katalóg, môže rokovanie napriek tomu prehrať, keď moderné položky nie sú tie, ktoré sa vyberú. Uprednostnite krátky zoznam s modernými položkami na začiatku. Dlhý zoznam, ktorý začína starými možnosťami, pozýva presne to zlyhanie, ktorému sa snažíte vyhnúť. Prijímaná množina je vonkajšie obmedzenie, ktoré sa posúva pri každej aktualizácii klienta, preto konfigurácia, ktorá fungovala včera, je dôkaz o včerajšku.

Jeden pár, ktorý ešte vyjedná

Pre súčasné telefóny stačí jediná moderná kombinácia. Jeden pár, ktorý vyjedná, vyzerá takto:

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

Riadok ike nesie šifrovanie, integritu a skupinu Diffie-Hellman, ktoré sa používajú počas výmeny kľúčov. Riadok esp pokrýva len dátový kanál, pretože skupina bola určená skôr, než začne platiť. Znova načítajte spojenie alebo reštartujte démona a potom telefón znova pripojte. Ponechajte tú hodnotu skupiny len vtedy, keď ju každý klient, ktorému slúžite, ešte prijíma, a nerozširujte návrh pre všetkých len preto, že jeden starý partner potrebuje viac.

Tri miesta na opravu, jedno býva zatvorené

• Jeden moderný návrh pre každého partnera. Správne, keď sú všetci klienti súčasné telefóny a počítače. Maže staré transformácie namiesto vyjednávania okolo nich.
• Druhá definícia spojenia pre klientov Apple. Udrží jedného starého partnera nažive a zároveň dá telefónu návrh, ktorý prijme. Stojí ďalší blok spojenia a robí výnimku viditeľnou.
• Zmena klienta. Zriedka vám otvorená: keď profil dodáva systém správy alebo aplikácia, nie je žiadny editor návrhov, do ktorého by sa dalo siahnuť, a vstavaný klient žiadny neukazuje.

Zvoľte druhú možnosť, keď zariadenie mimo vašej kontroly nemožno aktualizovať. Zvoľte prvú, keď môžete starého partnera vyradiť a radšej nesiete jedinú politiku.

Tak či tak je voľba viditeľná v konfigurácii, a o to ide. Tichý návrat, ktorý vyjedná nadol na starú transformáciu, je horší ako explicitný blok, pretože žiadna revízia ho nikdy neodhalí.

Dokážte to, potom to zaznamenajte

Pripojte sa znova a overte na serveri tri oddelené fakty: bol vybraný návrh, spojenie sa hlási ako nadviazané a klient dostal adresu. Nadviazaný handshake bez vzdialenej adresy ukazuje na pool alebo na selektory prevádzky, a patrí do samostatnej zmeny. Keď obe riešite spolu, vyriešené rokovanie vyzerá nevyriešene.

Zapíšte sadu transformácií, ktorá bola prijatá, kedy ste ju zmenili a ktorý build klienta ste overili. Ďalšia aktualizácia môže požiadavku znova posunúť a hodnoty, ktoré fungovali, sú to prvé, čo budete chcieť mať vedľa nových.