LCP Ditamatkan oleh Rakan pada PPTP: Aktifkan MPPE Dahulu

Pautan diautentikasi, klien melaporkan bersambung, dan sesaat kemudian log ditutup dengan LCP ditamatkan oleh rakan. Baris itu datang daripada rundingan PPP di dalam terowong GRE, jadi pengangkutan sudah berfungsi dan kedua-dua hujung tidak bersetuju tentang pilihan pautan. Kata laluan dan alamat pelayan biasanya tidak bersalah di sini. Dasar penyulitan ialah perkara pertama yang perlu dibandingkan, dan pada Linux fail rakan pppd ialah tempat pertama untuk dilihat.

Apa yang dikatakan kegagalan LCP tentang peringkat PPP

PPTP membungkus PPP di dalam GRE: sambungan kawalan TCP 1723 menyediakan panggilan, GRE membawa muatan, dan kemudian LCP merundingkan pilihan seperti protokol pengesahan, pemampatan dan MPPE. Rakan menamatkan LCP apabila pilihan yang diperlukan tidak boleh diterima di sisinya. Log yang mana pertukaran CHAP atau MSCHAPv2 selesai dan LCP tamat serta-merta selepasnya ialah penolakan dasar, bukan kegagalan kebolehcapaian. Jika terowong langsung tidak sampai ke rundingan, periksa pppd dan pemalamnya sebelum membaca baris LCP.

Dua prasyarat mudah terlepas pandang. Binari pppd mesti wujud, dan pemalam PPTP yang dinamakan dalam fail rakan mesti dipasang; pakej yang hilang menamatkan dail sebelum sebarang pilihan dibincangkan.

Aktifkan MPPE di sisi yang memerlukannya

Keputusan sebenar ialah hujung mana yang memiliki dasar penyulitan. Klien boleh menawarkan MPPE, memerlukannya atau menolaknya, dan pelayan membuat pilihan yang sama. Apabila kedua-duanya memerlukannya pautan naik; apabila satu memerlukan dan yang lain menolak, LCP tamat.

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

Muatkan modul dengan modprobe ppp_mppe sebelum mendail, kerana require-mppe-128 gagal tanpanya. Pada Windows kawalan yang setara ialah tab keselamatan entri VPN, di mana klien mesti diberitahu untuk memerlukan penyulitan dan bukannya menerima apa sahaja yang ditawarkan pelayan. Jika pelayan masih menamatkan LCP, tanya pengendalinya sama ada MPPE wajib, pilihan atau dilumpuhkan, kerana klien tidak boleh merundingkan perlindungan yang ditolak pelayan. Mematikan penyulitan supaya mesej itu hilang ialah arah yang salah: ia membuang satu-satunya perlindungan yang dimiliki protokol ini.

Simpan fail rakan yang berfungsi sebelum mengeditnya. Baris require-mppe yang salah taip menghasilkan semula kegagalan LCP generik yang sama dan menghantar anda kembali ke permulaan.

Baca log pppd sendiri, bukan applet

Applet desktop menunjukkan pemutusan dan menyembunyikan sebabnya, jadi baca laporan daemon tentang satu percubaan. Pada sistem systemd mesej masuk ke jurnal; persediaan lama menulis ke fail log tradisional.

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

Cari dalam tetingkap sekitar satu panggilan dan bukan sehari penyambungan semula, supaya pilihan yang ditolak mudah dilihat. pppd biasanya menamakan pilihan dan jawapan rakan, yang memberitahu anda sama ada untuk menukar cadangan sendiri atau meminta pihak pelayan melonggarkan keperluannya. Simpan percubaan dengan cap masa, kerana membandingkan dua log hanya berguna apabila anda tahu baris mana milik panggilan mana. Apabila tiada pertukaran LCP langsung muncul, kesalahan terletak lebih awal dalam rantaian dan MPPE bukan suspeknya.

Kekalkan pembetulan sepanjang penyambungan semula: nama cangkuk dan MTU

Sebaik sahaja pautan kekal, dua butiran menentukan sama ada ia bertahan melalui penyambungan semula. Cangkuk tinggal di /etc/ppp/ip-up.d dan /etc/network/if-up.d, dan kedua-dua direktori diproses oleh run-parts, yang penapis nama failnya menolak apa-apa yang mengandungi titik. Oleh itu skrip bernama set-pptp.sh dilangkau, manakala set-pptp dilaksanakan. Semak nama sebelum menyahpepijat kandungan skrip, kemudian tetapkan MTU yang lebih kecil dari dalam cangkuk itu supaya setiap antara muka ppp baharu mewarisinya tanpa arahan manual.

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

Untuk menamatkan sesi dengan sengaja, sasarkan pid yang direkodkan oleh pppd dan bukannya memadankan nama proses, kerana membunuh semua yang mengandungi ppp turut merobohkan pautan yang tidak berkaitan. PPTP sudah usang dan MS-CHAPv2 lemah, jadi anggap semakan ini sebagai penyelenggaraan pautan yang mesti terus berfungsi, bukan alasan untuk menggunakan PPTP di mana-mana tempat baharu.