Docker-də PPTP autentifikasiyadan keçir, amma trafik daşımır

Müştəri autentifikasiyadan keçir, PPP ünvanı razılaşdırır və sonra heç nə yerindən tərpənmir. Ping uğursuz olur, brauzer uğursuz olur, konteyner isə bütün müddət qoşulmuş görünür. Bu mənzərə marşrut cədvəli problemi deyil, çünki marşrut problemləri adətən nəzarət bağlantısını da pozur. Bu, yük yoludur və PPTP-də yük təzəcə uğur qazanan protokoldan fərqli bir protokoldur.

Ən çox vaxt qazandıran sıra ilə beş yoxlama.

Yoxlama 1: nəzarət kanalını yükdən ayırın

PPTP TCP 1723 üzərindən autentifikasiya edir və sonra PPP yükünü GRE, IP protokolu 47 içində daşıyır. GRE nə TCP, nə də UDP deyil, ona görə nəzarət portunu yönləndirən hər qayda onun haqqında heç nə demir. 1723-ü keçirən NAT və ya firewall 47 protokolunu şikayətsiz ata bilər və sessiya uğur kimi görünən şəkildə yarımqurulmuş qalır.

Giriş işləyirsə və heç bir paket qayıtmırsa, əvvəlcə GRE fərz edin, sonra bunu sübut edin.

Yoxlama 2: host nüvəsindəki köməkçini təsdiqləyin

Bağlantı izləmə köməkçi olmadan TCP nəzarət bağlantısını GRE axınına bağlaya bilməz. Modul nf_conntrack_pptp-dir, o, host nüvəsində yaşayır və onu konteyner obrazı içində yükləmək heç nə vermir, çünki modullar bütün host üçün ümumidir. Docker hostunda lsmod | grep nf_conntrack_pptp yoxlamadır. Əgər yoxdursa, modprobe nf_conntrack_pptp onu işləyən nüvə üçün yükləyir və növbəti açılış barədə heç nə demir, ona görə onu host konfiqurasiyasına da əlavə edin.

Yenidən başlatmada yox olan modul gələn ay eyni biletə çevrilir.

Yoxlama 3: onu söndürən nüvə siyasətini oxuyun

Modul mövcud olsa belə, 4.7-dən bəri nüvələr net.netfilter.nf_conntrack_helper üçün standart olaraq 0 qəbul edir və bu, hər protokol üçün avtomatik köməkçi təyinatını söndürür. Bu standart düzgün quraşdırılmış modulun niyə hələ də heç nə etmədiyinin səbəbidir: kod yerindədir və siyasət ondan istifadə etməməyi deyir. sysctl net.netfilter.nf_conntrack_helper cari dəyəri göstərir və onu iş vaxtı 1-ə qoymaq köməkçini yenidən əlçatan edir. Dizayn imkan verirsə, dəyəri host sysctl konfiqurasiyası vasitəsilə saxlayın.

Avtomatik təyinat trafikə gizli şəkildə gözləntilər yaratmağa imkan verir və standartın dəyişməsinin səbəbi məhz budur. Onu etibarlı hostla məhdudlaşdırın və ya köməkçini hədəfləyən açıq qayda istifadə edin.

Yoxlama 4: konteyner yoluna ayrıca baxın

Yüklənmiş köməkçi marşrut yaratmır. Konteynerə PPTP serverinə yol lazımdır və host yönləndirməsi GRE-ni hər iki istiqamətdə icazə verməlidir: iptables -L FORWARD -v -n 47 protokolunun qəbul edilib-edilmədiyini və sayğacların hərəkət edib-etmədiyini göstərir. Docker masquerade qaydaları TCP və UDP-ni çevirir, 47 protokolunu yox, ona görə körpülü konteynerə açıq forward icazəsi və bəzi hostlarda öz çevirmə qaydası lazım ola bilər. Həm də təsdiqləyin ki, konteyner öz obrazının gözlədiyi PPP cihaz dəstəyinə malikdir.

Qayda mətnini deyil, sayğacları oxuyun. Mövcud olub heç nəyə uyğun gəlməyən qayda bəzəkdir.

Yoxlama 5: GRE-nin izləndiyini sübut edin, sonra PPTP barədə qərar verin

Müştəri işləyərkən izləmə cədvəlini oxuyun. Qurulmuş PPTP nəzarət qeydi və ona bağlı GRE qeydi köməkçinin axınları bağladığını və qalan nasazlığın başqa yerdə olduğunu bildirir. GRE qeydi olmayan nəzarət qeydi yükün atıldığını və ya izlənmədiyini bildirir, bu da sizi 2 və 3-cü yoxlamalara qaytarır.

PPTP özü köhnəlmişdir və MS-CHAPv2 zəifdir. Server həm də L2TP/IPsec, IKEv2 və ya WireGuard təklif edirsə, onlardan birinə keçmək bu problem sinfini tamamilə aradan qaldırır.

PPTP qalmalı olduğu yerlərdə, müştərini konteyner içində deyil, hostda işlətmək NAT və filtrləmənin bir qatını aradan qaldırır və bu çox vaxt daha ucuz qərardır.