په Linux VPN کې د پتې، لارې، DNS او firewall څښتن څوک دی؟

دوه سکریپټونه چې د یوې لارې لپاره جنګیږي د Linux VPN ستونزې عادي بڼه ده چې د لارښوونې باګ په توګه ثبت کیږي. یو برخه د تونل وسیله جوړوي، بل د ډیفالټ لاره ورزیاتوي، دریم د حل کوونکي ترتیبات بیا لیکي، او څلورم د firewall قواعد بیا باروي. له دوی څخه هر یو کولای شي د بل کار لغوه کړي، او ګټونکی یوازې هغه دی چې وروستی ځل چلیدلی وي. د ځواب وړ پوښتنه دا نه ده چې کوم بسته نصب کړو، بلکې دا ده چې د حالت هرې برخې لپاره کومه برخه واکمنه ده.

دا نقشه یو ځل ولیکئ، او ډیری د بیا نښلولو ناکامۍ به له اسراره ووځي. څلور شیان مهم دي: وسیله او پتې یې، لارې او د تګلارې قواعد، د DNS ترتیبات او firewall.

وسیله او پتې یې

د تونل وسیله یا د هغه مدیر لخوا جوړیږي چې پروفایل پېژني، یا د هغه ډیمون لخوا چې یو چا په لاس پیل کړی وي. دواړه ترتیبات په خپل سر کار کوي؛ د دوی ګډول نه. که NetworkManager د پروفایل څښتن وي، پرېږدئ چې د وسیلې هم څښتن وي، او د همدې تونل نوم پر ضد یو غیر مدیریتي OpenVPN پروسه مه پیلوئ.

ولیکئ چې کله ناسته پای ته ورسیږي وسیله څوک لرې کوي. هغه وسیله چې له خپلې ناستې اوږده ژوندي پاتې کیږي، د زړو پتو او د هغوی وروسته ګډوډۍ تر ټولو عامه سرچینه ده.

لارې او د تګلارې قواعد

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

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

DNS تل جلا مالک دی

د حل کوونکي ډیمون د خپل هویت لاندې د خپلې پروسې په توګه چلیږي، له همدې امله د تونل د لارښوونې پرېکړې په ناڅاپي ډول نه میراث اخلي. کله چې VPN د DNS سرورونه ټېله کوي، یو څه باید هغه په هغه پر-لینک ترتیباتو وژباړي چې حل کوونکی یې درناوی کوي، او بیا یو څه باید هغه لرې کړي.

دلته افسانه دا ده چې په پروفایل کې د نوم سرور لیکل بدلوي چې پوښتنې چیرته ځي. دا هغه بدلوي چې حل کوونکي ته څه ویل کیږي، نه دا چې حل کوونکی پورته کوم ساکټ کاروي. د فایل باور کولو پرځای د پوښتنې او د لارې پلټنې سره ازموینه وکړئ.

د firewall حالت، او څوک یې بحالي کوي

د firewall قواعد په VPN کوربه کې تر ټولو ډېر بیا لیکل کیږي. مدیر کولای شي د هرې اړیکې لپاره د NAT یا لېږد قواعد ورزیات کړي، پداسې حال کې چې د بوټ وخت firewall خدمت یو خوندي شوی قواعد ټولګه بیا باروي او هغوی ړنګوي. د تګلارې لپاره یو واک وټاکئ او بل یې مصرف کوونکی کړئ، یا ومنئ چې بیا پیل کول چلند په غلې اوږه بدلوي. د اړیکې سره تړلې استثناوې باید په هغه فایل کې وي چې هماغه مالک یې باروي، نه په هغه iptables حکم کې چې د ستونزې حل پر مهال ټایپ کیږي.

که قواعد باید د بیا نښلولو څخه ژوندي پاتې شي، دا په ښکاره ووایاست. که نه، هغه هم ووایاست، ځکه بل انجینر به ډېر اسانه ځواب فرض کړي.

د ژوند دوره: بوټ، بیا نښلول، ویجاړول

د دغو دریو شیبو هر یو ته یو مالک ورکړئ. د بوټ پر مهال پرېکړه وکړئ چې مخکې شرطونه څه تیاروي او په کوم ترتیب. په نرم بیا پیل کې په یاد ولرئ چې وسیله کېدای شي ژوندې پاتې شي خو د ناستې حالت نه، نو باید یو تاییدوونکی وګرځي نه جوړوونکی. د ویجاړولو پر مهال یوازې هغه څه لرې کړئ چې دا اړیکه جوړ کړي دي، ځکه هرې لارې بیا تنظیمول یا ټول firewall خالي کول د یو تونل له کار څخه ایستلو سره یو شان نه دي.

د څارنې لپاره ip monitor link address route د کرنل بدلونونه ښیي لکه څنګه چې پېښیږي، خو دا د نیت پرځای پېښې راپور کوي: ړنګه شوې لاره هېڅ نه وايي چې کومه پروسه یې ړنګه کړې. هغه د مالکیت نقشې سره جوړه کړئ، او یو ګډوډ بندول به د نوماندانو لنډ لیست شي.

استثناوې هم بیه لري. د نښتې څخه د تېښتې لپاره ټول د وسیلې ټولګه غیر مدیریتي نښه کول هغه حالت هیڅوک ته نه سپاري، چې دا سمون نه، بلکې پرېکړه ده.