Docker ichidagi PPTP autentifikatsiyadan o'tadi, lekin trafikni tashimaydi

Mijoz autentifikatsiyadan o'tadi, PPP manzil bo'yicha kelishadi, so'ngra hech narsa qimirlamaydi. Ping muvaffaqiyatsiz bo'ladi, brauzer muvaffaqiyatsiz bo'ladi, konteyner esa butun vaqt davomida ulangan ko'rinadi. Bu naqsh marshrutlash jadvali muammosi emas, chunki marshrutlash muammolari odatda boshqaruv ulanishini ham buzadi. Bu yuk yo'li, PPTPda esa yuk hozir muvaffaqiyatli bo'lgan protokoldan boshqa protokoldir.

Eng ko'p vaqtni tejaydigan tartibda beshta tekshiruv.

Tekshiruv 1: boshqaruv kanalini yukdan ajrating

PPTP TCP 1723 orqali autentifikatsiyadan o'tadi va keyin PPP yukini GRE, IP protokoli 47 ichida tashiydi. GRE na TCP, na UDP, shuning uchun boshqaruv portini o'tkazadigan har bir qoida u haqida hech narsa demaydi. 1723ni o'tkazadigan NAT yoki xavfsizlik devori 47 protokolini shikoyatsiz tashlab yuborishi mumkin va sessiya muvaffaqiyatga o'xshash tarzda yarim qurilgan holda qoladi.

Agar kirish ishlasa va hech qanday paket qaytmasa, avval GRE deb taxmin qiling, keyin buni isbotlang.

Tekshiruv 2: xost yadrosidagi yordamchini tasdiqlang

Ulanish kuzatuvi yordamchisiz TCP boshqaruv ulanishini GRE oqimiga bog'lay olmaydi. Modul nf_conntrack_pptp, u xost yadrosida yashaydi va uni konteyner obrazining ichida yuklash hech narsa bermaydi, chunki modullar butun xostga tegishli. Docker xostidagi lsmod | grep nf_conntrack_pptp — bu tekshiruv. Agar u bo'lmasa, modprobe nf_conntrack_pptp uni ishlab turgan yadro uchun yuklaydi va keyingi yuklanish haqida hech narsa demaydi, shuning uchun uni xost konfiguratsiyasiga ham qo'shing.

Qayta yuklashda yo'qolgan modul keyingi oyda xuddi shu chiptaga aylanadi.

Tekshiruv 3: uni o'chiradigan yadro siyosatini o'qing

Modul mavjud bo'lsa ham, 4.7dan beri yadrolar net.netfilter.nf_conntrack_helper ni standart bo'yicha 0 ga qo'yadi, bu har bir protokol uchun yordamchining avtomatik tayinlanishini o'chiradi. Aynan shu standart tufayli to'g'ri o'rnatilgan modul ham hech narsa qilmaydi: kod bor va siyosat undan foydalanmaslikni aytadi. sysctl net.netfilter.nf_conntrack_helper joriy qiymatni bildiradi va uni ish vaqtida 1 ga qo'yish yordamchini yana mavjud qiladi. Agar dizayn ruxsat bersa, qiymatni xostning sysctl konfiguratsiyasi orqali saqlang.

Avtomatik tayinlash trafikka bilvosita kutishlar yaratishga imkon beradi va standartning o'zgarishiga aynan shu sabab bo'ldi. Uni ishonchli xost bilan cheklang yoki yordamchiga qaratilgan aniq qoidadan foydalaning.

Tekshiruv 4: konteyner yo'lini alohida ko'ring

Yuklangan yordamchi marshrut yaratmaydi. Konteynerga PPTP serveriga yo'l kerak va xostdagi yo'naltirish GREga ikkala yo'nalishda ham ruxsat berishi kerak: iptables -L FORWARD -v -n 47 protokoli qabul qilinayotganini va hisoblagichlar harakatlanayotganini ko'rsatadi. Dockerning masquerade qoidalari TCP va UDPni o'giradi, 47 protokolini emas, shuning uchun ko'prikli konteynerga aniq forward ruxsati va ba'zi xostlarda o'zining o'girish qoidasi kerak bo'lishi mumkin. Konteynerda o'z obrazi kutgan PPP qurilma qo'llab-quvvatlashi borligini ham tasdiqlang.

Qoida matnini emas, hisoblagichlarni o'qing. Mavjud bo'lib, hech narsaga mos kelmaydigan qoida — bezak.

Tekshiruv 5: GRE kuzatilayotganini isbotlang, keyin PPTP haqida qaror qiling

Mijoz ishlab turganda kuzatuv jadvalini o'qing. O'rnatilgan PPTP boshqaruv yozuvi va unga tegishli GRE yozuvi yordamchi oqimlarni bog'layotganini va qolgan nosozlik boshqa joyda ekanini bildiradi. GRE yozuvisiz boshqaruv yozuvi yuk tashlanayotganini yoki kuzatilmayotganini bildiradi, bu sizni 2 va 3-tekshiruvlarga qaytaradi.

PPTPning o'zi eskirgan va MS-CHAPv2 zaif. Agar server L2TP/IPsec, IKEv2 yoki WireGuardni ham taklif qilsa, ulardan biriga o'tish bu muammolar sinfini butunlay yo'q qiladi.

PPTP qolishi shart bo'lgan joyda, mijozni konteyner ichida emas, xostda ishga tushirish NAT va filtrlashning bir qatlamini yo'q qiladi, bu ko'pincha arzonroq qaror.