ولې د OpenVPN کلاینټ تر شا شبکه فرعي د لاسرسي وړ نه ده؟

د سرور د تونل پتې ته ping بریالي کیږي، د کلاینټ خپله د لارو جدول سم ښکاري، او د هغه کلاینټ شاته LAN لا هم د لاسرسي وړ نه ده۔ د کلاینټ د لارښوونې جدول سم ښکاري، سرور د تونل په لور یوه لار لري، او پیکټونه لا هم ورک کیږي۔ دا د layer-3 تونل کلاسیک نښه ده چې نه پوهیږي یو له کلاینټونو څخه پخپله ګیټوې هم دی۔

tun انټرفیس د هر کلاینټ لپاره بله ورځ نه لري۔ کرنل ډېر همکاران لرونکی یو واحد انټرفیس ویني، نو د لیرې LAN لپاره د کوم کلاینټ پیکټ ترلاسه کول باید د OpenVPN پروسې دننه پرېکړه شي۔ هغه پرېکړه د iroute له مخې تنظیمیږي، او پرته له هغې پیکټ د تلو ځای نه لري۔

سرور د انټرفیس له مخې نه، د کلاینټ له مخې لارښوونه کوي

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

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

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

د کلاینټ نوم اخېستونکې iroute نوملیکنه لیکل

iroute د سرور په اصلي تنظیم کې نه، بلکې په کلاینټ ځانګړي تنظیم فایل کې اوسیږي۔ سرور د client-config-dir اختیار سره یوې پوښۍ ته وګرځوئ، بیا داسې فایل جوړ کړئ چې نوم یې د کلاینټ د سند عام نوم وي او مخکښه برخه پکې کیږده۔

هغه څانګې لپاره چې LAN یې 10.20.0.0/24 دی او د سند عام نوم یې branch-router دی، په هغه لار کې فایل لکه iroute 10.20.0.0 255.255.255.0 کرښه لري۔ اصلي تنظیم یوازې د پوښۍ اختیار ته اړتیا لري؛ مخکښه برخه د کلاینټ سره اوسیږي۔

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

یو کلاینټ کولای شي څو مخکښې برخې ولري۔ د هرې شبکې لپاره یوه iroute کرښه زیاته کړئ او لیست د هغه کلاینټ د نورو تنظیماتو ترڅنګ وساتئ ترڅو نقشه کول د پلټنې وړ پاتې شي۔

د بیرته راستنیدو لار په دواړو خواو کې جوړول

پیکټونه لیرې LAN ته رسول نیمایي کار دی۔ کلاینټ باید د هغې LAN ترافیک هم تونل ته واستوي، چې معمولاً د کلاینټ ته د لارې ټېل وهلو سره کیږي: د push "route 10.8.0.0 255.255.255.0" په څېر کرښه هر کلاینټ ته وایي چې د سرور اړخ شبکې ته څنګه ورسیږي۔ د څانګې لپاره، معادل لار د سرور اړخ هغه هر څه ته چې باید ورسیږي تونل ته اشاره کوي۔

د بیرته راستنیدو خوا لیرې اړخ کې مالک ته اړتیا لري۔ په هغه اړخ کې څوک باید د بیرته تلو لار وپېژني: په LAN راؤټر کې ثابته لار چې VPN حوض سرور ته اشاره کوي، یا د ترافیک له LAN ته ننوتلو مخکې په سرور کې د پتو ژباړه۔ ثابته لار اصلي پتې په لاګونو او د لاسرسي قواعدو کې ښکاره ساتي خو د LAN مالک همکاري غواړي؛ ژباړه پخپله بسنه کوي خو پټوي چې واقعاً څوک نښلېدلی۔

لیږد باید په سرور کوربه کې فعال وي۔ پرته له هغې کرنل له تونل څخه پیکټ مني او د LAN انټرفیس ته د تېرولو څخه انکار کوي، چې د کلاینټ له نظره د ورک iroute په څېر ښکاري۔

د لاسرسي وړتیا د سمې ازموینې سره کتل

د لیرې پای ته ping کولو او اټکل کولو پرځای په طبقو کې ازموینه وکړئ۔ له سرور څخه وګورئ چې د مخکښې برخې لپاره داخلي نقشه شته او د کرنل لار تونل ته اشاره کوي۔ له کلاینټ څخه تایید کړئ چې ټېل وهل شوې لار نصب ده او د LAN پتې لپاره یې اصلي لار تونل دی۔

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

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