د یو Linux حساب د UID قاعدې سره د OpenVPN له لارې لارښودول

د حساب پر بنسټ لارښودنه هغه وخت مناسبه ده کله چې د یو Linux کاروونکي په ملکیت کې هر IPv4 ساکټ باید د موجوده ټونل له لارې ووځي، او هغه وخت مناسبه نه ده کله چې تاسو د پروګرام کچې جلاوالي ته اړتیا لرئ۔ دا د UID له مخې ټاکي، نو هر هغه څه چې په دې حساب کې ګرځي په حد کې دي، هغه بټچ کار هم چې هیر مو کړی۔ دا پوښتنه حل کړئ مخکې له دې چې یو ip rule ته لاس ووهئ۔

لاندې بېلګه په UID 1500 کې ځانګړی براوزر حساب، د 10.80.0.11 سیمه ایز پته لرونکی ټونل وسیله tun-office، او هغه VPN فرض کوي چې اړوند منزلونه اجازه ورکوي۔ ډیمون پخپله له دې UID بهر کار کوي۔

درې شرطونه چې میکانېزم ټاکي

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

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

جدول، قاعده او ساتونکی

وروسته له دې چې موجودې قاعدې وڅیړئ او نااستعمال شمېرې د جدول او لومړیتوب وټاکئ، ترتیب لنډ دی: په ځانګړي جدول کې اصلي لار چې د ټونل سرچینه پته لري، یوه قاعده چې د حساب پوښتنې هغه جدول ته لېږي، او یوه پای ته رسولونکې قاعده چې بدیله لار بندوي۔ په لیکلي ډول دا یو idempotent لار بدلون دی، ip -4 route replace default dev tun-office src 10.80.0.11 table 51820، او ورپسې ip -4 rule add priority 12100 uidrange 1500-1500 lookup 51820۔

ساتونکی ip -4 rule add priority 12101 uidrange 1500-1500 unreachable دی، او د خپل اوږدوالي له اشارې زیات اهمیت لري۔ پرته له دې، په 51820 جدول کې ورکه لار عادي پورتنۍ اړیکې ته غورځي او حساب په خاموشۍ هغه ترافیک تویوي چې پالیسي باید نیولی وی۔ له دې سره هماغه ناکامي د وخت پای ته رسېدل کیږي، یعنې بندول نه بدیله لار۔

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

UID لارښودنه څه پرېږدي: DNS

د حل کوونکي ډیمون خپل پورته ساکټونه د خپل UID لاندې پرانیزي، نو 1500 ټاکل هغه پوښتنې 51820 جدول ته نه لېږدوي۔ د DNS یوځای کول جلا پریکړه ده: حساب د ټونل له لارې د رسېدونکي حل کوونکي په لوري ګوته کړئ، یا ومنئ چې د نومونو حل د کوربه لار تعقیبوي خو ترافیک نه۔

سیمه ایز stub ته loopback پوښتنه د دې ثبوت نه دی چې پورتنۍ پوښتنه د براوزر لاره کارولې، او نه له کاشي څخه بریالۍ پاڼه بارول۔

IPv6 په ډیزاین کې خپله جمله غواړي

پورتني قاعدې یوازې IPv4 پوښي۔ که اړتیا له دې حساب څخه پرته له مستقیم IPv6 یو IPv4 ټونل وي، نو کتل شوې پای ته رسولونکې قاعده اضافه کړئ لکه ip -6 rule add priority 12101 uidrange 1500-1500 unreachable، بیا پخوانۍ IPv6 قاعدې او هغه loopback استثناوې چې غواړئ وساتئ وڅیړئ۔

مستقیم IPv6 بندول دوه ګونی سټیک ټونلینګ نه دی؛ دا یوه پوله ده۔ د دې ټونلینګ بلل به بل کس چې پالیسي لولي ګډوډ کړي، او ګډوډي به د خراب IPv6 سایټ په اړه د مرستې میز ټکټ په بڼه راڅرګنده شي۔

د ریښتیني حساب سره تایید کړئ، بیا د ژوند دورې مسؤلیت واخلئ

پوښتنې پرتله کړئ: ip -4 route get 198.51.100.25 uid 1500 هماغه منزل ته د عادي UID سره۔ بیا د ځانګړي حساب لاندې اجازه لرونکې غوښتنه وکړئ او هغه سرچینه پته وڅیړئ چې لرې پای یې ویني۔ غوره شوې سرچینه پته source NAT نه ده، او هغه اپلیکیشن ته چې بل څه تړي نه برلاسي کیږي۔ که دواړه پوښتنې یوه لار بېرته راوګرځوي، قاعده هغه نه کوي چې تاسو یې فکر کوئ۔

جدول، قاعدې او د ټونل لارې عمر د یو مالک لاندې وساتئ، بیاځلي نښلول او د ټونل له لاسه ورکول وآزموئ، او کله چې پالیسي وباسئ یوازې د هغې دقیق ثبتونه لرې کړئ۔ که جلا انټرفیسونه او جلا حالت واقعیا هغه څه وي چې تاسو ورته اړتیا لرئ، namespace لا هم شته۔