د OpenVPN له لارې LAN ته لاسرسی مات شوی؟ زونونه، لارې او د بېرته راتلو لاره وګورئ

تونل د بریالۍ اړیکې راپور ورکوي، د روټر خپله پاڼه بارېږي، خو د هغه تر شا ماشین ته د ډرایو نقشه اخیستنه لا هم د وخت له پای وروسته ناکامه کېږي۔ په دې ترکیب کې هېڅ تضاد نشته: روټر د خپل ځان په توګه ځواب ورکوي، او د هغه تر شا هر څه ته رسېدل په بل ځای کې اخیستل شوې بله پرېکړه ده۔ لاندې کتنې په ترتیب سره ترسره کړئ او په لومړنۍ ناکامۍ کې ودرېږئ، ځکه هر یو پر بل ولاړ دی۔ کله چې څلور واړه تېر شي، ستونزه د تونل له پاس نه ده، په تونل کې نه ده۔

کوم فلټر LAN ته روان پاکټ ویني

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

OpenWrt دا وېش د کتنې وړ ګرځوي، او توپیر د یو ځل لوستلو ارزښت لري۔ هغه زون چې تونل پای ته رسوي، LAN زون ته د لېږد قاعده غواړي، په داسې حال کې چې د ننوتلو قاعده یوازې پر روټر د چلېدونکو خدمتونو کنټرول کوي۔ د فعالې ادارې پاڼې ترڅنګ مړ LAN د همدې ورکې لېږد قاعدې عادي پایله ده۔

uci show firewall | grep -E "zone\[[0-9]+\]\.(name|input|forward|output)"

د تونل د وړونکي زون د لېږد موخه وګورئ: accept هغه څه دي چې زینه ورته اړتیا لري، او reject لاندې هر وخت پای ته رسېدل تشریح کوي۔ دوه ګاونډي تنظیمات ورته نښه جوړوي، نو تر هغه چې دلته یاست، هغه لرې کړئ۔ بې تار جلاوالی تار لرونکي هوسټونه له بې تار کلاینټونو پټوي، او هغه روټر چې غیر فعال LAN هوسټونه افلاین ګڼي، کېدای شي ځوابونه حتی له دې وروسته هم وغورځوي چې لېږد کار کوي۔

ولې ووېشل شوي تونل ته لېږل شوی مختګ اړین دی

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

push "route 192.168.50.0 255.255.255.0"

هغه پروفایلونه چې route-nopull لري، لېږل شوې لارې له پامه غورځوي، نو هماغه مختګ باید په کلاینټ فایل کې وي۔ په هر حال، تصدیق کړئ چې ننوتنه رسېدلې ده، نه دا چې فرض یې کړئ، ځکه غلي بدلون د فایر وال ستونزې سره سم ورته ښکاري۔

ip route show | grep 192.168.50

د سایت تر سایت ملګری د لېږلو څخه زیات غواړي۔ سرور باید زده کړي چې د هغه ملګري تر شا کوم مختګونه دي، کوم چې د هغه په client-config-dir فایل کې iroute کرښه کوي، او د هغه خپله جدول ته هم تونل ته د ننوتلو سمون لرونکې لاره اړینه ده۔

ځواب ته داسې پته اړینه ده چې ورته رسېدلی شي

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

tcpdump -ni tun0 host 192.168.50.20

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

هغه زینه چې په سم ځای کې پای ته رسېږي

څلور کتنې پرت پیژني، او هر یو د قضاوت پر ځای یوازې یو حکم دی۔ هغه په ترتیب سره چل کړئ او په لومړنۍ ناکامۍ کې ودرېږئ۔ ترتیب له حکمونو مهم دی، ځکه وروستی تېر شوی ګام د پخواني د ناکامۍ لامل پټوي۔

ping -c1 10.8.0.1
ping -c1 192.168.50.20
nc -vz 192.168.50.20 445
getent hosts nas.local

نومونه د زینې په پای کې وي، هېڅکله په پیل کې نه۔ هغه شریکه چې د 192.168.50.20 په توګه ځواب وایي خو د nas.local په توګه نه، د نومونو حل یا د لټون پسوند ته اشاره کوي، او د فایر وال سمونونه هیڅ یو نه شي بدلولی۔

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