په Docker کې PPTP تصدیق کیږي خو هېڅ ترافیک نه لېږدوي

کلاینټ تصدیق کوي، PPP پر یوه پته خبرې اترې کوي، او بیا هېڅ نه خوځي۔ Ping ناکامېږي، براوزر ناکامېږي، او کانټینر په ټول وخت نښلول شوی ښکاري۔ دا بڼه د روټینګ جدول ستونزه نه ده، ځکه چې د روټینګ ستونزې معمولاً د کنټرول اړیکه هم ماتوي۔ دا د بار لار ده، او په PPTP کې بار د هغه پروتوکول څخه بل پروتوکول دی چې همدا اوس بریالی شو۔

پنځه څیړنې، په هغه ترتیب چې تر ټولو ډیر وخت خوندي کوي۔

څیړنه 1: د کنټرول چینل له بار څخه جلا کړئ

PPTP د TCP 1723 له لارې تصدیق کوي او بیا د PPP بار د GRE، IP پروتوکول 47 دننه لېږدوي۔ GRE نه TCP دی او نه UDP، نو هره قاعده چې د کنټرول پورټ فوروړډ کوي، د دې په اړه هېڅ نه وایي۔ NAT یا فایر وال چې 1723 تېروي کولی شي پروتوکول 47 پرته له شکایت وغورځوي، او غونډه نیمه جوړه پاتې کیږي په داسې ډول چې بریالیتوب ښکاري۔

که ننوتل کار کوي او هېڅ پاکټ بیرته نه راځي، لومړی GRE فرض کړئ او بیا یې ثابت کړئ۔

څیړنه 2: په هوسټ کرنل کې مرستندوی تایید کړئ

د اړیکو تعقیب پرته له مرستندوی نه شي کولی TCP کنټرول اړیکه له GRE بهیر سره وتړي۔ ماډل nf_conntrack_pptp دی، په هوسټ کرنل کې ژوند کوي، او په کانټینر عکس کې یې لوډول هېڅ نه ترلاسه کوي ځکه چې ماډلونه په ټول هوسټ باندې پلي کیږي۔ په Docker هوسټ کې lsmod | grep nf_conntrack_pptp همدا څیړنه ده۔ که نه وي، modprobe nf_conntrack_pptp یې د روان کرنل لپاره لوډوي او د راتلونکي بوټ په اړه هېڅ نه وایي، نو په هوسټ ترتیباتو کې یې هم اضافه کړئ۔

هغه ماډل چې په بیا پیل کې ورک شي، بله میاشت هماغه ټکټ کیږي۔

څیړنه 3: هغه کرنل پالیسي ولولئ چې دا بندوي

حتی د ماډل په شتون کې، د 4.7 څخه کرنلونه net.netfilter.nf_conntrack_helper په ډیفالټ ډول 0 ته ټاکي، چې د هر پروتوکول لپاره د مرستندوی اتوماتیک ګمارل بندوي۔ همدا ډیفالټ لامل دی چې سم نصب شوی ماډل بیا هم هېڅ نه کوي: کوډ شته او پالیسي وایي چې مه یې کاروه۔ sysctl net.netfilter.nf_conntrack_helper اوسنی ارزښت راپور کوي، او د چلېدو پر مهال یې 1 ته ټاکل مرستندوی بیا شته کوي۔ که ډیزاین اجازه ورکړي، ارزښت د هوسټ sysctl ترتیباتو له لارې وساتئ۔

اتوماتیک ګمارل ترافیک ته اجازه ورکوي چې په ضمني ډول تمې جوړې کړي، او همدا لامل دی چې ډیفالټ بدل شو۔ دا د باوري هوسټ پورې محدود کړئ، یا هغه څرګنده قاعده وکاروئ چې مرستندوی ته نېغه ده۔

څیړنه 4: د کانټینر لار جلا وګورئ

لوډ شوی مرستندوی روټ نه جوړوي۔ کانټینر ته د PPTP سرور تر څنګ لار ته اړتیا ده، او د هوسټ فوروړډینګ باید GRE په دواړو لارو اجازه ورکړي: iptables -L FORWARD -v -n ښیي چې پروتوکول 47 منل کیږي که نه او شمېرونکي خوځي که نه۔ د Docker masquerade قواعد TCP او UDP ژباړي، نه پروتوکول 47، نو پل لرونکي کانټینر ته ښایي څرګنده forward مننه او په ځینو هوسټونو کې خپله ژباړنې قاعده ته اړتیا وي۔ همدا راز ډاډ ترلاسه کړئ چې کانټینر د خپل عکس هغه PPP وسیله ملاتړ لري چې تمه یې کیږي۔

د قاعدې متن نه، شمېرونکي ولولئ۔ هغه قاعده چې شته خو له هېڅ سره سمون نه لري، سینګار دی۔

څیړنه 5: ثابته کړئ چې GRE تعقیب کیږي، بیا د PPTP په اړه پرېکړه وکړئ

د کلاینټ د چلېدو پر مهال د تعقیب جدول ولولئ۔ جوړه شوې PPTP کنټرول ننوتنه او اړونده GRE ننوتنه معنا دا ده چې مرستندوی بهیرونه تړي او پاتې خرابي بل ځای کې ده۔ پرته له GRE ننوتنې کنټرول ننوتنه معنا دا ده چې بار غورځول کیږي یا تعقیب نه کیږي، چې تاسو بیا څیړنو 2 او 3 ته راګرځوي۔

PPTP پخپله زوړ دی او MS-CHAPv2 کمزوری دی۔ که سرور L2TP/IPsec، IKEv2 یا WireGuard هم وړاندې کوي، نو یوې ته تلل د ستونزو دا ټوله طبقه لیرې کوي۔

چېرې چې PPTP باید پاتې شي، کلاینټ په هوسټ کې چلول نه په کانټینر کې د NAT او فلټر کولو یوه طبقه لیرې کوي، چې ډېری وخت ارزانه پرېکړه ده۔