LCP Dihentikan oleh Peer pada PPTP: Aktifkan MPPE Lebih Dulu

Tautan berhasil diautentikasi, klien melaporkan terhubung, dan satu detik kemudian log ditutup dengan LCP dihentikan oleh peer. Baris itu berasal dari negosiasi PPP di dalam terowongan GRE, jadi transportnya sudah bekerja dan kedua ujung tidak sepakat soal opsi tautan. Kata sandi dan alamat server biasanya tidak bersalah di sini. Kebijakan enkripsi adalah hal pertama yang harus dibandingkan, dan di Linux berkas peer pppd adalah tempat pertama yang harus dilihat.

Apa yang dikatakan kegagalan LCP tentang tahap PPP

PPTP membungkus PPP di dalam GRE: koneksi kontrol TCP 1723 menyiapkan panggilan, GRE membawa muatan, lalu LCP menegosiasikan opsi seperti protokol autentikasi, kompresi, dan MPPE. Peer menghentikan LCP saat opsi yang diwajibkan tidak dapat diterima di sisinya. Log tempat pertukaran CHAP atau MSCHAPv2 selesai dan LCP berakhir tepat sesudahnya adalah penolakan kebijakan, bukan kegagalan keterjangkauan. Jika terowongan sama sekali tidak mencapai negosiasi, periksa pppd dan plugin-nya sebelum membaca baris LCP.

Dua prasyarat mudah terlewat. Biner pppd harus ada, dan plugin PPTP yang disebut di berkas peer harus terpasang; paket yang hilang mengakhiri panggilan sebelum opsi apa pun dibahas.

Aktifkan MPPE di sisi yang mewajibkannya

Keputusan sebenarnya adalah ujung mana yang memegang kebijakan enkripsi. Klien dapat menawarkan MPPE, mewajibkannya, atau menolaknya, dan server membuat pilihan yang sama. Bila keduanya mewajibkan, tautan naik; bila satu mewajibkan dan yang lain menolak, LCP berakhir.

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

Muat modul dengan modprobe ppp_mppe sebelum memanggil, karena require-mppe-128 gagal tanpanya. Di Windows kendali yang setara adalah tab keamanan entri VPN, tempat klien harus diberi tahu untuk mewajibkan enkripsi alih-alih menerima apa pun yang ditawarkan server. Jika server masih menghentikan LCP, tanyakan kepada operatornya apakah MPPE wajib, opsional, atau nonaktif, karena klien tidak dapat menegosiasikan perlindungan yang ditolak server. Mematikan enkripsi agar pesan itu hilang adalah arah yang salah: itu menghapus satu-satunya perlindungan yang dimiliki protokol ini.

Simpan berkas peer yang berfungsi sebelum mengeditnya. Baris require-mppe yang salah ketik mereproduksi kegagalan LCP generik yang sama dan mengembalikan Anda ke awal.

Baca log pppd sendiri, bukan applet

Applet desktop menampilkan pemutusan dan menyembunyikan alasannya, jadi bacalah laporan daemon tentang satu percobaan. Di sistem systemd pesan masuk ke journal; penyiapan lama menulis ke berkas log tradisional.

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

Telusuri jendela di sekitar satu panggilan, bukan seharian penyambungan ulang, agar opsi yang ditolak mudah terlihat. pppd biasanya menyebutkan opsi dan jawaban peer, yang memberi tahu Anda apakah harus mengubah usulan sendiri atau meminta sisi server melonggarkan persyaratannya. Simpan percobaan dengan cap waktu, karena membandingkan dua log hanya berguna bila Anda tahu baris mana milik panggilan mana. Bila tidak ada pertukaran LCP sama sekali, kesalahannya ada lebih awal di rantai dan MPPE bukan tersangkanya.

Pertahankan perbaikan saat menyambung ulang: nama hook dan MTU

Setelah tautan bertahan, dua detail menentukan apakah ia selamat dari penyambungan ulang. Hook berada di /etc/ppp/ip-up.d dan /etc/network/if-up.d, dan kedua direktori diproses oleh run-parts, yang filternya menolak nama apa pun yang mengandung titik. Karena itu skrip bernama set-pptp.sh dilewati, sedangkan set-pptp dieksekusi. Periksa namanya sebelum menelusuri isi skrip, lalu atur MTU yang lebih kecil dari dalam hook itu agar setiap antarmuka ppp baru mewarisinya tanpa perintah manual.

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

Untuk mengakhiri sesi dengan sengaja, targetkan pid yang dicatat pppd alih-alih mencocokkan nama proses, karena membunuh semua yang mengandung ppp juga merobohkan tautan yang tidak terkait. PPTP sudah usang dan MS-CHAPv2 lemah, jadi perlakukan pemeriksaan ini sebagai perawatan tautan yang harus tetap berfungsi, bukan alasan menempatkan PPTP di tempat baru mana pun.