iOS odmítl váš tunel strongSwan: porovnejte návrhy IKE
Fungující adresa a platný certifikát mohou i tak prohrát vyjednávání. Porovnejte řádky ike a esp s tím, co telefon přijímá.
Nic v certifikátu ani v adrese nevysvětluje, proč iPhone, který se loni připojoval k strongSwan, letos selhává. Nic na adrese, předsdíleném klíči ani identitě klienta se měnit nemuselo. Změnil se seznam transformací, které je vestavěný klient telefonu ochoten vyjednávat, a jakmile se tento seznam přestane překrývat se seznamem serveru, výměna skončí dřív, než je ověřena něčí identita.
Řádek v logu, který to rozhodne
Zvyšte úroveň logování pro toto spojení a najděte dva záznamy, které rozhodují o výsledku: co nabídl telefon a co vybral server. Pokud log skončí bez vybraného návrhu a hlásí, že se nic neshodovalo, autentizace se vůbec nezkoušela. Nový certifikát a nové heslo na tom místě nic nezmění, protože obojí se spotřebovává v pozdější fázi. Ani jedno nemůže ovlivnit výsledek, který byl rozhodnut před ověřením identity.
Rozlište oba tvary selhání dřív, než cokoli upravíte. Žádná úprava transformací nezachrání odmítnuté přihlašovací údaje a žádná oprava údajů nezachrání odmítnutou transformaci. Záznam v logu, který pojmenuje vybraný návrh, vám řekne, ve které ze dvou situací jste. Bez toho záznamu hádáte.
Vybraný řádek pojmenovává návrh podle jeho sady transformací, nikoli podle přátelského označení. Porovnejte pole šifrování, integrity a skupiny v tomto řádku se seznamem, který telefon poslal, protože neshoda v kterémkoli jednom poli stačí k prohře.
Co se na telefonu změnilo
Jedno vydání iOS ořezalo algoritmy, které je jeho klient ochoten používat. Slabé hashe integrity, malé skupiny Diffie-Hellman a návrhy, které uvádějí staré volby první, přestaly být přijatelné.
Delší seznamy tu nejsou bezpečnější. Výběr se řídí přijímanou množinou telefonu a jejím vlastním pořadím preferencí, takže server, který inzeruje široký katalog, může vyjednávání přesto prohrát, když moderní položky nejsou ty, které se vyberou. Dejte přednost krátkému seznamu s moderními položkami na začátku. Dlouhý seznam, který začíná starými volbami, zve právě to selhání, kterému se snažíte vyhnout. Přijímaná množina je vnější omezení, které se posune při každé aktualizaci klienta, takže konfigurace, která fungovala včera, je důkaz o včerejšku.
Jeden pár, který ještě vyjedná
Pro současné telefony stačí jediná moderní kombinace. Jeden pár, který vyjedná, vypadá takto:
ike=aes256-sha2_256-modp2048
esp=aes256-sha2_256
Řádek ike nese šifrování, integritu a skupinu Diffie-Hellman, které se používají během výměny klíčů. Řádek esp pokrývá jen datový kanál, protože skupina byla určena dřív, než začne platit. Znovu načtěte spojení nebo restartujte démona a potom telefon znovu připojte. Ponechte tuto hodnotu skupiny jen tehdy, když ji každý klient, kterého obsluhujete, ještě přijímá, a nerozšiřujte návrh pro všechny jen proto, že jeden starý protějšek potřebuje víc.
Tři místa, kde to opravit, jedno bývá zavřené
- Jeden moderní návrh pro každý protějšek. Správné, když jsou všichni klienti současné telefony a počítače. Maže staré transformace místo vyjednávání kolem nich.
- Druhá definice spojení pro klienty Apple. Udrží jeden starý protějšek naživu a zároveň dá telefonu návrh, který přijme. Stojí další blok spojení a činí výjimku viditelnou.
- Změna klienta. Zřídka vám otevřená: když profil dodává systém správy nebo aplikace, není žádný editor návrhů, do kterého by se dalo sáhnout, a vestavěný klient žádný nezpřístupňuje.
Zvolte druhou možnost, když zařízení mimo vaši kontrolu nelze aktualizovat. Zvolte první, když můžete starý protějšek vyřadit a raději nesete jedinou politiku.
Tak či tak je volba vidět v konfiguraci, a o to jde. Tichý návrat, který vyjedná dolů na starou transformaci, je horší než explicitní blok, protože žádná revize ho nikdy neodhalí.
Dokažte to, pak to zaznamenejte
Připojte se znovu a ověřte na serveru tři oddělená fakta: byl vybrán návrh, spojení se hlásí jako navázané a klient dostal adresu. Navázaný handshake bez vzdálené adresy ukazuje na pool nebo na selektory provozu a patří do samostatné změny. Když obojí řešíte spolu, vyřešené vyjednávání vypadá nevyřešeně.
Zapište sadu transformací, která byla přijata, kdy jste ji změnili a kterou build klienta jste ověřili. Příští aktualizace může požadavek znovu posunout a hodnoty, které fungovaly, jsou to první, co budete chtít mít vedle nových.