PPTP'de LCP eş tarafından sonlandırıldı: önce MPPE'yi etkinleştirin

Bağlantı kimlik doğrulamasından geçer, istemci bağlı olduğunu bildirir ve bir saniye sonra günlük LCP eş tarafından sonlandırıldı diyerek kapanır. Bu satır GRE tünelinin içindeki PPP görüşmesinden gelir, yani taşıma zaten çalışıyordu ve iki uç bağlantı seçeneklerinde anlaşamadı. Parolalar ve sunucu adresleri burada genellikle suçsuzdur. Önce karşılaştırılması gereken şey şifreleme ilkesidir ve Linux'ta pppd'nin eş dosyası ilk bakılacak yerdir.

LCP hatası PPP aşaması hakkında ne söyler

PPTP, PPP'yi GRE içine sarar: TCP 1723 denetim bağlantısı çağrıyı kurar, GRE yükü taşır ve ardından LCP kimlik doğrulama protokolü, sıkıştırma ve MPPE gibi seçenekleri görüşür. Gerekli bir seçenek kendi tarafında kabul edilemez olduğunda eş LCP'yi sonlandırır. CHAP veya MSCHAPv2 alışverişinin tamamlandığı ve hemen ardından LCP'nin bittiği bir günlük, ilke reddidir, erişilebilirlik hatası değildir. Tünel görüşmeye hiç ulaşmıyorsa, LCP satırını okumadan önce pppd'yi ve eklentisini inceleyin.

İki ön koşul kolayca gözden kaçar. pppd ikili dosyası bulunmalı ve eş dosyasında adı geçen PPTP eklentisi kurulu olmalıdır; eksik paket, herhangi bir seçenek tartışılmadan çağrıyı bitirir.

MPPE'yi bunu gerektiren tarafta etkinleştirin

Gerçek karar, şifreleme ilkesinin hangi uçta olduğudur. İstemci MPPE önerebilir, talep edebilir veya reddedebilir ve sunucu da aynı seçimi yapar. İkisi de talep ederse bağlantı kalkar; biri talep edip diğeri reddederse LCP biter.

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

Aramadan önce modülü modprobe ppp_mppe ile yükleyin, çünkü o olmadan require-mppe-128 başarısız olur. Windows'ta eşdeğer denetim VPN girdisinin güvenlik sekmesidir; istemciye sunucunun sunduğunu kabul etmek yerine şifrelemeyi talep etmesi söylenmelidir. Sunucu hâlâ LCP'yi sonlandırıyorsa, MPPE'nin zorunlu, isteğe bağlı mı yoksa devre dışı mı olduğunu işletmecisine sorun, çünkü istemci sunucunun reddettiği bir korumayı görüşemez. Mesaj kaybolsun diye şifrelemeyi kapatmak yanlış yöndür: bu protokolün sahip olduğu tek korumayı kaldırır.

Düzenlemeden önce çalışan eş dosyasını kaydedin. Yanlış yazılmış require-mppe satırı aynı genel LCP hatasını yeniden üretir ve sizi başa döndürür.

Applet yerine pppd'nin kendi günlüğünü okuyun

Masaüstü appletleri bağlantı kesilmesini gösterir ve nedeni gizler, bu yüzden daemonun tek bir denemeye ilişkin anlatımını okuyun. systemd sistemlerinde mesaj journal'a gider; daha eski kurulumlar geleneksel günlük dosyalarına yazar.

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

Bütün bir gün yeniden bağlanma yerine tek bir arama çevresindeki pencerede arayın, böylece reddedilen seçenek kolayca görülür. pppd genellikle seçeneği ve eşin yanıtını belirtir; bu, kendi önerinizi değiştirmeniz mi yoksa sunucu tarafından gereksinimi yumuşatmasını istemeniz mi gerektiğini söyler. Denemeleri zaman damgalı tutun, çünkü iki günlüğü karşılaştırmak ancak hangi satırların hangi çağrıya ait olduğunu bildiğinizde yararlıdır. Hiç LCP alışverişi görünmüyorsa, arıza zincirde daha önededir ve MPPE şüpheli değildir.

Düzeltmeyi yeniden bağlanmalar boyunca koruyun: kanca adları ve MTU

Bağlantı ayakta kaldığında, iki ayrıntı yeniden bağlanmayı atlatıp atlatmayacağını belirler. Kancalar /etc/ppp/ip-up.d ve /etc/network/if-up.d içinde yaşar ve her iki dizin de run-parts tarafından işlenir; onun dosya adı süzgeci nokta içeren her şeyi reddeder. Bu yüzden set-pptp.sh adlı betik atlanır, set-pptp ise çalıştırılır. Betiğin içeriğinde hata ayıklamadan önce adı denetleyin, sonra aynı kancanın içinden daha küçük MTU'yu ayarlayın; böylece her yeni ppp arayüzü onu elle komut olmadan devralır.

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

Bir oturumu bilerek bitirmek için süreç adlarını desenle eşleştirmek yerine pppd'nin kaydettiği pid'i hedefleyin, çünkü ppp içeren her şeyi öldürmek ilgisiz bağlantıları da koparır. PPTP kullanımdan kalkmıştır ve MS-CHAPv2 zayıftır, bu yüzden bu denetimleri çalışmaya devam etmesi gereken bir bağlantının bakımı olarak görün, PPTP'yi yeni bir yere kurma gerekçesi olarak değil.