PPTP dalam Docker mengesahkan tetapi tidak membawa trafik

Klien mengesahkan, PPP merundingkan alamat, dan kemudian tiada apa yang bergerak. Ping gagal, pelayar gagal, dan kontena kelihatan bersambung sepanjang masa. Corak itu bukan masalah jadual penghalaan, kerana masalah penghalaan biasanya memutuskan sambungan kawalan juga. Ia laluan muatan, dan dalam PPTP muatan ialah protokol berbeza daripada yang baru berjaya.

Lima pemeriksaan, mengikut urutan yang menjimatkan paling banyak masa.

Pemeriksaan 1: pisahkan saluran kawalan daripada muatan

PPTP mengesahkan melalui TCP 1723 dan kemudian membawa muatan PPP di dalam GRE, protokol IP 47. GRE bukan TCP atau UDP, jadi setiap peraturan yang memajukan port kawalan tidak berkata apa-apa tentangnya. NAT atau tembok api yang melepas 1723 boleh menggugurkan protokol 47 tanpa aduan, dan sesi kekal separuh terbina dengan cara yang kelihatan seperti kejayaan.

Jika log masuk berfungsi dan tiada paket kembali, anggap GRE dahulu dan buktikannya kemudian.

Pemeriksaan 2: sahkan pembantu dalam kernel hos

Penjejakan sambungan tidak dapat memautkan sambungan kawalan TCP kepada aliran GRE tanpa pembantu. Modulnya ialah nf_conntrack_pptp, ia hidup dalam kernel hos, dan memuatkannya di dalam imej kontena tidak mencapai apa-apa kerana modul terpakai untuk seluruh hos. lsmod | grep nf_conntrack_pptp pada hos Docker ialah pemeriksaannya. Jika tiada, modprobe nf_conntrack_pptp memuatkannya untuk kernel yang berjalan dan tidak berkata apa-apa tentang but seterusnya, jadi tambahkannya juga ke konfigurasi hos.

Modul yang hilang semasa but semula menjadi tiket yang sama bulan depan.

Pemeriksaan 3: baca dasar kernel yang mematikannya

Walaupun modul tersedia, kernel sejak 4.7 menetapkan net.netfilter.nf_conntrack_helper kepada 0 secara lalai, yang mematikan penyerahan pembantu automatik untuk setiap protokol. Lalai itulah sebabnya modul yang dipasang dengan betul masih tidak melakukan apa-apa: kod ada dan dasar mengatakan jangan gunakannya. sysctl net.netfilter.nf_conntrack_helper melaporkan nilai semasa, dan menetapkannya kepada 1 pada masa jalan menjadikan pembantu tersedia semula. Kekalkan nilai melalui konfigurasi sysctl hos jika reka bentuk mengizinkan.

Penyerahan automatik membenarkan trafik mencipta jangkaan secara tersirat, dan itulah sebabnya lalai diubah. Hadkan kepada hos yang dipercayai, atau gunakan peraturan eksplisit yang menyasarkan pembantu.

Pemeriksaan 4: lihat laluan kontena secara berasingan

Pembantu yang dimuatkan tidak mencipta laluan. Kontena memerlukan laluan ke pelayan PPTP, dan pemajuan hos mesti membenarkan GRE dalam kedua-dua arah: iptables -L FORWARD -v -n menunjukkan sama ada protokol 47 diterima dan sama ada pembilang bergerak. Peraturan masquerade Docker menterjemah TCP dan UDP, bukan protokol 47, jadi kontena berjambatan mungkin memerlukan penerimaan forward eksplisit dan, pada sesetengah hos, peraturan terjemahannya sendiri. Pastikan juga kontena mempunyai sokongan peranti PPP yang dijangka oleh imejnya.

Baca pembilang, bukan teks peraturan. Peraturan yang wujud dan tidak sepadan dengan apa-apa ialah hiasan.

Pemeriksaan 5: buktikan GRE dijejaki, kemudian putuskan tentang PPTP

Semasa klien berjalan, baca jadual penjejakan. Entri kawalan PPTP yang terbentuk ditambah entri GRE berkaitan bermakna pembantu memautkan aliran dan kerosakan yang tinggal ada di tempat lain. Entri kawalan tanpa entri GRE bermakna muatan digugurkan atau tidak dijejaki, yang membawa anda kembali ke pemeriksaan 2 dan 3.

PPTP sendiri warisan dan MS-CHAPv2 lemah. Jika pelayan juga menawarkan L2TP/IPsec, IKEv2 atau WireGuard, beralih kepada salah satunya menghapuskan seluruh kelas masalah ini.

Di mana PPTP mesti kekal, menjalankan klien pada hos dan bukan di dalam kontena menghapuskan satu lapisan NAT dan penapisan, yang selalunya keputusan yang lebih murah.