په dnsmasq کې ستاسو VPN ډومین زون لیږد نه دی
یو پش شوی ډومین تګلاره ده، د زون فایل نه، او په resolv.conf کې localhost سم کېدای شي۔ منله شوې تنظیم تعقیب کړئ تر هغه backend پورې چې واقعاً چلېږي۔
تاسو د کلینټ په dnsmasq تنظیماتو کې کارپوریټ زون لټوئ، نه یې پیدا کوئ، او نتیجه اخلئ چې VPN خپل ډومین پش نه کړ۔ هغه څه چې پش شول د لارښوونې نښه ده، زون نه۔ کلینټ ډومین او هغه resolver ثبتوي چې باید د هغه لپاره ځواب ووايي، او مدیریت شوی backend هغه په شرطي لېږد بدلوي۔ په غلط ځای کې کتل یو باوري او په بشپړ ډول غلط تشخیص ورکوي۔
هغه څه چې کلینټ ومنل هغه نه دي چې ګیټ وې وړاندې کړي وو
ګیټ وې کولای شي یو resolver، یو ډومین او هغه لار وړاندې کړي چې د دې resolver ته رسېدو لپاره اړینه ده، او کلینټ کولای شي درې واړه یا هېڅ یو ومني۔ یو وارد شوی پروفایل، مرستندوی سکریپټ یا د پش شوو انتخابونو په پام کې نه نیولو تګلاره کولای شي منل شوی ټولګه تشه پرېږدي په داسې حال کې چې د سرور خوا سمه ښکاري۔ د سرور له تنظیماتو پرځای د کلینټ له ثبت شوې حالت پیل کړئ، ځکه چې resolver په حقیقت کې هغه حالت ترلاسه کوي۔ که منل شوی ډومین نه وي، نور هر څه به مهم نه وي۔ د هر کیشې د کتلو دمخه د اړیکې DNS ځانګړنې وګورئ۔
دا توپیر د هغه ډومین د ډېرو راپورونو وضاحت کوي چې هېڅکله ونه رسېد۔ هغه وړاندې شو، او پلي نه شو۔
د ډومین دوه ډوله ننوتل
یوه اړیکه کولای شي عادي پلټنې ډومینونه او یوازې-لار ډومینونه ولېږدوي، او دویم ډول د ټیلډ سره پیلېږي۔ د پلټنې ډومین پوښتنې مسیر کوي او لنډ نومونه پراخېدو ته اجازه ورکوي، چې په کاري سټیشن کې اسانه او په سرور کې حیرانونکې ده۔ یوازې-لار ډومین وايي چې د هغه پسوند پوښتنې باید پرته له دې چې لنډ نومونه څنګه حل شي مشخصو سرورونو ته ځي۔ یو ډومین په دواړو لارو لیکل زیاتوالی نه دی، ځکه دواړه ننوتل جلا کارونه کوي۔
د شخصي نوم فضا لپاره معمولاً یوازې-لار بڼه غواړئ۔ هغه کارپوریټ پسوند کارپوریټ resolver ته متوجه ساتي او نور هر څه په خپل حال پرېږدي۔
په resolv.conf کې localhost تېروتنه نه ده
کله چې سیمه ییز کیشینګ resolver کارول کېږي، د سیسټم فایل یوازې loopback پتې ته اشاره کوي او نور هيڅ ته نه۔ هغه ننوتل سیمه ییز اورېدونکی پیژني، نه هغه پورته سرورونه چې مدیر هغه ته ورکړي دي۔ کارپوریټ پته به په فایل کې قانوناً نه وي۔
هغه ننوتل په عامه resolver بدلول کلاسیک غلط اصلاح ده۔ دا عامه نوم حل بېرته راوړي او په هماغه سمون کې شرطي تګلاره پرېږدي۔
backendونه سره ګډ مه کوئ
مدیریت شوی dnsmasq بېلګه او د سیسټم resolver جلا پروګرامونه دي چې جلا تنظیمات او جلا د حالت لیدونه لري۔ د یو لپاره د حالت امر د بل په اړه هېڅ ګټور نه وايي۔
وټاکئ چې مدیر کوم backend کارولو ته تنظیم شوی، بیا د هغه backend جوړ شوی تنظیم ولولئ، نه هغه فایل چې په اتفاق سره شته۔ مدیر خپل د بېلګې تنظیم لیکي او د هغې بېلګې لپاره دودیز انتخابونه ملاتړ کوي، نو د یو ناتړلي نړیوال فایل سمول هېڅ نه بدلوي او د بې اغېزې بدلون په څېر ښکاري۔ په 53 پورټ کې دویم ډیمون پیلول له بې ګټې هم بدتر دی، ځکه اوس دوه پروګرامونه په دې نه یوځای کېږي چې پورټ د چا دی۔ لومړی مالک څرګند کړئ، بیا هغه ځای سم کړئ چې مالک یې لولي۔
د نوم فضا ازموینه وکړئ، نه یوازې ځواب
د اپلیکیشن د عادي لارې له لارې یو اجازه لرونکی شخصي نوم او یو عامه کنټرول نوم وپوښتئ۔ کارپوریټ سرور ته مستقیمه پوښتنه ثابتوي چې ریکارډ شته؛ دا نه ثابتوي چې کلینټ هغه سرور غوره کړی۔ دویمه پوښتنه هغه ده چې تګلاره ازموي۔
بیا د بیاځلي نښلېدو او د پرېکېدو وروسته تکرار کړئ۔ اړیکه باید د اړیکې د ژوند دورې پیروي وکړي، او شخصي نومونه باید د تونل نه شتون پر مهال حل کېدل بند کړي، نه دا چې هماغه پسوند ته ځواب ویونکي عامه resolver ته بېرته ولوېږي۔ که بېرته ولوېږي، تاسو یو تېښته موندلې ده، چې له ماتې پلټنې څخه جلا نیمګړتیا ده۔ ولیکئ کوم backend چلېده، کوم ډومینونه پلي شول، او هرې پوښتنې څه بېرته راوړل۔