Mengapa PPP CHAP saja tidak dapat memenuhi persyaratan MPPE

Profil PPTP yang menuntut enkripsi biasanya gagal di titik yang sama: PPP menyepakati pertukaran autentikasi yang tidak pernah menghasilkan materi kunci yang dibutuhkan MPPE. Terowongan tampak setengah hidup, kata sandi diterima, dan tautan putus sebelum ada lalu lintas yang melintasinya. Meraih daftar turun CHAP sampai sesuatu terhubung menyembunyikan cacat sebenarnya, dan itu adalah kontrak antara metode autentikasi dan kebijakan perlindungan. Pemeriksaan di bawah disusun agar masing-masing menyingkirkan penyebab yang lebih murah daripada berikutnya.

Dua negosiasi berjalan di dalam satu koneksi PPTP

PPTP membawa sesi PPP normal di dalam terowongan GRE, dan keduanya bernegosiasi secara terpisah. Lapisan luar memutuskan bagaimana paket dienkapsulasi dan kanal kendali mana yang ada; sesi PPP dalam memutuskan siapa mitranya dan perlindungan apa yang menumpang di atasnya. Karena itu permintaan kata sandi hanya membuktikan sesuatu tentang lapisan dalam, dan jabat tangan luar yang selesai tidak membuktikan apa pun tentang keduanya. Profil gagal di sini karena orang men-debug terowongan sementara ketidaksepakatan duduk di dalam PPP.

CHAP biasa adalah pertukaran tantangan-tanggapan dalam RFC 1994, dibangun di atas rahasia bersama dan tidak ada yang lain. MS-CHAPv2 adalah pertukaran berbeda dengan pesan berbeda dan keluaran berbeda, distandarkan dalam RFC 2759. Kata bersama pada kedua nama adalah satu-satunya yang mereka punya bersama di kabel. Tidak ada nama yang memberi tahu apa yang dihasilkan pertukaran itu, dan hanya bagian itulah yang penting.

Itulah sebabnya opsi yang hanya diberi label CHAP bersifat ambigu pada profil lama. Ketika server menginginkan MS-CHAPv2 dan klien menawarkan CHAP biasa, kendali tautan masih dapat selesai dan kata sandi masih dapat diterima. Kegagalan datang kemudian, saat server mencoba menurunkan kunci perlindungan dari pertukaran yang tidak menghasilkan apa pun.

Cocokkan metode yang diwajibkan dengan kunci yang dapat dihasilkannya

Kunci MPPE bukanlah sifat PPP secara umum. Untuk keluarga Microsoft CHAP penurunannya ditetapkan dalam RFC 3079, dan itu mengambil sebagai masukan keluaran pertukaran MS-CHAP, bukan rahasia bersama. Metode EAP mencapai tempat yang sama melalui jalur berbeda, dengan server autentikasi mengembalikan kunci sebagai atribut MS-MPPE-Recv-Key dan MS-MPPE-Send-Key. CHAP biasa tidak muncul di kedua jalur itu, dan itulah seluruh alasan ketidakcocokan ini ada.

Konfigurasi yang mewajibkan MPPE sekaligus menolak setiap metode yang mampu memasok kunci bertentangan secara internal. pppd menyelesaikan pertentangan itu dengan menolak tautan, bukan dengan mengarang kunci, sehingga hasil yang terlihat adalah sesi yang terautentikasi lalu berakhir pada fase jaringan. Mencoba ulang klien tidak akan mengubahnya selama server menolak satu-satunya metode yang menurunkan sesuatu.

Aturan yang mengikutinya singkat: jika profil mewajibkan MPPE, metodenya harus varian MS-CHAP atau metode EAP yang kuncinya dikembalikan server. Menolak hanya MS-CHAPv2 tidak menegakkan itu, karena MS-CHAPv1 juga menurunkan kunci dan tetap tersedia kecuali ditolak secara terpisah; menolak keduanya menyisakan CHAP biasa dan PAP, yang tidak menurunkan apa pun dan membuat persyaratan itu mustahil dipenuhi. Sebutkan metode yang diterima secara eksplisit alih-alih mendaftar yang tidak Anda sukai. Melepas persyaratan enkripsi agar klien terhubung adalah penurunan mutu, bukan perbaikan.

Baca opsi server sebelum menyunting klien

Sebagian besar ketidakcocokan ini terlihat di server dalam dua berkas, dan membacanya lebih murah daripada membangun ulang klien. Pada titik akhir PPTP Linux, pengaturan yang relevan berada di berkas opsi pppd yang diteruskan pptpd. Jalankan di server, bukan dari layar status klien. Mulailah dari baris yang mewajibkan, menolak, atau menamai mode perlindungan:

sudo grep -nE 'require-|refuse-|mppe|mschap' /etc/ppp/options.pptpd

Baca keluarannya sebagai kontrak, bukan sebagai daftar tanda. Baris yang mewajibkan MPPE sekaligus menolak kedua varian MS-CHAP tidak dapat dipenuhi klien mana pun, dan persyaratan yang hilang untuk metode MS-CHAP membiarkan pintu terbuka bagi pertukaran yang tidak memberi kunci. Lalu periksa siapa yang boleh mengautentikasi sama sekali, yang diputuskan berkas rahasia:

sudo sed -n '1,20p' /etc/ppp/chap-secrets
sudo pppd --version

Catat tiga nilai sebelum mengubah apa pun: protokol luar, metode autentikasi yang diwajibkan server, dan apakah perlindungan bersifat wajib atau opsional. Ketiganya menentukan setiap keputusan berikutnya, dan menebaknya dari dialog klien adalah cara sebuah profil berakhir setengah terkonfigurasi. Biarkan berkas tetap terbuka selama bekerja, karena bagian berikutnya membutuhkan tiga nilai yang sama.

Temukan kegagalan menurut fase PPP

PPP melaporkan kegagalan dalam fase, dan fasenya memberi tahu klausul kontrak mana yang rusak. Tautan yang tidak pernah meninggalkan kendali tautan punya masalah enkapsulasi atau negosiasi, sedangkan yang terautentikasi lalu mati biasanya punya masalah kebijakan atau kunci. Tautan yang tetap hidup dan tidak membawa apa pun telah beralih ke perutean, yang merupakan penyelidikan berbeda.

Jurnal menyimpan baris fase, dan itu lebih berguna daripada tingkat debug yang lebih tinggi. Minta proses PPP dan pesan perlindungan, lalu baca hasil autentikasi sebelum yang lain. Baris terakhir biasanya menyebut klausul yang menolak:

sudo journalctl -b --no-pager | grep -iE 'pppd|pptpd|mppe|chap' | tail -40

Dalam keluaran itu, cari hasil autentikasi lebih dulu lalu keluhan bahwa perlindungan diwajibkan tetapi tidak dinegosiasikan. Pesan kedua adalah tanda tangan dari pertentangan di atas, dan berapa pun percobaan ulang tidak menghapusnya selama server menolak satu-satunya metode yang dapat menghasilkan kunci. Dua jebakan layak disebut: menaikkan tingkat debug tanpa membaca baris fase menghasilkan kebisingan, dan menangkap materi tantangan atau kata sandi mengubah tugas konfigurasi menjadi kebocoran kredensial. Catat fase itu sebelum mengubah opsi apa pun.

Rencanakan jalan keluar sebelum titik akhir lama dimatikan

MPPE adalah mekanisme perlindungan tautan yang historis, dan keberadaannya tidak menjadikan PPTP pilihan yang masuk akal untuk penerapan baru. Panduan Microsoft saat ini sudah menyarankan agar tidak memakai PPTP dan tidak memakai L2TP/IPsec dengan kunci yang dibagikan sebelumnya untuk peluncuran akses jarak jauh baru. Menjaga titik akhir lama tetap hidup adalah keputusan tentang layanan yang sudah ada, bukan templat untuk yang berikutnya.

Ketika titik akhir harus tetap ada, tuliskan kontraknya: protokol luar, metode autentikasi yang diwajibkan, perlindungan wajib, dan versi klien yang menegosiasikannya. Ketika bisa pergi, pilih identitas gateway pengganti, autentikasi kliennya, dan tempat kredensial akan tinggal sebelum menyentuh profil lama. Lalu rencanakan rute, DNS, dan sumber daya yang berhak diakses setiap pengguna. Validasi klien yang dimaksud terhadap persyaratan pemilik, bukan terhadap koneksi yang berfungsi.

Penolakan yang disengaja harus tetap menjadi penolakan, karena kembali ke mode tanpa perlindungan agar pengujian lulus mengubah kegagalan kebijakan menjadi paparan. Keadaan akhir adalah kontrak yang didukung dan terdokumentasi, bukan kumpulan perubahan terkecil yang membuat satu koneksi lama berhasil. Biarkan profil lama di tempatnya, tidak terpakai dan terdokumentasi, sampai penggantinya lulus pemeriksaan yang sama.