PPTP نښلول کیږي او بیا د Linux NAT تر شا ځړیږي: د GRE مرستندوی

یو څوک 1723 فوروارډ کوي، کلاینټ سرور ته رسیږي، تصدیق پیل کیږي، او بیا هر څه پرته له تېروتنې ودریږي۔ طبیعي نتیجه غلط پټنوم دی، نو پټنوم درې ځله بیا ټایپ کیږي۔ فوروارډ سم و او اعتبارنامې سمې وې۔ چې مات شو هغه دوهم پروتوکول دی چې فوروارډ هېڅکله نه و پوښلی، او د کرنل یو ډیفالټ چې په خاموشۍ کې ورسره مرسته کول بند کړل۔

فوروارډ هېڅکله ستونزه نه وه

د پورټ فوروارډ اصول د TCP یا UDP ترافیک تشریح کوي۔ دا هغه بار نشي تشریح کولی چې د غونډې په منځ کې بل IP پروتوکول ته ځي، او PPTP همدا کار کوي۔

نو ځکه اړیکه تر هغې شیبې روغه ښکاري چې ځړیږي۔ هغه برخه چې د پورټ اصول یې کنټرولولی شي بریالۍ شوه، او هغه برخه چې نشي کنټرولولی هماغه ناکامه برخه ده۔

د کنټرول لپاره TCP، د معلوماتو لپاره GRE

غږ د TCP 1723 له لارې خبرې اترې کیږي۔ کله چې ولاړ شي، بار GRE ته ځي، IP پروتوکول 47، چې هېڅ د پورټ شمېرې نه وړي۔ د پورټونو پر بنسټ اصول د ورته کولو لپاره هیڅ نلري۔

GRE چې وړي هغه د هغې په سرلیک کې د غږ پیژندونکی دی، او NAT ژباړونکی باید هغه ساحه په دواړو لورو کې په دوامداره توګه بیا ولیکي، که نه نو د غونډې دوه نیمایي له یو بل سره موافقې کول بندوي۔ یو لوری بیا لیکل شوی او بل نه، هغه غونډه جوړوي چې تصدیق کیږي او بیا هر د معلوماتو بسته غورځوي۔ د نښې بڼه همدا ده: بریا، بیا چوپتیا۔

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

څلور ماډلونه او یو sysctl چې هغوی یې بند کړل

دوه ماډلونه چوکاټ سمبالوي، nf_conntrack_proto_gre او nf_nat_proto_gre۔ نور دوه د غږ پیژندونکی سمبالوي، nf_conntrack_pptp او nf_nat_pptp۔ د وروستي بار کول نور د اړتیاوو له لارې راکاږي، نو د ماډلونو لیست باید څلور واړه وښیي۔

زاړه لارښوونې د 2.6 دورې ip_ مخکښ کاروي۔ هغه کمانډونه کېدای شي داسې ښکاره شي چې څه نه باروي او روان وي، نو د وتلو حالت پرځای بار شوی لیست وګورئ۔

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

یا اتوماتیک ټاکل بیا په نړیواله توګه فعال کړئ، یا مرستندوی هغه بهیرونو ته ونښلوئ چې ورته اړتیا لري او نور هر څه پرېږدئ:

iptables -t raw -A PREROUTING -p tcp --dport 1723 -j CT --helper pptp

دوهم انتخاب غوره دی۔ دا چلند یوازې PPTP ترافیک ته محدودوي، پرځای دې چې په ټول روټر کې اتوماتیک ټاکل بیا فعال کړي۔

د هغه پروتوکول خلاصول چې پورټ نلري

د فایر وال هغه اصول چې 1723 ته اجازه ورکوي د پروتوکول 47 په اړه هیڅ نه وايي۔ په firewalld کې پروتوکول په هغه زون کې اجازه کړئ چې کلاینټ ته مخامخ دی۔ په عادي iptables کې په ننوتلو زنځیر کې gre پروتوکول ومنئ۔

بیا په دواړو خواوو کې نیول وکړئ۔ هغه بستې چې کلاینټ پرېږدي او ځوابونه نه رسیږي مانا دا ده چې د بېرته راتلو لاره فلټر ده، او دا له رد شوې اعتبارنامې څخه بېله خرابي ده۔

له نښلېدو وروسته د اندازې حد

GRE یو سرلیک ورننباسي، او په داخل کې PPP نور هم زیاتوي، نو کاري لینک د 1500 څخه ډېر ښکته MTU راپور ورکوي۔ کوچني ځوابونه بار کیږي او لویان ځړیږي، چې د لومړي ستونزه حل کېدو شیبه کې راڅرګندېدونکې دوهمه، بې اړیکې ستونزه ښکاري۔

د کلاینټ په PPP اډاپټر کې MTU ولولئ او له روټر خپل حساب سره یې همغږي کړئ د دې پرځای چې شمېرې راټیټې کړئ ترڅو څه کار وکړي۔ د بشپړ اندازې بستې چې وځي او هیڅ نه راګرځي هماغه حد ته اشاره کوي، نه ژباړې ته۔

د لارې ترمیم کاروونکی بیا کار ته راولي، او دا PPTP ښه انتخاب نه کوي۔ MS-CHAPv2 او RC4 ډېر پخوا زاړه شوي، نو د ماډلونو بارول د لنډمهاله سمون په توګه وګورئ او د یو ساتل شوي پروتوکول ته د تلو پلان جوړ کړئ۔