د OPNsense تر شا د OpenVPN کلینټونو ثابت پتې

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

OPNsense دا overrideونه د سرور په کلینټ ځانګړو تنظیماتو کې ساتي، چې د سند عام نوم یې کیلي دی، او دا عام نوم د پتې پلان برخه ګرځوي۔

چسپې کرایه ثابته پته نه ده

د pool فایل د پتې-کلینټ نقشې لیکي او کله چې پېژندل شوی کلینټ بیا ونښلول شي هغه بېرته ورکوي۔ دا اسانتیا ده، نه تړون: فایل کولای شي بیا جوړ شي، نقشه هغه وخت ورکېږي چې د کلینټ هویت بدل شي، او هغه دوه سرورونه چې یو pool شریکوي به پرې سلا نه شي۔ د کلینټ لپاره ځانګړی override بل ډول کار کوي، ځکه پته د تاریخ څخه نه، بلکې د ترتیباتو څخه راځي۔ هغه د وسیلې بیا پیل او بیا نصب هم زغمي، په دې شرط چې override د نورو ترتیباتو سره یوځای بیکاپ شوی وي۔

متحرکه بدیله لار، یعنې VPN له DNS سره د client-connect سکریپټ او متحرکو تازه کولو له لارې نښلول، کار کوي او داسې resolver غواړي چې تازه کول ومني، او همدارنګه په هرې نښلونې کې یو سکریپټ۔ په وسیله کې تاسو یوازې هغو بستو ته محدود یاست چې پلورونکی یې برابروي، او معمولاً هماغه ځای کې دا پلان ودريږي۔

هغه /30 حساب چې هیچا نه خوښېږي

په تلواله net30 ټوپولوژي کې هر کلینټ خپله /30 ترلاسه کوي: لومړۍ د کارېدو وړ پته د سرور خوا ته ځي، دویمه کلینټ ته۔ نو overrideونه باید د سرور د متحرکې ټنل شبکې څخه بهر وي، چې مانا یې دا ده لومړی هغه شبکه پراخه کړو۔ د 10.8.0.0/24 پر سرور کولای شي 10.8.0.0/23 ته ووځي، د زاړه ساحې نیمه برخه متحرکو کلینټونو ته او بله نیمه overrideونو ته پرېږدي۔ اصلي /24 د اضافي IPv4 ځایي شبکې په توګه ورزیات کړئ تر څو دواړو نیمو ته ترافیک ټنل ته وګرځي۔

هره override پته باید پر /30 پوله ولګېږي، نو وروستی اکتېټ د څلورو ضریب وي۔ پر 10.8.1.0 یوه /30 کلینټ ته 10.8.1.2 ورکوي، او هماغه پته ده چې DNS ریکارډ یې لري۔ د هغې پر ځای 10.8.1.3 غوره کول داسې کلینټ جوړوي چې نښلي خو ترافیک نه شي لېږدولی، ځکه پته هغې فرعي شبکې پورې اړه لري چې ټوپولوژي هېڅکله هغه ته نه ده ټاکلې۔

پلان ساتل اسانه دي که overrideونه د پراخې ساحې له پاسه لاندې ته ووېشل شي، تر څو متحرک pool په خالي ځای کې پراخ شي نه د ثابتو ټاپوګانو شاوخوا۔

ځایي شبکې او هغه زون چې کلینټونه ترې پوښتنه کوي

له کلینټ څخه کلینټ ته ترافیک خپله اجازه غواړي۔ د سرور د IPv4 ځایي شبکو لړلیک باید د ساحې دواړه نیمې برخې ولري، متحرکه او ثابته؛ پرته له دې سرور له یوه کلینټ څخه بسته مني او هغه سیاست نه لري چې بل ته یې تېرېدو ته اجازه ورکړي۔ نښه د DNS د خرابۍ په څېر ښکاري، ځکه نوم حل کېږي او نښلونه بیا هم ناکامه وي۔ په همدې وخت کې د کلینټ-کلینټ تنظیم هم وګورئ، ځکه یوازې د ځایي شبکې ننوتنه د همزولو ترمنځ لېږد نه فعالوي۔

ریکارډونه په هغه زون کې خپاره کړئ چې لرې کلینټونه واقعاً ترې پوښتنه کوي۔ د هغه زون ریکارډ چې یوازې د LAN resolver یې خدمت کوي، هغه کلینټ ته نه ښکاري چې هلېښل شوی resolver یې بل ځای ته اشاره کوي، او په غلط زون کې نور ریکارډونه ورزیاتول هېڅکله دا نه سمول۔ له هر څه مخکې هلېښل شوې DNS خوښه او د لټون ډومین تایید کړئ۔

په نوې نښلونې کې څه وګورئ

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

هغه سند چې په بل عام نوم بیا صادر شي له خپل override سره سمون بندوي او کلینټ بېرته متحرک pool ته راګرځوي۔ له هر هویت بدلون وروسته دې ته تمه ولرئ۔