ولې د نومونو پوښتنې د OpenVPN د لارښوونکي تونل له لارې ناکامېږي

کوربه ping ته په پته ځواب وایي او په هر نومیزه پوښتنه کې ناکامېږي۔ تونل پورته دی او لاره شته، نو طبیعي پایله دا ده چې VPN سم نه دی تنظیم شوی۔ ډېره ګټوره پایله دا ده چې هغه پوښتنه هیڅکله د لارښوونې وړ نه وه: لارښوونکی تونل unicast IP وړي، خو پوښتنه خپرېدنه وه چې د بلې خوا نه شته برخې په لټه کې وه۔ کله چې د طبقو ناسم والي ښکاره شي، حلونه پخپله د لګښت له مخې ځای پرځای کېږي۔

افسانه: تونل خراب دی ځکه نومونه ناکامېږي

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

هغه ته د تونل د خرابۍ په سترګه کتل د پروفایل هغو بدلونونو ته رسوي چې مرسته نشي کولی۔ د انتخابونو زیاتول، د کوډ کولو بدلول یا د مراجع بیا نصبول خپرېدنه هماغه ځای پرېږدي چې وه۔

د حل له نومولو دمخه د هغه میکانیزم نوم واخلئ چې ناکام شو۔ هغه پوښتنه چې خپرېدنه کاروي برخې ته اړتیا لري، خو هغه پوښتنه چې حل کوونکی کاروي د پوښتلو لپاره پتې ته اړتیا لري۔

TUN څه وړي او څه نه وړي

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

د کشف ترافیک په دغه ماډل کې هېڅ نه ځایېږي۔ د Windows زاړه نوم پوښتنې، SSDP اعلانونه او mDNS غوښتنې یوې موخې ته نه، بلکې په برخه کې هر چا ته لېږل کېږي۔ لارښوونکي تړاو کې د لېږلو لپاره «هر څوک» نشته۔ دغه هر میکانیزم شریکه رسنۍ فرض کوي۔

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

پل جوړول د پولې په لرې کولو کار کوي

TAP وسیله فریمونه وړي، او یو پل هغه له ریښتیني LAN برخې سره نښلوي۔ بیا مراجع په هغه برخه کې پته لري او د هغې خپرېدونکی ترافیک اوري۔ همدا لامل دی چې پل جوړول د نوم ستونزه روغوي۔ دا مراجع په پته ورکولو کې پر هغې برخې تکیه هم کوي۔

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

د یوې کوچنۍ لابراتوار لپاره دا منصفانه تبادله ده۔ د خپرېدلې کاري ځواک لپاره لږ تر لږه داسې ده۔

DNS او WINS ته زور ورکول تنګه ترمیم دی

مراجع ته د پوښتلو لپاره ځانګړی ځای ورکړئ۔ dhcp-option DNS او dhcp-option DOMAIN دنننۍ نومونه هغه سرور ته اړوي چې زون پېژني، او هغه Windows مراجع چې لا هم پر NetBIOS تکیه دی په همدې توګه WINS سرور ترلاسه کولی شي۔ تونل لارښوونکی پاتې کېږي او برخه خپل ځای ته پاتې کېږي۔

دوه شرطونه فیصله کوي چې دا به کار وکړي که نه۔ ذکر شوی سرور باید د زون لپاره ځواب ووایي، او پوښتنې ته باید د تونل له لارې اجازه وي۔

حل کوونکی له مراجع څخه وآزمویئ، نه د سرور له خپل شل څخه۔ هغه حل کوونکی چې په سیمه ییزه توګه کار کوي د تونل د وړلو شيانو په اړه هېڅ نه وایي۔

ومومئ چې کومه طبقه ناکامه شوه

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

Multicast د هماغه دیوال شاته دی۔ 224.0.0.251 په څېر ټولګه په تلواليزه توګه د لارښوونکي تونل له لارې نه لېږل کېږي، او د ټولګې لپاره لاره کافي نه ده پرته له multicast پوهېدونکې لارې یا په LAN کې له انعکاس کوونکي۔