په دوه سرورونو کې یو VPN حساب: د حالت درې کتابونه

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

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

څوک کولای شي ونښلي: یو واک، ډېرې غوټې

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

شریکه ډېټابیس د دې ځواب یو ممکنه برخه ده۔ دا د دې ثبوت نه دی چې هر اړوند سیاست هلته ژوند کوي، یا هر غوټه بدلون په یوه لحظه کې پلی کوي۔ یو حساب چې په A غوټه کې غیرفعال شوی خو په B غوټه کې لا منل کېږي، مانا دا ده چې د وتلو بهیر نه دی بشپړ شوی۔

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

د صادرونکي واک له حساب ډاټا جلا وساتئ۔ ډېرې دروازې کولای شي پر هماغه CA باور وکړي، پرته له دې چې د هغې لاسلیک کیلي ولري، او هر غوټه لا هم خپل سرور سند او خپله د کړیګر خوا باور اړیکه غواړي۔

غوټه څه لري: پتې او لارې

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

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

کړیګران په قصد سره یوې غوټې ته واستوئ۔ د DNS غوره توب، د کړیګر د پای نقطو لیستونه او د مخکینۍ برخې خدمت بېل میکانزمونه دي چې د روغتیا او ناکامۍ بدلون بېل چلند لري۔ یو غوره کول سم دي؛ «د بار انډول» د ډیزاین په توګه منل د بېرته راستنېدو لار او د ناکامۍ چلند ناټاکلی پرېږدي۔

یو مستند محصول بېلګه دلته مرسته کوي۔ د Pritunl د تکرار سندونه VPN شبکه د هر تکرار لپاره یوه شی ګڼي، او په بېلو تکرارونو کې کړیګران اړ دي چې یو بل ته ورسیږي، اضافي لارې او اړیکې ته۔ دا د محصول ځانګړی ترتیب دی، د Community OpenVPN لپاره نسخه نه ده، خو ښیي چې ولې د تکرار زیاتول شبکه بدلوي نه یوازې د حساب ذخیره۔

ناسته څه ده: ژوندی حالت، نه کرښه

دریم کتاب ژوندې ناسته ده۔ نښلول شوي کړیګر د هغې غوټې په سر کې چې هغه یې منلی، د پروتوکول حالت او شبکهي ځانګړنه لري۔ دا چې حساب په بله غوټه کې پېژندل کېږي، هغې غوټې ته ناسته، کیلي یا د پاکټونو دوام ورکولو وړتیا نه ورکوي۔

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

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

د درې کتابونو آزموینه

هر یو جلا وآزمویئ۔ د A غوټې له لارې ننوځئ، بیا د B غوټې له لارې، او تایید کړئ چې دواړه د تمه شوو پتو سیمو سره بریالي دي۔ یو هویت بېرته واخلئ او دواړه غوټې وګورئ، نه یوازې هغه چې تصادفاً مو آزموېلي۔ بیا یوه غوټه ودروئ او وګورئ چې کړیګر او خصوصي اپلیکیشن په رښتیا څه کوي۔

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

څو غوټیز حساب ډیزاین یوازې هغه وخت بشپړ دی چې درې واړه کتابونه روښانه مالک، د بدلون لار او د ناکامۍ چلند ولري۔ د غوټو ترمنځ د تنظیم فایل کاپي کول د دې پوښتنو له یوې هم ځواب نه ورکوي۔