mDNS د VPN دننه: ولې .local نومونه نه حل کېږي

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

وګورئ نن څه حل کېږي او څه یوازې حل شوي ښکاري

لومړی دوه پوښتنې جلا کړئ: د کوربه نوم لپاره unicast پوښتنه د حل کوونکي څخه پوښتي، په داسې حال کې چې _ipp._tcp لپاره لټون له سیمه ییز لینک څخه پوښتي۔ په Linux کې، avahi-browse -a ښیي چې مالتیکاسټ DNS څه لیدلی شي، او resolvectl query name.local ښیي چې د حل کوونکي سټک له هغه نوم سره څه کوي۔ په macOS کې، dns-sd -B _ipp._tcp مخکې له ادرس اړتیا پرته کشف شوي خدمتونه لیستوي۔

که پته ځواب ووایي او نوم نه، لارښودنه کار کوي او کشف نه کوي۔ د .local نوم کولی شي په خپل کوربه کې هم د nss-mdns له لارې ځواب شي پرته له دې چې avahi-browse نصب وي، نو د هغه نوم لپاره بریالی getent یا پینګ دا ثبوت نه دی چې کشف تونل تېر کړی؛ د لټون پایله او د حل کوونکي پایله جلا جلا شواهد دي۔ اپلیکیشنونه هغه څه کیش کوي چې کشف کړي یې دي، نو ځکه نیمګړتیا ډېری وختونه له نښلولو وروسته ساعتونه ښکاري، نه د نښلولو پر مهال۔ اپلیکیشن بند او بیا پرانیزئ، بیا وګورئ چې کیش شوې ننوتنه نوم لري که پته، ځکه پته د کشف له درېدو وروسته هم اوږد وخت کار کوي۔

ولې پوښتنه هېڅکله تونل نه تېرېږي

مالتیکاسټ DNS پوښتنې 224.0.0.251 ته، د سیمه ییز شبکې کنټرول بلاک دننه، د UDP پورټ 5353 له لارې لیږي۔ روټرونه د هغه بلاک پتې نه رالیږي، نو پوښتنه په هغه لینک کې پاتې کېږي چې هغې ته لیږل شوې وه۔ لیږونکي هم IP TTL یا د IPv6 د ټوپ حد 255 ته ټاکي تر څو ترلاسه کوونکی هغه پاکټ رد کړي چې لا دمخه روټر تېر کړی؛ پروتوکول د لینک څخه بهر جعل دې ته ورته کشف کوي، نه دې ته ورته سیمه ییز پاتې کېږي۔ سیمه ییزتوب د هدف له پتې راځي، نه د یو ټوپ TTL څخه۔

د تونل ډول هم مهم دی۔ د tun سټایل انټرفیس یوازې IP پاکټونه وړي او نور هېڅ نه، نو هېڅ مالتیکاسټ ګروپ له هغې نه ژغورل کېږي۔ د tap سټایل پل خپله خپرېدونکې سیمه پراخوي، نو ځکه ځینې زاړه ډیزاینونه د لارښودنې پر ځای پل جوړول، او هر هغه ستونزه چې پل راوړي یې میراث وګرځېده۔

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

داسې نوم ایښودل وټاکئ چې ساتلی یې شئ

د شرکت سرچینو لپاره دوامداره ځواب یو لارښود شوی کوربه نوم دی چې هغه حل کوونکی یې خدمت کوي چې VPN یې ټېله کوي، د وویشل شوي DNS سره تر څو داخلي نومونه داخلي سرورونو ته لاړ شي او نور هر څه نه۔ Windows دا د نوم حل پالیسي جدول په توګه ښیي، macOS د هر انټرفیس لپاره محدود حل کوونکي کاروي، او ډېری کلینټونه ورته ټېله تنظیم لري۔ وسیله په داخلي DNS کې خپل عادي نوم ساتي، او کشف د لارې برخه کېدل بندوي۔

د کشف پراکسي یا mDNS انعکاس کوونکی کولی شي دا تشه پل کړي، او دا ریښتینی ډیزاین دی چې خپل کوربه، خپله ښکارېدنه او خپل کلینټ اړتیاوې لري۔ دا نه ښکاري ځکه چې تاسو لاره اضافه کړه۔ هېڅکله .local پوښتنې عامه حل کوونکي ته مه رالیږئ: ډومین د RFC 6762 له مخې د سیمه ییز مالتیکاسټ کارونې لپاره ساتل شوی، او د هغې بهر ته لیږل ورو نیمګړتیاوې او غیرضروري معلومات افشا کوي۔

خدمت وګورئ، نه نوم

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

کشف نومونه په یرغلګر ډول کیش کوي، نو زوړ ننوتل ممکن بریالیتوب ښکاري۔ که سند یا تصدیق غوښتنه ښکاره شي، هغه بله طبقه او جلا ستونزه ده۔ ولیکئ کوم میکانیزم مو بدل کړ، حل کوونکی که کشف، تر څو بل کس اړ نه وي ټوله پوښتنه بیا پرانیزي۔