ستاسو د VPN پول د LAN د DHCP حد نه دی: ولې دا ماتېږي

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

دوه وېشونکي، یوه پته فضا

د LAN DHCP سرور پوهېږي چې کومې پتې یې کوم MAC پتې ته په اجاره ورکړې دي، او د ARP په مرسته یې ساتنه کوي۔ د VPN سرور خپل پول لري او د دې اجارو په اړه څه نه پوهېږي۔ دواړه غلط نه دي؛ یوازې دوی یو بل ته نه دي معرفي شوي۔

له LAN پول څخه ورکړل شوې پته چې VPN سرور یې ویشي کېدای شي لا دمخه د یو پرنټر وي۔ اوس دوه وسایل په یوه پریفکس کې یوې پتې دعوه کوي، او د سویچ د لېږد جدول فیصله کوي چې څوک ځواب ووايي۔

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

ولې روټر د VPN پتې نه ویشي

د DHCP موندنه خپرېدنه ده، او خپرېدنې په روټ شوې پوله کې درېږي۔ که ډیزاین تونل پله نه کړي یا د سم واکمنۍ سره DHCP ریلې ونه چلوي، د کلاینټ غوښتنه هیڅکله LAN سرور ته نه رسېږي۔

نو VPN سرور پخپله پته ټاکي: په سرور تنظیماتو کې یو پول, په WireGuard ترتیب کې د هر ملګري لپاره یوه پته، یا هغه پته چې په IKEv2 ځای پرځای کولو کې د تصدیق طبقې لخوا ټېله کېږي۔ دا میکانیزمونه د LAN د اجارې ډیټابیس څخه خپلواک دي، او همدې له امله ورته خپله حد ته اړتیا ده۔

همدا منطق تشریح کوي چې ولې د DHCP ساحې بدلول هغه VPN کلاینټ نه جوړوي چې هیڅکله پته نه اخلي۔ کلاینټ د LAN سرور نه پوښتنه کوي، او د ساحې هیڅ سمون وه نه شي کولای چې پوښتنه وکړي۔

نښلېدنه د ورو شبکې په توګه نه، د شخړې په توګه ښکاري

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

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

د بیرته راستنیدو لاره جلا ستونزه ده

حتی په پاک او جلا پول سره، د LAN میزبانان باید پوه شي چې کلاینټ ته څنګه ځواب ووايي۔ د دوی اصلي ګېټ وې روټر دی، او روټر ته د پول لپاره هغه مسیر ته اړتیا ده چې VPN سرور ته اشاره کوي، مګر که ډیزاین پرځای یې د کلاینټ ترافیک وژباړي۔

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

دا کمانډونه په ګېټ وې کې د لېږد پرېکړه او هغه ګاونډي ننوتونه ښيي چې دوه ګونې تېروتنه بربنډوي:

ip -4 route get 10.8.0.5
ip neigh show dev br-lan | grep 10.8
ip -4 route get 192.168.50.20

که لومړی کمانډ د تونل انټرفېس سره ځواب ووايي، د بیرته راستنیدو مسیر شته۔ که د LAN انټرفېس سره ځواب ووايي، روټر فکر کوي چې کلاینټ په تار کې دی او به هڅه وکړي د هغه لپاره ARP وکړي۔

پله شوي ډیزاینونه شته، خو باید وټاکل شي

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

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

پرته لدې چې اپلیکیشن واقعاً برخې ته اړتیا ولري، جلا پول سره درېیمه طبقه وټاکئ، او پول مستند کړئ ترڅو بل مدیر د نظم لپاره DHCP حد بیا ونه کاروي۔