Üres az L2TP hibakeresési napló? A hiba valószínűleg a journalban van

Elindítja az L2TP segédprogramot hibakereséssel, nézi a terminált, és az semmi hasznos nélkül leáll a képernyőn. Ez nem hibás hibakeresési kapcsoló. Egy NetworkManager L2TP kapcsolat négy együttműködő folyamat, és közülük csak néhány ír abba a terminálba, amelyet néz. A többi bizonyíték a journalban van, egy szűrőnyire.

Négy folyamat, két naplócél

A kapcsolat az IPsec-kel indul, amely a telepítéstől függően libreswan vagy strongSwan. Ezután az L2TP daemon, hagyományosan xl2tpd, néhány buildben kl2tpd, viszi a tunnelt. Végül a pppd kezeli a hitelesítést és a címzést benne.

A segédszolgáltatás összehangolja ezeket a részeket, és kiírja a saját előrehaladását. Az IPsec daemon és a pppd általában a rendszerjournalon keresztül jelent, ezért a terminál sikertelen kapcsolatot mutat, miközben az ok egy olyan fájlban van, amelyet nem nyitott meg.

Ez a szétválás azt is megmagyarázza, miért néz ki egyformán a PSK-hiba és a jelszóhiba az asztalról: mindkettő általános bontást okoz, és a sikertelen szakasz csak az egyes folyamatok kimenetében látszik. Pontosan ezért számít itt a journal. Egy általános üzenet az asztalon, négy lehetséges szerző mögötte.

Gyűjtsön össze egy kísérletet, aztán olvassa el a sorrendet

Reprodukálja egyszer, ismert profillal és ismert időponttal, majd egy szűk ablakot olvasson a teljes indítás helyett. A kísérletek ismétlése a beállítások módosítása közben olyan keverékké teszi a naplót, amely nem értelmezhető.

Ezek a parancsok kiválasztják az aktuális indítás résztvevő folyamatait, és érdemes megerősíteni a bővítmény útvonalát a disztribúcióján:

journalctl -b --no-hostname _COMM=nm-l2tp-service _COMM=pluto _COMM=charon _COMM=xl2tpd _COMM=pppd
rpm -ql NetworkManager-l2tp 2>/dev/null | grep nm-l2tp-service

Az egy hívásban ismételt mezők e folyamatok unióját választják, ami időrendben tartja a sorrendet. Debian-alapú rendszeren az egyenértékű lekérdezés a dpkg -L; a lényeg, hogy megtalálja, hol él valójában a segédprogram, mielőtt kézzel próbálja futtatni.

Három feltétel dönti el a következő lépést

Olvassa el az első sikertelen szakaszt, majd ennek megfelelően válasszon. Ha az IPsec javaslat- vagy partnerhitelesítési hibát jelent, a tunnel soha nem jött létre, és a PPP-jelszó módosítása nem segíthet.

Ha a tunnel létrejött, és a pppd elutasította a bejelentkezést, a megosztott titok már rendben volt, és a hitelesítőadat-probléma egy szinttel feljebb van. Ha a pppd címről tárgyalt, és a hiba később jelenik meg, mindkettő működik, és a fennmaradó probléma az útválasztás, a DNS vagy a szerver saját szabályzata.

Ez a három ág szinte minden általános bontást lefed, és azt dönti el őket, melyik folyamat naplózta az utolsó hibát, nem az, melyik hibaüzenet tűnik a legriasztóbbnak.

Érdemes azt is megerősíteni, melyik IPsec-háttér van telepítve, mielőtt hozzányúl egy hibakeresési beállításhoz. A strongSwanhoz írt naplózási opció semmit nem tesz, ha libreswan fut, és a kapcsolat ugyanott fog elakadni, miközben egy olyan fájlt szerkeszt, amelyet senki nem olvas.

A hibakeresési mód fájlokat hagy maga után

Az eredeti hibakeresési munkafolyamat kézzel indítja a szolgáltatást hibakeresési kapcsolóval, és ez a mód a kapcsolat végén hátrahagyhatja a generált futásidejű konfigurációs fájlokat.

Ezek a fájlok hitelesítési anyagot tartalmaznak: az előre megosztott kulcsot, hitelesítő adatokat vagy mindkettőt. A csevegőablakba másolt generált konfiguráció hitelesítő adatok felfedése, nem naplórészlet. Távolítsa el a titkos sorokat, mielőtt bármit megoszt, és törölje a könyvtárat, amikor a vizsgálat véget ér. Kezelje őket titokként, nyerje ki a jelentéshez szükséges konkrét sorokat, és utána törölje őket, ahelyett hogy egy könyvtárat illesztene be egy jegybe.

A kézi példányt is össze kell hangolni a normálissal. Ha hibakeresési másolatot indít, miközben a szolgáltatás már birtokolja a bővítményt, két tulajdonos és mindkettőt keverő napló keletkezik, ami rosszabb, mint a hibakeresési kimenet teljes hiánya.

Ezután állítsa vissza a normál segédprogramot

Amikor a vizsgálat véget ér, állítsa le a kézi példányt, távolítsa el a megtartott futásidejű fájlokat, és kapcsolódjon újra a normál úton, hogy a következő ember a valóságnak megfelelő konfigurációt lásson.

Ezután a sikertelen rétegben ellenőrizze az eredményt, nem az asztali ikonnál:

journalctl -b -u NetworkManager --since -10min | tail -30
ip -4 addr show ppp0
ip -4 route get 10.20.4.10

Egy munkamenet, amely hitelesít, címet kap és a szándékolt cél felé irányít, az az eredmény, amelyet hibakeresett. Egy csendes terminál egy sikertelen kísérlet alatt csak azt mondja meg, hogy hová nem íródott ki a kimenet.