Mengapa PPP CHAP sahaja tidak dapat memenuhi keperluan MPPE

Profil PPTP yang menuntut penyulitan biasanya gagal pada titik yang sama: PPP bersetuju dengan pertukaran pengesahan yang tidak pernah menghasilkan bahan kunci yang diperlukan MPPE. Terowong kelihatan separuh hidup, kata laluan diterima, dan pautan terputus sebelum sebarang trafik melaluinya. Mencapai menu lungsur CHAP sehingga sesuatu bersambung menyembunyikan kecacatan sebenar, dan itu ialah kontrak antara kaedah pengesahan dengan dasar perlindungan. Semakan di bawah disusun supaya setiap satu menolak punca yang lebih murah daripada yang berikutnya.

Dua rundingan berjalan dalam satu sambungan PPTP

PPTP membawa sesi PPP biasa di dalam terowong GRE, dan kedua-duanya berunding secara berasingan. Lapisan luar menentukan bagaimana paket dikapsulkan dan saluran kawalan mana yang wujud; sesi PPP dalam menentukan siapa rakan dan perlindungan apa yang menunggang di atasnya. Oleh itu gesaan kata laluan hanya membuktikan sesuatu tentang lapisan dalam, dan jabat tangan luar yang selesai tidak membuktikan apa-apa tentang kedua-duanya. Profil gagal di sini kerana orang menyahpepijat terowong sedangkan perselisihan duduk di dalam PPP.

CHAP biasa ialah pertukaran cabaran-tindak balas dalam RFC 1994, dibina atas rahsia bersama dan tiada yang lain. MS-CHAPv2 ialah pertukaran berbeza dengan mesej berbeza dan output berbeza, diseragamkan dalam RFC 2759. Perkataan bersama dalam kedua-dua nama ialah satu-satunya yang mereka kongsi di atas wayar. Tiada nama yang memberitahu apa yang dihasilkan pertukaran itu, dan itulah satu-satunya bahagian yang penting.

Itulah sebabnya pilihan yang dilabel hanya CHAP adalah kabur dalam profil lama. Apabila pelayan mahu MS-CHAPv2 dan klien menawarkan CHAP biasa, kawalan pautan masih boleh selesai dan kata laluan masih boleh diterima. Kegagalan datang kemudian, apabila pelayan cuba memperoleh kunci perlindungan daripada pertukaran yang tidak menghasilkan apa-apa.

Padankan kaedah yang diperlukan dengan kunci yang boleh dihasilkannya

Kunci MPPE bukan sifat PPP secara umum. Untuk keluarga Microsoft CHAP, terbitan ditentukan dalam RFC 3079, dan ia mengambil sebagai input output pertukaran MS-CHAP dan bukan rahsia bersama. Kaedah EAP sampai ke tempat yang sama melalui laluan berbeza, dengan pelayan pengesahan memulangkan kunci sebagai atribut MS-MPPE-Recv-Key dan MS-MPPE-Send-Key. CHAP biasa tidak muncul dalam mana-mana laluan, dan itulah seluruh sebab ketidakpadanan ini wujud.

Konfigurasi yang menuntut MPPE sambil menolak setiap kaedah yang mampu membekalkan kunci adalah bercanggah secara dalaman. pppd menyelesaikan percanggahan itu dengan menolak pautan, bukan dengan mereka kunci, jadi hasil yang kelihatan ialah sesi yang mengesahkan diri dan kemudian tamat dalam fasa rangkaian. Mencuba semula klien tidak akan mengubahnya selagi pelayan menolak satu-satunya kaedah yang menerbitkan apa-apa.

Peraturan yang menyusul adalah ringkas: jika profil menuntut MPPE, kaedahnya mesti varian MS-CHAP atau kaedah EAP yang kuncinya dipulangkan oleh pelayan. Menolak hanya MS-CHAPv2 tidak menguatkuasakannya, kerana MS-CHAPv1 juga menerbitkan kunci dan kekal tersedia melainkan ditolak secara berasingan; menolak kedua-duanya meninggalkan CHAP biasa dan PAP, yang tidak menerbitkan apa-apa dan menjadikan keperluan itu mustahil dipenuhi. Namakan kaedah yang diterima secara eksplisit daripada menyenaraikan yang anda tidak suka. Melepaskan keperluan penyulitan supaya klien bersambung ialah kemerosotan, bukan pembaikan.

Baca pilihan pelayan sebelum menyunting klien

Kebanyakan ketidakpadanan ini kelihatan pada pelayan dalam dua fail, dan membacanya lebih murah daripada membina semula klien. Pada titik akhir PPTP Linux, tetapan berkaitan tinggal dalam fail pilihan pppd yang disalurkan oleh pptpd. Jalankannya pada pelayan, bukan dari skrin status klien. Mulakan dengan baris yang menuntut, menolak atau menamakan mod perlindungan:

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

Baca output sebagai kontrak dan bukan sebagai senarai bendera. Baris yang menuntut MPPE sambil menolak kedua-dua varian MS-CHAP tidak dapat dipenuhi oleh mana-mana klien, dan keperluan yang hilang untuk kaedah MS-CHAP membiarkan pintu terbuka kepada pertukaran yang tidak memberi kunci. Kemudian semak siapa yang dibenarkan mengesahkan sama sekali, yang ditentukan oleh fail rahsia:

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

Catat tiga nilai sebelum mengubah apa-apa: protokol luar, kaedah pengesahan yang dituntut oleh pelayan, dan sama ada perlindungan itu wajib atau pilihan. Ketiga-tiganya menentukan setiap keputusan kemudian, dan menekanya daripada dialog klien ialah cara profil berakhir separuh dikonfigurasikan. Biarkan fail terbuka semasa bekerja, kerana bahagian seterusnya memerlukan tiga nilai yang sama.

Cari kegagalan mengikut fasa PPP

PPP melaporkan kegagalan dalam fasa, dan fasa itu memberitahu klausa kontrak mana yang patah. Pautan yang tidak pernah meninggalkan kawalan pautan mempunyai masalah pengkapsulan atau rundingan, manakala yang mengesahkan diri lalu mati biasanya mempunyai masalah dasar atau kunci. Pautan yang kekal naik dan tidak membawa apa-apa telah beralih kepada penghalaan, yang merupakan penyiasatan berbeza.

Jurnal menyimpan baris fasa, dan ia lebih berguna daripada tahap nyahpepijat yang lebih tinggi. Minta proses PPP dan mesej perlindungan, kemudian baca hasil pengesahan sebelum apa-apa lagi. Baris terakhir biasanya menamakan klausa yang menolak:

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

Dalam output itu, cari hasil pengesahan dahulu dan kemudian aduan bahawa perlindungan dituntut tetapi tidak dirundingkan. Mesej kedua ialah tandatangan percanggahan di atas, dan berapa kali pun dicuba semula ia tidak menghapuskannya selagi pelayan menolak satu-satunya kaedah yang boleh menghasilkan kunci. Dua perangkap wajar dinamakan: menaikkan tahap nyahpepijat tanpa membaca baris fasa menghasilkan bunyi bising, dan menangkap bahan cabaran atau kata laluan mengubah tugas konfigurasi menjadi kebocoran kelayakan. Rekodkan fasa itu sebelum mengubah mana-mana pilihan.

Rancang jalan keluar sebelum titik akhir lama dimatikan

MPPE ialah mekanisme perlindungan pautan yang bersejarah, dan kehadirannya tidak menjadikan PPTP pilihan yang wajar untuk penggunaan baharu. Panduan Microsoft semasa sudah menasihati menentang PPTP dan menentang L2TP/IPsec dengan kunci pra-kongsi untuk penggunaan akses jauh baharu. Mengekalkan titik akhir lama hidup ialah keputusan tentang perkhidmatan sedia ada, bukan templat untuk yang seterusnya.

Apabila titik akhir mesti kekal, tuliskan kontrak: protokol luar, kaedah pengesahan yang diperlukan, perlindungan wajib dan versi klien yang merundingkannya. Apabila ia boleh pergi, pilih identiti get laluan pengganti, pengesahan kliennya dan tempat kelayakan akan tinggal sebelum menyentuh profil lama. Kemudian rancang laluan, DNS dan sumber yang setiap pengguna dibenarkan mencapai. Sahkan klien yang dimaksudkan terhadap keperluan pemilik dan bukan terhadap sambungan yang berfungsi.

Penolakan yang disengajakan harus kekal sebagai penolakan, kerana kembali kepada mod tanpa perlindungan supaya ujian lulus mengubah kegagalan dasar menjadi pendedahan. Keadaan siap ialah kontrak yang disokong dan didokumenkan, bukan set perubahan terkecil yang membuatkan satu sambungan lama berjaya. Biarkan profil lama di tempatnya, tidak digunakan dan didokumenkan, sehingga pengganti lulus semakan yang sama.