جلا وتونکی: usb0 کې VPN ډله، eth0 کې د ګیټوې ټرافیک

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

ډاډ ترلاسه کړئ چې سرچینه پته تر رټنګ پرېکړې پورې پاتې کېږي

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

همدلته سیمه ییزې ازموینې ګمراه کوي۔ پر ګیټوې چلول شوی curl د ګیټوې پتې سره سیمه ییز جوړ شوی بهیر دی، نو اصلي جدول اخلي او د مراجعینو د لارې په اړه څه نه ثابتوي۔ له نښلول شوي مراجع څخه ازموینه وکړئ، یا داسې سرچینې سره ټرافیک جوړ کړئ چې واقعاً د ډلې وي۔

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

بشپړه ټاکل شوې جدول جوړه کړئ

جدول د یوه ملګري سره ډیفالټ لاره نه ده۔ ورته په کافي اندازه لارې ته اړتیا ده چې هره پلټنه په داخل کې حل شي، په دې کې د WAN فرعي شبکې نښلول شوې لاره هم، تر څو راتلونکی ټوپ د لاسرسي وړ وي۔ د tun1 پر 10.77.0.0/24 ډلې، د 203.0.113.1 راتلونکي ټوپ سره د 203.0.113.20/24 WAN پتې، او جدول 600 لپاره:

ip -4 route replace 203.0.113.0/24 dev usb0 src 203.0.113.20 table 600
ip -4 route replace 10.77.0.0/24 dev tun1 table 600
ip -4 route replace default via 203.0.113.1 dev usb0 table 600
ip -4 rule add priority 1500 from 10.77.0.0/24 lookup 600

قاعده د هر موجود هر څه نیوونکي قاعدې لاندې لومړیتوب کې ده، نو سمون لرونکي مراجعین لومړی جدول 600 ته رسېږي او نور هر څه اصلي جدول ته ورځي۔ د ip-rule حواله د ترتیب شوي لټون ماډل او د ټاکونکي نحوه په بشپړه توګه بیانوي۔

بیا فکر وکړئ چې جدول کې څه نشته۔ هغه منزل چې یوازې اصلي کې لاره لري، لکه د eth0 له لارې د لاسرسي وړ مدیریت فرعي شبکه، په جدول 600 کې نه موندل کېږي او هلته ډیفالټ شتون ولري اصلي ته نه راګرځي۔ که هغه لارې مهمې وي، هغه په څرګنده توګه ټاکل شوې جدول ته ورزیاتې کړئ، کوم چې د VPN د وتلو جدول لپاره معمولاً سم ځواب دی۔

د اورېدونکي خپل ټرافیک له پالیسۍ بهر وساتئ

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

د بېرته لار فلټرول هم همدې لامل ته کتنې ارزښت لري۔ کله چې مراجعینو ته ځوابونه د usb0 له لارې وځي او غوښتنه بېل لینک ته رسېدلې وي، سخت rp_filter تنظیم کولی شي هغه پاکټونه وغورځوي چې د رټنګ پالیسي یې سم ګڼي۔ مخکې له دې چې نتیجه واخلئ چې قاعده ناکامه شوه، پر دواړو انټرفیسونو د sysctl اغېزمن ارزښتونه وګورئ۔

ترتیب پر ماشین د هر بل څه په نسبت هم مهم دی۔ Docker پلونه، دوهم VPN او د برابرونکي له انځور څخه هر پخوانی قاعده ټول لومړیتوبونه زیاتوي، نو د دې پر ځای چې لومړیتوب 100 یوازینی وګڼئ، بشپړه قاعده لیست ولولئ۔

لېږدول او ژباړه له لارې سره سمون کړئ

رټنګ یو پورتنی لینک ټاکي؛ دا د لېږدولو اجازه نه ورکوي۔ کرنل باید IPv4 لېږدول فعال ولري، او فایر وال باید له مراجع څخه WAN ته لوری او بېرته ټرافیک ومني۔ سم جدول د FORWARD زنځیر سره چې بهیر غورځوي هغه څرګندونه ورکوي چې ورکه لاره یې ورکوي، نو دواړه په یوه پاس کې ګډ کتل کېږي۔

که دوهم WAN شخصي ډله ستاسو په لوري بېرته رټنګ نه کړي، په هغه وتلو کې سرچینه وژباړئ۔ د متحرکې پتې انټرفیس لپاره ډلې او انټرفیس ته محدوده تنګه masquerade قاعده معمول ټاکنه ده:

iptables -t nat -A POSTROUTING -s 10.77.0.0/24 -o usb0 -j MASQUERADE

دلته حد له هدف څخه مهم دی۔ هغه masquerade قاعده چې له هر وتونکي انټرفیس سره سمون ولري هغه ټرافیک هم بیا لیکي چې په سمه توګه د eth0 له لارې وځي، او دا د رټنګ غلطۍ د سمولو پر ځای پټوي۔ ژباړه د رټنګ پرېکړې وروسته چلېږي، نو هېڅکله نشي هغه پاکټ سمولی چې غلط پورتني لینک ته لېږل شوی۔

کله چې لارې بېلې وي د ټنل اضافي لګښت هم پاملرنې ته اړتیا لري۔ که مراجعین لوی TCP MSS ومني او بدیله WAN لږ MTU یا په داخل کې ټنل ولري، لوی برخې ودرېږي او کوچنۍ کار کوي۔ د لېږدولو په لاره کې MSS کلپ کول دا له کله ناکله ټکنۍ کېدو پر ځای وړاندوینې وړ چلند ګرځوي۔

پریکړه وکړئ چې usb0 ورک شي نو څه پېږدي

تشه جدول د ناکامۍ پر مهال بندېدونکې حالت نه دی۔ که سمون لرونکې لاره ورکه شي، لټون بلې قاعدې ته دوام کوي، اصلي جدول ته رسېږي او د eth0 ډیفالټ اخلي۔ هغه ټرافیک چې باید د دوهم WAN له لارې ووځي په چوپتیا د لومړي له لارې وځي، او په پالیسي رټنګ شوي ځای پر ځای کې دا معمولاً هغه پایله ده چې تاسو یې تر ټولو لږ غواړئ۔

چېرې چې دا بېرته لوېدل د منلو وړ نه وي، په جدول 600 کې څرګنده پای لاره ورزیاته کړئ، لکه blackhole ډیفالټ، یا تر هغه چې انټرفیس بند وي په فایر وال کې ډله وغورځوئ۔ د دواړو له ډلې هر یو هغه پرېکړه ده چې لیکلی یې شئ؛ چوپتیا نه۔

دوامداره والی وروستی ټکی دی۔ چې څوک دواړه لینکونه لري، که د شبکې مدیر وي، لېږدونکی سکریپټ وي یا د نښلون ژوند چرخه، هغه باید په هر بیا نښلون کې پرته له کاپي زیاتولو لارې او قاعده بیا جوړې کړي۔ له ریښتیني مراجع څخه په غوښتنه او له ګیټوې څخه په جلا غوښتنه تایید کړئ، په دواړو کې لیدل شوې وتنه تایید کړئ، بیا دوهم WAN وباسئ او وګورئ چې ستاسو د ډیزاین شوو دوو پایلو له ډلې کومه واقعاً پېږدي۔ IPv6 خپل جدول، قاعده او ژباړه ته اړتیا لري؛ پورتنی IPv4 قاعده د هغه په اړه څه نه وایي۔