Kegagalan penulisan GRE di pptpd bukan masalah kata sandi

Kegagalan penulisan GRE di log, dan naluri pertama adalah mengatur ulang kata sandi pengguna. Naluri itu hampir selalu salah. Pesan-pesan ini menjelaskan jalur data, bukan pemeriksaan kredensial: klien mungkin berhasil diautentikasi lalu macet pada tahap ketika ia mendaftar di jaringan. Dua pesan berbeda menunjuk dua kegagalan berbeda, dan tidak satu pun terpecahkan oleh kata sandi baru.

Dua pesan, dua kegagalan berbeda

Kegagalan baca berarti paket GRE tidak pernah mencapai daemon, atau dibuang saat masuk. Koneksi kontrol bisa tampak sepenuhnya sehat sementara tidak ada yang melintasi jalur data. Autentikasi adalah satu-satunya hal yang terbukti berhasil.

Kegagalan tulis biasanya berarti sesi menegosiasikan sesuatu yang tidak dapat digunakan kernel atau klien. Kanal kontrol selesai, dan opsi yang disepakati selama pertukaran itu tidak cocok dengan apa yang benar-benar dapat dilakukan titik akhir. Itu perselisihan konfigurasi, bukan peristiwa autentikasi.

Baca mana dari keduanya yang muncul sebelum mengubah apa pun. Keduanya mengarah ke lapisan berbeda, dan memperlakukannya sebagai satu gejala adalah alasan server yang sama ditambal dua kali karena alasan tak terkait. Baris log adalah satu-satunya diagnostik gratis yang Anda dapatkan.

Protokol 47 bukan port 47

PPTP memakai TCP 1723 untuk menyiapkan panggilan dan GRE untuk membawa muatan. GRE adalah protokol IP 47, bukan nomor port, jadi aturan firewall yang membuka port 47 tidak mengizinkan apa pun yang berguna.

Router di jalur membutuhkan fitur passthrough PPTP atau izin GRE eksplisit. Tanpanya, jabat tangan TCP selesai dan terowongan tidak pernah membawa paket, yang menghasilkan tepat kegagalan baca di atas. Aturan port 47 di firewall adalah sore yang paling sering terbuang dalam protokol ini.

Pantau kedua arah sekaligus di server alih-alih menebak sisi mana yang membuang lalu lintas: tcpdump -ni any port 1723 or proto gre.

Jika 1723 menunjukkan penyiapan panggilan sementara GRE tetap diam, pemblokiran berada di atas host. Jika GRE datang dan daemon masih gagal, masalahnya lokal dan opsi adalah tempat berikutnya untuk dilihat.

Izinkan GRE di tempat host benar-benar meneruskan

Menyisipkan aturan forward untuk GRE adalah uji yang wajar pada host yang meneruskan lalu lintas terowongan, dan itu bukan kebijakan. Aturan uji yang menerima semua dari satu protokol adalah diagnostik, bukan desain. Biarkan cukup lama untuk mempelajari sesuatu, lalu ganti dengan aturan terbatas.

Tambahkan aturan input untuk paket yang dialamatkan ke server itu sendiri, karena rantai forward tidak melihatnya. Lalu lihat penghitung aturan sebelum dan sesudah percobaan koneksi, yang memberi tahu Anda apakah paket benar-benar datang.

Buat aturan tetap melalui layanan firewall distribusi alih-alih menjalankannya lagi setelah setiap reboot. Pada host nftables, cocokkan ip protocol gre di rantai input dan rantai forward.

Pastikan modul ppp_generic juga dimuat, dan periksa apakah pelacakan koneksi membuang arah kembali. Keduanya menghasilkan kegagalan yang tampak seperti masalah firewall dan bukan. Modul kernel yang hilang tampak persis seperti protokol yang diblokir sampai Anda memeriksanya.

Cocokkan opsi dengan klien yang benar-benar Anda miliki

Perbaikan dari laporan lain ada di /etc/ppp/pptpd-options, tempat resep menolak PAP, CHAP, dan MSCHAP, mengomentari baris require yang sesuai, dan mempertahankan MPPE stateful. Resep itu ditulis untuk satu campuran klien, dan menyalinnya secara buta merusak kasus umum. Baca baris penolakan sebagai pernyataan tentang klien yang dimiliki penulis, bukan sebagai rekomendasi.

Klien Windows biasanya membutuhkan MS-CHAPv2 dengan MPPE-128. Pertahankan persyaratan itu dan hapus hanya opsi yang benar-benar tidak dapat dinegosiasikan klien.

# keep encryption; drop only what this client cannot negotiate
refuse-pap
refuse-chap
refuse-mschap
mppe-stateful
require-mschap-v2
require-mppe-128

Mematikan enkripsi agar koneksi berhasil adalah penurunan, bukan perbaikan. Uji varian seperti itu pada tautan laboratorium, lalu pulihkan enkripsi sebelum layanan menghadapi klien nyata. Koneksi yang bekerja secara tidak aman lebih buruk daripada yang gagal dengan jujur.

Baca nomor kesalahan klien

Kode numerik klien mempersempit tahap lebih cepat daripada log server. Baca sebelum membaca apa pun yang lain. 691 berarti kredensial ditolak, 721 berarti server tidak pernah menjawab, dan 619 berarti koneksi terputus. Dua menit dengan nomor itu menghemat satu jam dengan konfigurasi.

Bandingkan kode itu dengan log server sebelum mengedit apa pun, dan uji ulang dengan klien yang sama setelah setiap perubahan. Jika tidak, kegagalan kedua bersembunyi di balik yang pertama dan perbaikan tampak tidak efektif.

Ketika login berhasil dan tidak ada lalu lintas yang bergerak, GRE tetap menjadi tersangka. Itulah saatnya kembali ke tangkapan, bukan ke penyimpanan kredensial.