PPTP di Docker terautentikasi tetapi tidak membawa lalu lintas

Klien terautentikasi, PPP menegosiasikan alamat, lalu tidak ada yang bergerak. Ping gagal, peramban gagal, dan kontainer tampak tersambung sepanjang waktu. Pola itu bukan masalah tabel perutean, karena masalah perutean biasanya juga memutus koneksi kontrol. Ini jalur muatan, dan pada PPTP muatan adalah protokol berbeda dari yang baru saja berhasil.

Lima pemeriksaan, dalam urutan yang menghemat paling banyak waktu.

Pemeriksaan 1: pisahkan kanal kontrol dari muatan

PPTP terautentikasi melalui TCP 1723 lalu membawa muatan PPP di dalam GRE, protokol IP 47. GRE bukan TCP maupun UDP, jadi setiap aturan yang meneruskan port kontrol tidak mengatakan apa pun tentangnya. NAT atau firewall yang meloloskan 1723 dapat menjatuhkan protokol 47 tanpa keluhan, dan sesi tetap setengah terbangun dengan cara yang tampak seperti keberhasilan.

Jika login berhasil dan tidak ada paket yang kembali, anggap GRE lebih dulu dan buktikan kemudian.

Pemeriksaan 2: pastikan pembantu di kernel host

Pelacakan koneksi tidak dapat menautkan koneksi kontrol TCP ke aliran GRE tanpa pembantu. Modulnya adalah nf_conntrack_pptp, ia hidup di kernel host, dan memuatnya di dalam image kontainer tidak mencapai apa pun karena modul berlaku untuk seluruh host. lsmod | grep nf_conntrack_pptp di host Docker adalah pemeriksaannya. Jika tidak ada, modprobe nf_conntrack_pptp memuatnya untuk kernel yang berjalan dan tidak mengatakan apa pun tentang boot berikutnya, jadi tambahkan juga ke konfigurasi host.

Modul yang hilang saat reboot menjadi tiket yang sama bulan depan.

Pemeriksaan 3: baca kebijakan kernel yang mematikannya

Bahkan dengan modul tersedia, kernel sejak 4.7 menetapkan net.netfilter.nf_conntrack_helper ke 0 secara bawaan, yang mematikan penetapan pembantu otomatis untuk setiap protokol. Bawaan itulah sebabnya modul yang terpasang dengan benar tetap tidak melakukan apa pun: kodenya ada dan kebijakan mengatakan untuk tidak memakainya. sysctl net.netfilter.nf_conntrack_helper melaporkan nilai saat ini, dan menyetelnya ke 1 saat runtime membuat pembantu tersedia lagi. Pertahankan nilainya melalui konfigurasi sysctl host jika desain mengizinkan.

Penetapan otomatis memungkinkan lalu lintas membuat ekspektasi secara implisit, dan itulah tepatnya alasan bawaannya diubah. Batasi ke host tepercaya, atau gunakan aturan eksplisit yang menyasar pembantu.

Pemeriksaan 4: lihat jalur kontainer secara terpisah

Pembantu yang dimuat tidak membuat rute. Kontainer membutuhkan jalur ke server PPTP, dan penerusan host harus mengizinkan GRE di kedua arah: iptables -L FORWARD -v -n menunjukkan apakah protokol 47 diterima dan apakah penghitungnya bergerak. Aturan masquerade Docker menerjemahkan TCP dan UDP, bukan protokol 47, jadi kontainer berjembatan mungkin memerlukan penerimaan forward eksplisit dan, pada sebagian host, aturan penerjemahannya sendiri. Pastikan juga kontainer memiliki dukungan perangkat PPP yang diharapkan imagenya.

Baca penghitungnya, bukan teks aturannya. Aturan yang ada dan tidak cocok dengan apa pun adalah hiasan.

Pemeriksaan 5: buktikan GRE dilacak, lalu putuskan soal PPTP

Saat klien berjalan, baca tabel pelacakan. Entri kontrol PPTP yang terbentuk ditambah entri GRE terkait berarti pembantu menautkan alirannya dan sisa gangguan ada di tempat lain. Entri kontrol tanpa entri GRE berarti muatan dijatuhkan atau tidak dilacak, yang membawa Anda kembali ke pemeriksaan 2 dan 3.

PPTP sendiri warisan lama dan MS-CHAPv2 lemah. Jika server juga menawarkan L2TP/IPsec, IKEv2, atau WireGuard, beralih ke salah satunya menghilangkan seluruh kelas masalah ini.

Di mana PPTP harus tetap ada, menjalankan klien di host alih-alih di dalam kontainer menghilangkan satu lapisan NAT dan penyaringan, yang sering kali menjadi keputusan lebih murah.