ولې د LAN کوربه د OpenVPN کلینټ پتې لپاره ARP لیږي

د LAN کوربه او VPN کلینټ ترمنځ د لاسرسي ستونزې ډېری وختونه خپلې پتې پلان ته ورګرځي۔ دغه کوربه ته پر 10.0.100.0/22 یو انٹرفیس ورکړئ او هغه به له 10.0.100.0 څخه تر 10.0.103.255 پورې هره پته مستقیمه نښلول شوې وګڼي، په شمول هغه کلینټ ټولګه چې په غلې 10.0.101.0/24 کې ځای پرځای شوې ده۔ ځواب هېڅکله روټر ته نه ځي، ځکه د کوربه له نظره هېڅ روټر نه برخه اخلي۔ پاکټ ګاونډي ته خطاب شوی او پر تار غوښتل کیږي۔

دا میکانیزم د راپورونو د یوې بشپړې کورنۍ شاته دی: تونل فعال دی، سرور روټ لري او د LAN کوربه بیا هم کلینټ ته نه رسي۔

هغه /22 چې /24 تېروي

مخکښه د رینج په توګه ولولئ، نه د سټرنګ په توګه۔ یو /22 1024 پتې لري او 10.0.100.0/22 له 10.0.100.0 څخه تر 10.0.103.255 پورې غځیږي، نو په 10.0.101.0/24 کې ټولګه په بشپړه توګه د هغې دننه ده۔ تېروتنه له بیاکتنې ژوندۍ پاتې کیږي ځکه د ټولګې لومړني اکتېټونه د LAN له لومړنیو اکتېټونو توپیر لري او یوازې دریم اکتېټ د دې دننه والی ښکاره کوي۔ دواړه رینجونه په عددونو ولیکئ مخکې له دې چې دواړه جلا اعلان کړئ۔

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

مستقیمه اړیکه ARP مانا لري، نه روټینګ

کله چې د /22 انٹرفیس لرونکی کوربه 10.0.101.25 ته لیږي، کرنل منزل د انٹرفیس مخکښې سره پرتله کوي او سمون مومي۔ پاکټ د روټ شوي پاکټ پرځای د ګاونډي پلټنه کیږي، او په ایتھرنیټ کې د ګاونډي پلټنه د هغې پتې لپاره ARP غوښتنه ده۔ که پته د روټ شوي ګېټوې په شا کې د VPN کلینټ وي، په LAN کې هېڅ کوربه یې مالک نه دی، نو غوښتنه بې ځوابه پاتې کیږي او پاکټونه غورځول کیږي۔ تونل ګناه نه لري، او کلینټ هېڅکله ترافیک نه ویني۔

له همدې امله ناکامي غیر متوازنه او کله ناکله پرې شوې ښکاري۔ VPN کوربه ډېری وختونه LAN ته رسي ځکه د هغه خپل روټونه سم لوري ته اشاره کوي، په داسې حال کې چې LAN کوربه ځواب نه شي ویلی، او هر څه چې زوړ ARP اندراج کیش کړي نښه جھلملي کوي۔

TUN، TAP او هر یو څه وړي

TUN وسیله IP پاکټونه وړي او TAP وسیله ایتھرنیټ چوکاټونه وړي۔ روټ شوې TUN اړیکه اړ نه ده ARP ووړي ترڅو IP لاسرسی برابر کړي، او همدا لامل دی چې پورتنۍ بې ځوابه غوښتنه تمه کیږي، نه خرابه۔ TAP د قصدي پول سره کولای شي نشریاتي ډومین پراخ کړي او ARP چل کړي، خو بدلوي چې کلینټ څه لیدلی شي، داسې سرونه غواړي چې هماغه چوکاټ بندي ملاتړ کړي، او د شبکې ماډل بیاډیزاین دی نه د یوې متداخلې مخکښې ترمیم۔ د پتې پلان د تېروتنې درملنې لپاره روټ شوې ګمارنه TAP ته اړول کوچنۍ ستونزه په لویه بدله کوي۔

مخکې له دې چې پایلې واخلو، ولیکئ چې ARP غوښتنه چېرې ښکاره شوه او کوم سیستم یې ولیږله۔ لیږونکی تاسو ته وایي چې د منزل په اړه څه فکر کوي، نه دا چې تونل څه کوي۔

داسې ټولګه ډیزاین کړئ چې متداخله نه شي

له هرې نښلول شوې مخکښې او هرې اعلان شوې سایټ مخکښې بهر ټولګه وټاکئ، بیا هغه روټونه ورزیات کړئ چې دا دواړو خواوو ته لاسرسي وړ کوي۔ د پلان په نه کارول شوې برخه کې 10.8.0.0/24 ته ورته رینج فکر کول اسانه دي، او هغه LAN چې باید ورته ورسي د VPN سرور ته اشاره کوونکی سټاتیک روټ ترلاسه کوي۔ تخصیص، اعلان شوي روټونه، اجازه ورکړل شوې سرچینې پتې او د اور مخ محافظتي قواعد یوځای بدل کړئ، ځکه دوی یو ډیزاین بیانوي نه څلور تنظیمات۔

پر سرور Source NAT کولای شي ټولګه د LAN څخه د روټ وړ پتې شاته پټه کړي، او دا د کډوالۍ قانوني اوزار دی۔ هغه سرچینه هم بیا لیکي، نو LAN د اړیکو د انفرادي کلینټونو سره تړاو ورکولو او د هر کلینټ لپاره د قواعدو پلي کولو وړتیا له لاسه ورکوي۔

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