Elutasított L2TP/IPsec PSK: előbb a párbeszéd, aztán a fájlok

Beilleszti az előre megosztott kulcsot az adminisztrátor üzenetéből a NetworkManager párbeszédablakába, bejelöli a megjelenítés négyzetét, és a kulcs karakterről karakterre megegyezik. A kapcsolat mégis hitelesítési hibával végződik, mielőtt az alagút felállna. Amikor ezt először láttam, azt feltételeztem, hogy a kulcs rossz; nem volt az. Két másik dolog dönti el, mit olvas valójában a démon: a titokfájl, amelyet a bővítmény ehhez a kapcsolathoz ír, és hogy az érték változatlanul jutott-e át a párbeszéden.

Az alábbi végigvezetés a kulcsot követi a mezőtől a fájlig, és ez a sorrend mondja meg, hol veszett el. A hibázó gépen végezze el, ne a működőn, mert a két gép közti különbség általában a fájlok elrendezése, nem a kulcs.

Kezdje a párbeszédnél, de ne bízzon a mezőben

Nyissa meg a kapcsolat IPsec lapját, és gépelje be újra a kulcsot a beillesztés helyett. A csevegőüzenetből, PDF-ből vagy jelszókezelőből másolt kulcs végén olyan sortörés érkezhet, amelyet a mező nem jelenít meg, a látható karakterek pedig továbbra is helyesnek tűnnek.

Kattintson a jelszó megjelenítését vezérlő elemre, és nézze meg a karakterlánc végét, ne a közepét. Ha a kurzor üres sort hagy a szöveg alatt, törölje azt, és gépelje be újra az utolsó karaktert. Ez az egyetlen javítás az ilyen bejelentések meglepő részét megoldja, és kevesebbe kerül, mint bármelyik napló elolvasása.

Ha a kulcs olyan jegyrendszerből jön, amely hosszú sorokat tördel, olyan csatornán kérje, amely nem tördel. Hasonlítsa össze a hosszakat az adminisztrátorral, ne nézzen két karakterláncot egymás mellett; a tördelési ponton elveszett karakter arányos betűtípusban láthatatlan.

Kövesse a kulcsot az /etc/ipsec.d belsejébe

A bővítmény soha nem adja át a PSK-t az IPsec-démonnak parancssori argumentumként. Ehelyett egy titokfájlban tárolja az értéket, és gondoskodik arról, hogy a démon beszúrja azt a fájlt, include sort fűzve az /etc/ipsec.secrets fájlhoz, ha nincs ilyen. Amit a párbeszéd tart, az a létrehozott fájl bemenete, nem a használatban lévő érték.

Sorolja fel, mi létezik, mielőtt bármit módosítana:

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

A bővítmény régebbi kiadásai kapcsolatonként egy fájlt írtak, a kapcsolat UUID-je alapján elnevezve, például /etc/ipsec.d/nm-l2tp-ipsec-<uuid>.secrets. A profil törlése az appletben nem törli megbízhatóan ezt a fájlt. Ha egy korábbi szerver régi fájlja még a lemezen van, és még mindig be van vonva, a démon olyan titkot választhat, amely egy már nem használt profilhoz tartozik, és a kapcsolat meghiúsul, miközben a látható mező helyes.

Értse meg, mit tett az 1.2.12-es változás a frissítésekkel

A bővítmény 1.2.12-es verziója a kapcsolatonkénti titokfájlokat egyetlen közös fájlra cserélte, /etc/ipsec.d/ipsec.nm-l2tp.secrets. A frissítés nem takarítja el a régebbi, UUID szerinti fájlokat, és egy meglévő include /etc/ipsec.d/*.secrets sor továbbra is bevonja őket. Az 1.2.16-os verzió az alapértelmezett javaslatok kezelését változtatta meg, nem a titkok elrendezését.

Ez a történet magyarázza, miért viselkedik másképp két gép, amelynek látszólag ugyanaz a profilja. A kulcs azonos; a démon által bevont fájlok halmaza nem. Amikor eltávolít egy árva fájlt, tegye félre a törlés helyett, erősítse meg a kapcsolatot, majd törölje, miután a működő állapot rögzítve van. Az átnevezés megőrzi a régi értéket visszaállíthatóan, ha kiderül, hogy a hiba máshol van.

Válassza külön azokat a karaktereket, amelyeket a tárolási formátum nem tud megtartani

A strongSwan dokumentációja a megosztott titok karakterláncáról kimondja, hogy az érték nem tartalmazhat sortörést vagy kettős idézőjelet. A dokumentumból beillesztett kulcs bármelyiket hordozhatja anélkül, hogy egy normál párbeszédben bármi látszana.

Az 1.2.12 óta a tárolt érték nem egyszerű szöveg. A bővítmény base64-kódolással látja el a PSK-t, mielőtt az a fájlba kerül, és a kiadási megjegyzések ezt a kódolást nevezik meg okként arra, hogy a kettős idézőjel most elfogadható egy kulcsban. A mezőbe gépelt idézőjel tehát ábrázolható; ugyanez nem igaz minden vezérlőkarakterre.

A hossz másik korlát. Az L2TP/IPsec szoftverekre nem vonatkozik egyetemes minimum: egyes kliensek húsz karakternél rövidebb kulcsokat is elfogadnak, más átjárók pedig minimumot írnak elő. Ha egy rövid kulcsot elutasítanak, a szabály a kiszolgáló szabályzatához vagy az adott kliens ellenőrzéséhez tartozik, és valaminek a helyi növelése nem változtat rajta.

Olvassa ki, melyik hitelesítési réteg hibázott

Először futtassa az ipsec --version parancsot, mert a strongSwan és a Libreswan eltérő fájlneveket és szintaxist használ, és az egyikre adott tanács árthat a másiknak. Ezután olvassa ki a hiba szakaszát a kliens üzenetéből vagy a démon naplójából: az előre megosztott kulcsra vonatkozó panasz más esemény, mint az elutasított felhasználónév és jelszó.

A PSK az alagút végpontjait hitelesíti. A felhasználónév és a jelszó az L2TP belsejében lévő személyt hitelesíti, és a PPP akkor foglalkozik velük, miután az IPsec-társulás felállt. A helyes PSK rossz fiókkal is meghiúsul, és a fiók cseréje nem javít meg egy kulcsot, amelyet a démon soha nem olvasott helyesen.

Amikor lezárja a jegyet, írja le mind a négyet: a bővítmény verzióját, a használt titokfájlt, hogy a kulcsot újragépelték vagy beillesztették, és a hibában megnevezett réteget. Így aki később megismétli ezt a végigvezetést, egyenesen a működő és a hibázó gép közti különbséghez ugorhat.