Vložíte vopred zdieľaný kľúč zo správy správcu do dialógu NetworkManager-a, zaškrtnete políčko na jeho zobrazenie a sedí znak po znaku. Spojenie sa napriek tomu skončí chybou autentifikácie skôr, než sa tunel zdvihne. Keď som to videl prvý raz, predpokladal som, že kľúč je nesprávny; nebol. O tom, čo démon naozaj číta, rozhodujú dve ďalšie veci: súbor tajomstiev, ktorý doplnok pre to spojenie zapisuje, a to, či hodnota prešla dialógom bez zmeny.

Postup nižšie sleduje kľúč z poľa do súboru a práve toto poradie hovorí, kde sa stratil. Robte to na stroji, ktorý zlyháva, nie na tom, ktorý funguje, pretože rozdiel medzi týmito dvoma strojmi je zvyčajne usporiadanie súborov, nie kľúč.

Začnite pri dialógu, ale neverte poľu

Otvorte kartu IPsec daného spojenia a kľúč znova napíšte namiesto vloženia. Kľúč skopírovaný z chatovej správy, PDF alebo správcu hesiel môže prísť so zalomením riadka na konci, ktoré pole nezobrazuje, a zobrazené znaky stále vyzerajú správne.

Kliknite na ovládací prvok na zobrazenie hesla a pozrite sa na koniec reťazca, nie do stredu. Ak kurzor nechá pod textom prázdny riadok, vymažte ho a napíšte posledný znak znova. Táto jediná oprava vyrieši prekvapivú časť takýchto hlásení a stojí menej než čítanie akéhokoľvek logu.

Ak kľúč prišiel z tiketového systému, ktorý zalomuje dlhé riadky, vyžiadajte si ho cez kanál, ktorý nezalomuje. Porovnajte dĺžky so správcom namiesto porovnávania dvoch reťazcov vedľa seba; stratený znak v mieste zalomenia je v proporcionálnom písme neviditeľný.

Sledujte kľúč do /etc/ipsec.d

Doplnok nikdy neodovzdá PSK démonovi IPsec ako argument na príkazovom riadku. Namiesto toho uloží hodnotu do súboru tajomstiev a zariadi, aby démon tento súbor načítal, pričom do /etc/ipsec.secrets pridá riadok include, ak tam žiadny nie je. To, čo dialóg drží, je vstup pre tento vygenerovaný súbor, nie hodnota, ktorá sa používa.

Predtým, než čokoľvek zmeníte, vypíšte, čo 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šie verzie doplnku zapisovali jeden súbor na spojenie, pomenovaný podľa UUID spojenia, napríklad /etc/ipsec.d/nm-l2tp-ipsec-<uuid>.secrets. Odstránenie profilu v applete tento súbor spoľahlivo neodstráni. Ak na disku zostal starý súbor z predchádzajúceho servera a je stále zahrnutý, démon môže vybrať tajomstvo patriace profilu, ktorý už nepoužívate, a spojenie zlyhá, hoci viditeľné pole je správne.

Pochopte, čo zmena v 1.2.12 urobila s aktualizáciami

Verzia doplnku 1.2.12 nahradila súbory tajomstiev pre každé spojenie jediným zdieľaným súborom, /etc/ipsec.d/ipsec.nm-l2tp.secrets. Aktualizácia nečistí staršie súbory podľa UUID a existujúci riadok include /etc/ipsec.d/*.secrets ich stále načítava. Verzia 1.2.16 zmenila spracovanie predvolených návrhov, nie usporiadanie tajomstiev.

Táto história vysvetľuje, prečo sa dva stroje so zdanlivo rovnakým profilom správajú odlišne. Kľúč je totožný; množina súborov, ktoré démon načítava, nie je. Keď odstraňujete osirelý súbor, presuňte ho nabok namiesto vymazania, potvrďte spojenie a až potom ho vymažte, keď je funkčný stav zaznamenaný. Premenovanie udrží starú hodnotu obnoviteľnou, ak sa ukáže, že porucha je inde.

Oddeľte znaky, ktoré formát ukladania nevie obsiahnuť

Dokumentácia strongSwan k reťazcu zdieľaného tajomstva uvádza, že hodnota nesmie obsahovať zalomenie riadka ani znak dvojitej úvodzovky. Kľúč vložený z dokumentu môže niesť ktorékoľvek z toho bez akéhokoľvek vizuálneho rozdielu v bežnom dialógu.

Od 1.2.12 uložená hodnota nie je obyčajný text. Doplnok zakóduje PSK do base64 predtým, než sa dostane do súboru, a poznámky k vydaniu uvádzajú toto kódovanie ako dôvod, prečo je dvojitá úvodzovka v kľúči teraz prijateľná. Úvodzovka napísaná do poľa je teda reprezentovateľná; to isté neplatí pre každý riadiaci znak.

Dĺžka je iné obmedzenie. V softvéri L2TP/IPsec neplatí žiadne univerzálne minimum: niektorí klienti prijímajú kľúče kratšie ako dvadsať znakov a niektoré brány minimum vynucujú. Ak je krátky kľúč odmietnutý, pravidlo patrí zásade servera alebo validácii toho klienta, a zvýšenie niečoho lokálne to nezmení.

Prečítajte, ktorá vrstva autentifikácie zlyhala

Najprv spustite ipsec --version, pretože strongSwan a Libreswan používajú iné názvy súborov a syntax a rada pre jeden môže poškodiť druhý. Potom prečítajte fázu zlyhania zo správy klienta alebo z logu démona: sťažnosť na vopred zdieľaný kľúč je iná udalosť než odmietnuté používateľské meno a heslo.

PSK autentifikuje konce tunela. Používateľské meno a heslo autentifikujú osobu vnútri L2TP a PPP sa nimi zaoberá po zdvihnutí asociácie IPsec. Správny PSK s nesprávnym účtom napriek tomu zlyhá a zmena účtu neopraví kľúč, ktorý démon nikdy neprečítal správne.

Keď zatvárate tiket, zapíšte všetky štyri veci: verziu doplnku, používaný súbor tajomstiev, či bol kľúč znova napísaný alebo vložený, a vrstvu uvedenú v chybe. Potom ktokoľvek, kto tento postup neskôr zopakuje, môže rovno prejsť k rozdielu medzi funkčným a zlyhávajúcim strojom.

Súvisiace články