PPTP terhubung lalu macet di belakang Linux NAT: helper GRE

Seseorang meneruskan 1723, klien mencapai server, autentikasi dimulai, lalu semuanya berhenti tanpa kesalahan. Kesimpulan alaminya adalah kata sandi salah, jadi kata sandi diketik ulang tiga kali. Penerusan itu baik-baik saja dan kredensialnya juga baik-baik saja. Yang rusak adalah protokol kedua yang tidak pernah dicakup penerusan itu, dan nilai bawaan kernel yang diam-diam berhenti membantu dengan protokol tersebut.

Penerusan tidak pernah menjadi masalah

Aturan penerusan port menjelaskan lalu lintas TCP atau UDP. Aturan itu tidak dapat menjelaskan muatan yang beralih ke protokol IP lain di tengah sesi, dan PPTP melakukan tepat itu.

Karena itulah koneksi terlihat sehat sampai saat macet. Bagian yang dapat diatur aturan port berhasil, dan bagian yang tidak dapat diaturnya adalah bagian yang gagal.

TCP untuk kendali, GRE untuk data

Panggilan dinegosiasikan melalui TCP 1723. Setelah aktif, muatan pindah ke GRE, protokol IP 47, yang tidak membawa nomor port sama sekali. Aturan yang berpatokan pada port tidak punya apa pun untuk dicocokkan.

Yang dibawa GRE adalah pengenal panggilan di kepala paketnya, dan penerjemah NAT harus menulis ulang bidang itu secara konsisten di kedua arah atau kedua belah sesi berhenti saling sepakat. Satu arah ditulis ulang dan yang lain tidak menghasilkan sesi yang mengautentikasi lalu membuang setiap paket data. Itulah persis bentuk gejalanya: berhasil, lalu sunyi.

GRE telanjang tanpa PPTP tidak perlu penulisan ulang seperti itu, itulah sebabnya terowongan GRE biasa dapat bekerja melalui router yang gagal untuk klien PPTP di jalur yang sama.

Empat modul dan sebuah sysctl yang mematikannya

Dua modul menangani pembingkaian, nf_conntrack_proto_gre dan nf_nat_proto_gre. Dua lagi menangani pengenal panggilan, nf_conntrack_pptp dan nf_nat_pptp. Memuat yang terakhir menarik sisanya melalui dependensi, jadi daftar modul seharusnya menunjukkan keempatnya.

Petunjuk lama memakai awalan ip_ dari era 2.6. Perintah itu bisa tampak berjalan sementara tidak memuat apa pun, jadi periksa daftar yang dimuat, bukan status keluarnya.

Memuatnya tidak lagi cukup. Sejak Linux 4.7 sysctl net.netfilter.nf_conntrack_helper bernilai 0 secara bawaan, yang menonaktifkan penetapan helper otomatis untuk aliran baru. Sebuah router bisa memiliki semua modul dan tetap tidak menerjemahkan apa pun. Periksa nilai efektifnya sebelum memeriksa daftar modul lagi.

Entah aktifkan kembali penetapan otomatis secara global, atau pasang helper ke aliran yang membutuhkannya dan biarkan sisanya:

iptables -t raw -A PREROUTING -p tcp --dport 1723 -j CT --helper pptp

Opsi kedua yang lebih baik. Opsi itu membatasi perilaku pada lalu lintas PPTP alih-alih mengaktifkan kembali penetapan otomatis di seluruh router.

Membuka protokol yang tidak punya port

Aturan firewall yang mengizinkan 1723 tidak mengatakan apa pun tentang protokol 47. Di firewalld, izinkan protokol itu di zona yang menghadap klien. Di iptables biasa, terima protokol gre di rantai input.

Lalu tangkap di kedua sisi. Paket yang meninggalkan klien tanpa balasan yang datang berarti jalur kembali disaring, dan itu kesalahan yang berbeda dari kredensial yang ditolak.

Setelah terhubung, batas ukuran

GRE menyisipkan kepala paket, dan PPP di dalamnya menambah lebih banyak, jadi tautan yang bekerja melaporkan MTU jauh di bawah 1500. Respons kecil termuat dan yang besar macet, yang tampak seperti masalah kedua yang tidak terkait muncul tepat saat masalah pertama terpecahkan.

Baca MTU pada adaptor PPP klien dan cocokkan dengan perhitungan router sendiri alih-alih menurunkan angka sampai sesuatu berhasil. Paket berukuran penuh yang keluar tanpa ada yang kembali menunjuk ke batas itu, bukan ke penerjemahan.

Memperbaiki jalur membuat pengguna bekerja, dan itu tidak menjadikan PPTP pilihan yang baik. MS-CHAPv2 dan RC4 sudah lama usang, jadi perlakukan pemuatan modul sebagai perbaikan sementara dan rencanakan perpindahan ke protokol yang dipelihara.