Rozbila aktualizace Ubuntu L2TP/IPsec? Porovnejte návrhy IKEv1

Připojení fungovalo ve čtvrtek, aktualizace proběhla v pátek a v pondělí se klient zasekne na “connecting” a vzdá to. Stejný notebook, stejný server, stejný účet, stejný předem sdílený klíč. V profilu nebylo nic upraveno, a proto vás zjevní podezřelí, heslo a firewall, jen zdržují.

Změnil se seznam transformací, které je váš stroj ochoten nabídnout. Oba IPsec stacky používané na Ubuntu, strongSwan a Libreswan, vyřazují algoritmy, které už nepovažují za bezpečné, a plugin NetworkManager, který před nimi stojí, má vlastní seznam, jenž se posouvá podle jiného harmonogramu. Server připoutaný k 3DES, SHA1 a 1024bitové skupině Diffie-Hellman může nakonec neslyšet nic, co přijímá.

Co aktualizace skutečně změnila

Nabídku IKEv1 napájejí dvě vrstvy. Démon dodává výchozí sadu návrhů zkompilovanou do sebe a plugin L2TP se buď na ni spoléhá, nebo dodává vlastní seznam. Před NetworkManager-l2tp 1.2.16 se plugin spoléhal, takže vaše nabídka byla to, co instalovaný démon považoval za rozumné. Od verze 1.2.16 plugin posílá dokumentovaný seznam vymodelovaný podle klientů Windows a Apple a tento seznam je širší než staré výchozí nastavení, ale už neobsahuje každou starší kombinaci na čele fronty.

Toto rozdělení vysvětluje režim selhání, který lidem připadá matoucí: dva stroje na stejném vydání Ubuntu se mohou chovat různě, protože jeden má distribuční balíček a druhý backport, a verze démona na obou vypadá v hlášení o chybě stejně. Než uzavřete, že aktualizace nezměnila nic podstatného, zkontrolujte verzi pluginu, ne jen verzi démona.

Ve stejné oblasti je menší past. Oba démoni píší skupiny Diffie-Hellman s eliptickou křivkou různě, jeden píše ecp384 a druhý ecp_384. Vložte špatný pravopis do dialogu Advanced a démon nastavení odmítne jako neparsovatelné, což se v logu projeví jako problém vyjednávání, nikoli jako překlep v konfiguraci.

Přečtěte si selhání, než cokoli změníte

Začněte tím, který backend používáte, protože odpověď určuje jak syntaxi, tak umístění logu.

ipsec --version
nmcli connection show "Your VPN name" | grep -i ipsec

Potom si přečtěte samotnou výměnu. Na strongSwanu démon zapisuje do journalu na aktuálním vydání a do /var/log/syslog na starším a zajímavá je nabídka, kterou posílá, ne poslední řádek. Hledáte formulaci o tom, že žádný návrh neodpovídá, což je problém algoritmu; selhání autentizace, které ukazuje na klíč nebo účet; nebo obyčejný timeout, který ukazuje na dosažitelnost.

Tyto tři výsledky se příliš často považují za jeden příznak. Timeout s prázdným logem démona znamená, že pakety nepřicházejí. Odmítnutí návrhu znamená, že dorazily a byly odmítnuty. Pokud váš log mlčí, zvyšte na jeden pokus úroveň ladění pluginu a potom ji snižte, protože podrobný výstup rychle zaplní journal.

Fáze 1 a fáze 2 jsou oddělené sázky

IKEv1 vyjednává dvakrát. Hlavní režim sestavuje bezpečnostní asociaci IKE ze šifrovacího algoritmu, algoritmu integrity, skupiny Diffie-Hellman a metody autentizace. Rychlý režim potom sestaví asociaci ESP, která ponese L2TP. Server může první přijmout a druhou odmítnout, takže polopřesný profil selže později, než čekáte, a vypadá jako jiná chyba.

Phase 1: 3des-sha1-modp1024!
Phase 2: 3des-sha1!

Vykřičník je syntaxe strongSwan pro striktní záznam: nabídni tuto jednu kombinaci a nic jiného. Bez něj se záznam připojí k záložnímu seznamu, což je v pořádku, když je protějšek moderní, a kontraproduktivní, když je to zařízení s jedinou pevně zakódovanou politikou. Berte uvedenou dvojici jako ilustraci formy, ne jako doporučení pro cokoli, co dnes stavíte.

Změňte jedno pole a test zopakujte

U aktuálního pluginu je nejrychlejším prvním testem úplně vymazat obě pole návrhů a znovu se připojit, protože dodaný výchozí seznam už obsahuje běžné kombinace Windows a Apple. U staršího pluginu jejich vymazání vrátí kontrolu démonu, který mohl vyřadit algoritmus, na kterém váš server trvá, a selhání se zhorší.

Pokud vymazání nepomůže, nastavte striktní dvojici, kterou váš server dokumentuje, jednu fázi po druhé. Změňte fázi 1, připojte se znovu a přečtěte log, než se dotknete fáze 2. Když kombinace konečně funguje, zapište si ji vedle modelu serveru a verze pluginu, protože výchozí hodnoty se zase posunou a právě ta poznámka promění příští aktualizaci v pětiminutovou kontrolu.