یو TAP سرور که څو؟ په پُل باندې OpenVPN کليانټ

څو TAP کليانټان د هر یو لپاره یوه سرور پروسه، یو UDP پورټ او په کوربه باندې یو TAP وسيله نه غواړي۔ په Ethernet حالت کې یو OpenVPN سرور کولای شي ډېر تصدیق شوي کليانټان ومني او هغوی یوې پُل ته ونښلوي، او د طبقې 2 یوه برخه پراخولو لپاره همدا مستنده لاره ده۔ یوې پروسې ډیزاین هغه دی چې لارښود یې مستند کوي، او معمولاً همدا سم ډیفالټ دی۔

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

دوه معماریانې، نه دوه تنظیمونه

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

پُل شوې TAP ځای پرځای کول کليانټان د یوې Ethernet برخې غړي ګرځوي۔ دوی خپرېدنې ویني، کولای شي یو بل د ARP په مرسته ومومي، او د جلا پاتې کېدو لپاره پر لارښوونې پرځای د پُل او اور وژونکي پالیسۍ تکیه کوي۔ دا هغه وخت ګټور دی چې کليانټان باید داسې ښکاره شي لکه په هماغه سوئیچ کې نښلول شوي۔

نو پرتله د دې په اړه ده چې کليانټان باید چېرته ورسېږي، نه د کارکرد په اړه۔ لومړی طبقه غوره کړئ، بیا پرېکړه وکړئ چې څو پروسې به یې خدمت کوي۔

server-bridge مرستندوی څه کوي

server-bridge مرستندوی د څو کليانټانو Ethernet حالت تنظیموي۔ د هغې د پتې حوض بڼه ګېټوې، د شبکې ماسک او د پُل شوې فرعي شبکې دننه ځانګړې سلسله اخلي، د بېلګې په توګه په 192.168.50.1 کې ګېټوې او له 192.168.50.160 څخه تر 192.168.50.199 پورې حوض۔

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

د هغو ځای پرځای کولو لپاره چې بهرنی سرور پتې ووېشي، د DHCP-پراکسي بڼه شته۔ هغې خپل مخکیني شرطونه لري، او د دواړو بڼو ګډول هغه ټکر جوړوي چې اسناد ترې خبرداری ورکوي۔ د پُل شوې فرعي شبکې لپاره یو تخصیص کوونکی غوره کړئ۔

جلاوالی د پروسو له شمېر څخه نه راځي

اته OpenVPN پروسې چې له هماغه بې حده پُل سره نښلول شوې دي، لا هم یو خپرېدنې ډومېن شريکوي۔ کليانټان کولای شي د پُل له لارې یو بل ته ARP ولېږي، او د اورېدونکو شمېر په دې کې هېڅ ونه بدل کړل۔

که غوښتنه دا وي چې د کليانټانو ډلې دې په طبقه 2 کې یو بل ونه ویني، ډیزاین ته جلا پُلونه یا VLAN تړاوونه او له هغو سره مل دسترسي قواعد اړین دي۔ دا د شبکې د ډیزاین پرېکړه ده، او که یوه سرور پروسه وي یا اته، پرېکړه هماغه ده۔ د پُل فلټر کولای شي ځینې ترافیک محدود کړي، خو جلا خپرېدنې ډومېنونه نه جوړوي۔ هغه د برخې وېش بشپړونکی وګڼئ، نه د هغه بدیل۔

که غوښتنه یوازې دا وي چې کليانټان ځینې IP خدمتونو ته ورسېږي، لارښوونکی TUN ډیزاین معمولاً له پُل کولو او فلټر کولو څخه ساده دی۔ هر کليانټ خپل تړاو ترلاسه کوي، او پالیسي د پُل په دننه کې نه، بلکې د لارښوونې او اور وژونکي قواعدو کې ژوند کوي۔

کله څو پروسې بیا هم سمې

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

که څو وکاروئ، هر یو ته خپل اورېدونکی او د وسيلې مالکیت ورکړئ او د پتو سلسلې همغږې کړئ۔ دوه سروران چې دواړه فکر کوي چې په هماغه پُل باندې هماغه حوض د دوی دی، په پای کې به هماغه پته ووېشي۔

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

له انځور باور کولو مخکې پُل او د سرور حالت له روان کوربه څخه ولولئ۔ مهم ترتیبات هغه دي چې کرنل او ډیمون واقعاً بار کړي، او هماغه هم دي چې یو بیاکتونکی یې کولای شي وګوري۔