د ډومېن پر بنسټ VPN لارښوونه د IP لارو په مقابل کې: کومه مناسبه ده؟
په ویشل شوې تونل بکس کې د کوربه نوم لاره نه ده. د ډومېن قواعد او روښانه مخکښې د تازه کولو، د فرعي ډومېنونو په لمن او د DNS د بدلون پر مهال د پیښېدونکو له مخې پرتله کړئ.
د IP لاره د پتې مخکښې سره سمون لري، او کرنل یې پرته له نورو پوښتنو پلي کوي. د ډومېن پر بنسټ VPN قاعده د نوم سره سمون لري، چې مانا یې دا ده چې په سټک کې باید یو څه پریکړه وکړي چې دا نوم اوس کوم پتې ته اشاره کوي او هغه پریکړه تازه وساتي. دا د بېلابېلو ناکامۍ طریقو سره بېلابېل میکانېزمونه دي، او پلورونکي د دواړو لپاره یوه کلمه کاروي. د دوی پرتله کول په ځانګړنو لیستونو کې اصل مطلب له لاسه ورکوي؛ دوی د هغه څه له مخې پرتله کړئ چې کله ځواب بدل شي پیښیږي.
ګټوره ویش د هغه قاعدې او هغه قاعدې ترمنځ ده چې حل کوي او نه حل کوي.
هره قاعده واقعاً له څه سره سمون لري
د مخکښې قاعده د لارښوونې جدول کې د منزل پتو سره سمون لري. هیڅ شی نه حل کیږي، هیڅ شی نه پای ته رسیږي، او سمون د هر پاکټ لپاره دقیق دی. د ډومېن قاعده د غوښتنلیک د نوم غوښتنې سره سمون لري، کوم چې RFC 1034 د پتې پر ځای د لیبلونو ونې په توګه تعریفوي. ځینې محصولات نوم یو ځل حل کوي او پایله پتې د لارو په توګه نصبوي، چې قاعده د تازه کولو ټایمر سره نښلول شوې IP قاعده جوړوي.
له ډیبګ کولو دمخه پوه شئ چې له دې دواړو کوم یو لرئ، ځکه ناکامي په هر حالت کې بشپړ توپیر لري.
د ډومېن قاعده په سټک کې چیرته ده
که محصول د ډومېن قواعد د سیمه ایز پراکسي له لارې پلي کوي، ترافیک باید هغه پراکسي ته ورسیږي، او هغه غوښتنلیکونه چې د سیسټم پراکسي له پامه غورځوي قاعده په بشپړه توګه پریږدي. که یې د نومونو د حل او لارو د زیاتولو له لارې پلي کوي، پتې یوازې د وروستي تازه کولو په اندازه تازه دي. که د حل کوونکي سره نښلوي، د DNS چلند د لارښوونې پالیسۍ برخه کیږي، او یو بدیل حل کوونکی کولی شي په چوپتیا یې لغوه کړي.
د ترتیباتو لیبل نه، د پلورونکي ماډل ولولئ. دوه کلاینټان چې د Split Tunnel په نوم بکس لري ممکن درې بېلابېل کارونه وکړي.
پرتله کړئ چې څه مات کیږي
درې شیان په بېلابېلو ډولونو مات کیږي. د پتو بدلون: د CDN کوربه نوم کولی شي په څو دقیقو کې بل پتې ټولګې ته حل شي، نو کاپي شوې لیست ژر زوړ کیږي. د فرعي ډومېن لمن: د example.com لپاره قاعده ممکن api.example.com پوښي یا یې نه پوښي، او مستندات معمولاً روښانه وي چې کوم یو. د حل ناکامي: کله چې حل کوونکی ناکام شي، حل کوونکی کلاینټ ممکن د ترافیک تونل کولو یا مستقیم لیږلو ته ورسیږي.
یوازې دوهمه د ترتیباتو پوښتنه ده. نور دوه د ډیزاین پوښتنې دي چې محصول څومره اټکل کولو ته تیار دی.
| Behaviour | Prefix rule | Domain rule |
|---|---|---|
| Match basis | destination address | requested name or resolved addresses |
| Staleness | none | depends on refresh policy |
| Subdomain scope | not applicable | product-defined |
| Resolver outage | unaffected | product-defined fallback |
| Where to debug | routing table | client log plus resolver state |
کله چې مخکښه غوره ځواب وي
د یوې باثباته خصوصي فرعي شبکې لپاره روښانه مخکښه روښانه تر، ژرتر او د پلټنې لپاره اسانه ده. دا د حل کوونکي د بندښت هم زغملای شي، ځکه هیڅ شی باید حل نشي. د ډومېن قاعدې ته مخه کړئ کله چې خدمت کوربه شوی وي، کله چې پتې څرخي، یا کله چې واقعاً د منزل ټولګه نشئ شمیرلی. یوازې د دې لپاره چې کوربه نوم هغه شی دی چې تاسو یې ناڅاپه پوهیږئ، دې ته مخه مه کوئ.
اټکل شوې ثابته لیست د دواړو تر ټولو بد ده: د ساتنې وړ ښکاري، او هغه ورځ چې عرضه کوونکی کوربه زیاتوي په چوپتیا ترافیک له لاسه ورکوي.
د نوې غوښتنې سره تایید کړئ
له نورمالې بیا نښلونې وروسته د سړې غوښتنې سره ازموئ، ځکه کیش شوې پاڼه ممکن هیڅکله قاعده ته ونه رسیږي. نوم حل کړئ، بیا وګورئ چې نښلون واقعاً چیرته لاړ. dig +short app.example.com اوسنی پتې ټولګه درکوي، او د کلاینټ د نښلونونو لیست تاسو ته وایي چې کوم انټرفیس جریان یوړ.
د محصول د مستند شوې تازه کولو وقفې وروسته بیا تکرار کړئ. که پتې ټولګه ځای بدل کړي او قاعده یې تعقیب نه کړي، تاسو ریښتینی چلند موندلی دی.
د حل کوونکي پالیسي هم جلا وساتئ. د ډومېن قاعده سم نوم معلوماتو ته اړتیا لري، مګر پخپله نه پریکړه کوي چې کوم حل کوونکی پوښتنې ته ځواب وایي.