Odmítnutý PSK u L2TP/IPsec: projděte dialog a pak soubory

Vložíte předsdílený klíč ze zprávy správce do dialogu NetworkManageru, zaškrtnete políčko pro jeho zobrazení a on sedí znak za znakem. Spojení přesto skončí chybou autentizace dřív, než se tunel zvedne. Když jsem to viděl poprvé, předpokládal jsem, že klíč je špatný; nebyl. O tom, co démon skutečně přečte, rozhodují dvě další věci: soubor s tajemstvími, který plugin pro to spojení zapíše, a zda hodnota prošla dialogem beze změny.

Postup níže sleduje klíč z pole do souboru a právě toto pořadí říká, kde se ztratil. Dělejte to na stroji, který selhává, ne na tom, který funguje, protože rozdíl mezi těmito dvěma stroji bývá v uspořádání souborů, ne v klíči.

Začněte u dialogu, ale nevěřte poli

Otevřete kartu IPsec daného spojení a klíč znovu napište, místo abyste ho vložili. Klíč zkopírovaný z chatové zprávy, PDF nebo správce hesel může dorazit se zalomením řádku na konci, které pole nezobrazuje, a zobrazené znaky přesto vypadají správně.

Klikněte na ovládací prvek pro zobrazení hesla a podívejte se na konec řetězce, ne doprostřed. Pokud kurzor nechá pod textem prázdný řádek, smažte ho a napište poslední znak znovu. Tahle jediná úprava vyřeší překvapivě velkou část těchto hlášení a stojí méně než čtení jakéhokoli logu.

Pokud klíč přišel z tiketového systému, který zalamuje dlouhé řádky, vyžádejte si ho kanálem, který nezalamuje. Porovnejte délky se správcem, místo abyste dva řetězce okem srovnávali vedle sebe; ztracený znak v místě zalomení je v proporcionálním písmu neviditelný.

Sledujte klíč do /etc/ipsec.d

Plugin nikdy nepředává PSK démonu IPsec jako argument na příkazovém řádku. Místo toho hodnotu uloží do souboru s tajemstvími a zařídí, aby démon tento soubor načetl, přičemž do /etc/ipsec.secrets přidá řádek include, pokud tam žádný není. Co dialog drží, je vstup pro tento generovaný soubor, ne hodnota, která se používá.

Než cokoli změníte, vypište, co existuje:

ipsec --version
sudo ls -l /etc/ipsec.d/*.secrets /etc/ipsec.d/ipsec.nm-l2tp.secrets 2>/dev/null
sudo grep -n "include" /etc/ipsec.secrets

Starší verze pluginu psaly jeden soubor na spojení, pojmenovaný podle UUID spojení, například /etc/ipsec.d/nm-l2tp-ipsec-<uuid>.secrets. Smazání profilu v appletu tento soubor spolehlivě nesmaže. Pokud na disku zůstal starý soubor z předchozího serveru a je stále zahrnut, démon může vybrat tajemství patřící profilu, který už nepoužíváte, a spojení selže, i když je viditelné pole správné.

Pochopte, co změna 1.2.12 udělala s upgrady

Verze pluginu 1.2.12 nahradila soubory s tajemstvími pro každé spojení jediným sdíleným souborem, /etc/ipsec.d/ipsec.nm-l2tp.secrets. Upgrade starší soubory podle UUID neuklízí a existující řádek include /etc/ipsec.d/*.secrets je stále načítá. Verze 1.2.16 změnila zpracování výchozích návrhů, ne uspořádání tajemství.

Tato historie vysvětluje, proč se dva stroje se zdánlivě stejným profilem chovají různě. Klíč je totožný; množina souborů, které démon načítá, není. Když odebíráte osiřelý soubor, přesuňte ho stranou, místo abyste ho mazali, potvrďte spojení a pak ho smažte, jakmile je zaznamenán funkční stav. Přejmenování udrží starou hodnotu obnovitelnou, pokud se ukáže, že závada je jinde.

Oddělte znaky, které úložný formát neumí pojmout

Dokumentace strongSwanu ke sdílenému tajemství uvádí, že hodnota nesmí obsahovat zalomení řádku ani znak dvojité uvozovky. Klíč vložený z dokumentu může nést kterékoli z toho bez jakéhokoli vizuálního rozdílu v běžném dialogu.

Od verze 1.2.12 uložená hodnota není prostý text. Plugin nejprve zakóduje PSK do base64, než se dostane do souboru, a poznámky k vydání uvádějí toto kódování jako důvod, proč je dvojitá uvozovka v klíči nyní přijatelná. Uvozovka napsaná do pole je tedy reprezentovatelná; totéž neplatí pro každý řídicí znak.

Délka je jiné omezení. Pro software L2TP/IPsec neplatí žádné univerzální minimum: někteří klienti přijímají klíče kratší než dvacet znaků a některé brány minimum vynucují. Pokud je krátký klíč odmítnut, pravidlo patří zásadě serveru nebo validaci toho klienta a zvýšení něčeho lokálně to nezmění.

Přečtěte, která vrstva autentizace selhala

Nejprve spusťte ipsec --version, protože strongSwan a Libreswan používají jiná jména souborů a jinou syntaxi a rada pro jeden může poškodit druhý. Pak z klientské zprávy nebo z logu démona přečtěte fázi selhání: stížnost na předsdílený klíč je jiná událost než odmítnuté uživatelské jméno a heslo.

PSK autentizuje koncové body tunelu. Uživatelské jméno a heslo autentizují osobu uvnitř L2TP a PPP se jimi zabývá poté, co je asociace IPsec zvednutá. Správný PSK se špatným účtem přesto selže a změna účtu neopraví klíč, který démon nikdy nepřečetl správně.

Když tiket zavíráte, zapište všechny čtyři věci: verzi pluginu, používaný soubor s tajemstvími, zda byl klíč znovu napsán nebo vložen, a vrstvu uvedenou v chybě. Kdokoli tento postup později zopakuje, může rovnou přeskočit k rozdílu mezi funkčním a selhávajícím strojem.