A kapcsolat hitelesít, a kliens jelzi, hogy csatlakozott, és egy másodperccel később a napló azzal zárul, hogy az LCP-t a partner bontotta. Ez a sor a GRE-alagúton belüli PPP-tárgyalásból származik, tehát az átvitel már működött, és a két vég nem értett egyet a kapcsolat beállításaiban. A jelszavak és a kiszolgálócímek itt általában ártatlanok. A titkosítási szabályzat az első összehasonlítandó dolog, Linuxon pedig a pppd partnerfájlja az első hely, ahol érdemes megnézni.

Mit mond az LCP-hiba a PPP-szakaszról

A PPTP PPP-t csomagol GRE-be: a TCP 1723 vezérlőkapcsolat felépíti a hívást, a GRE szállítja a hasznos terhet, majd az LCP olyan beállításokról tárgyal, mint a hitelesítési protokoll, a tömörítés és az MPPE. A partner akkor bontja az LCP-t, ha egy kötelező beállítás az ő oldalán nem elfogadható. Az a napló, amelyben a CHAP- vagy MSCHAPv2-csere befejeződik, és az LCP közvetlenül utána véget ér, szabályzatelutasítás, nem elérhetőségi hiba. Ha az alagút egyáltalán nem jut el a tárgyalásig, vizsgálja meg a pppd-t és a bővítményét, mielőtt elolvassa az LCP-sort.

Két előfeltétel könnyen elkerüli a figyelmet. A pppd binárisnak léteznie kell, és a partnerfájlban megnevezett PPTP-bővítménynek telepítve kell lennie; egy hiányzó csomag még azelőtt befejezi a tárcsázást, hogy bármilyen beállítást megbeszélnének.

Engedélyezze az MPPE-t azon az oldalon, amelyik megköveteli

A valódi döntés az, melyik vég birtokolja a titkosítási szabályzatot. A kliens felajánlhatja, megkövetelheti vagy elutasíthatja az MPPE-t, és a kiszolgáló ugyanezt választja. Amikor mindkettő megköveteli, a kapcsolat létrejön; amikor az egyik megköveteli, a másik pedig elutasítja, az LCP véget ér.

pty "pptp vpn.example.net --nolaunchpppd"
name alice
remotename PPTP
require-mppe-128

Töltse be a modult a modprobe ppp_mppe segítségével tárcsázás előtt, mert nélküle a require-mppe-128 meghiúsul. Windows alatt a megfelelő vezérlő a VPN-bejegyzés biztonsági lapja, ahol a kliensnek meg kell parancsolni, hogy titkosítást követeljen, ne pedig elfogadja, amit a kiszolgáló kínál. Ha a kiszolgáló továbbra is bontja az LCP-t, kérdezze meg az üzemeltetőjét, hogy az MPPE kötelező, választható vagy letiltott, mert a kliens nem tárgyalhat olyan védelmet, amelyet a kiszolgáló elutasít. A titkosítás kikapcsolása, hogy eltűnjön az üzenet, rossz irány: eltávolítja az egyetlen védelmet, amellyel ez a protokoll rendelkezik.

A szerkesztés előtt mentse el a működő partnerfájlt. Egy elgépelt require-mppe sor ugyanazt az általános LCP-hibát idézi elő, és visszaküldi a kezdetekhez.

A pppd saját naplóját olvassa, ne az appletét

Az asztali appletek megmutatják a bontást, de elrejtik az okot, ezért olvassa el a démon beszámolóját egyetlen kísérletről. systemd-rendszereken az üzenet a journalba kerül; a régebbi beállítások a hagyományos naplófájlokba írnak.

journalctl --since "10 min ago" | grep -i -E "pppd|lcp|mppe"
tail -n 50 /var/log/syslog

Egyetlen hívás körüli ablakban keressen, ne egy egész nap visszacsatlakozásaiban, hogy a visszautasított beállítás könnyen felismerhető legyen. A pppd általában megnevezi a beállítást és a partner válaszát, ami megmondja, hogy a saját javaslatát módosítsa-e, vagy a kiszolgáló oldalát kérje meg a követelmény enyhítésére. Tartsa időbélyeggel a kísérleteket, mert két napló összehasonlítása csak akkor hasznos, ha tudja, mely sorok melyik híváshoz tartoznak. Ha egyáltalán nem jelenik meg LCP-csere, a hiba korábban van a láncban, és az MPPE nem gyanús.

Őrizze meg a javítást újracsatlakozásokon át: hooknevek és MTU

Amint a kapcsolat állva marad, két részlet dönti el, hogy túlél-e egy újracsatlakozást. A hookok a /etc/ppp/ip-up.d és a /etc/network/if-up.d könyvtárban élnek, és mindkettőt a run-parts dolgozza fel, amelynek fájlnévszűrője elutasít mindent, ami pontot tartalmaz. Ezért a set-pptp.sh nevű szkript kimarad, míg a set-pptp végrehajtódik. Ellenőrizze a nevet, mielőtt a szkript tartalmát hibakeresné, majd állítsa be a kisebb MTU-t azon hook belsejéből, hogy minden új ppp-interfész kézi parancs nélkül örökölje.

run-parts --test /etc/ppp/ip-up.d
ip link set dev ppp0 mtu 1200

Ha szándékosan be akar fejezni egy munkamenetet, a pppd által rögzített pid-et célozza meg, ne a folyamatneveket illessze mintára, mert minden ppp-t tartalmazó dolog megölése a nem kapcsolódó kapcsolatokat is leszakítja. A PPTP elavult, az MS-CHAPv2 pedig gyenge, ezért tekintse ezeket az ellenőrzéseket egy továbbra is működnie kellő kapcsolat karbantartásának, nem pedig a PPTP új helyen való bevezetése indokának.

Kapcsolódó cikkek