DNS هلته وڅېړئ چې پلټنه پکې ناکامېږي. ستاسو لپټاپ چې یو نوم حل کوي، دا نه ثابتوي چې Squid یا هغه لوړه پراکسي چې راتلونکی اتصال جوړوي هم یې حلولای شي.

د ناکامېدونکې بېلګې د کېش لاګ ولولئ او د سرور د نوم حل کوونکي تنظیمونه وګورئ. د کوربه په کچه یوه مرستندویه کتنه دا ده:

getent ahosts target.example

اصلي هدف وکاروئ. getent د کوربه د پلټنې سیستم کاروي؛ د Squid داخلي حل کوونکی یا کېش ښايي توپیر ولري. مخکې له دې چې یو شان یې وګڼئ، په څرګند ډول ورکړل شوي dns_nameservers او hosts_file ورودي معلومات وګورئ.

په Squid 6.13 کې د نوم سرورونو څرګند لېست IP پتې لري:

dns_nameservers 192.0.2.53

د اسنادو دا پته په یوه منل شوي حل کوونکي بدله کړئ چې د Squid له سروره ورته لاسرسی کېږي. خصوصي نومونه ښايي د ادارې حل کوونکي ته اړتیا ولري؛ یو نامرتبط عام حل کوونکی ښايي په خپل DNS لید کې دا نومونه ونه ویني.

د لپټاپ د hosts فایل مستعار نوم د پراکسي له لارې د کوربه نوم له غوښتنې سره نه لېږدېږي. په هغه ماشین کې چې پلټنه کوي د نصب شوې Squid نسخې hosts_file تنظیم وګورئ، او د اړتیا پر مهال د لوړې پراکسي حل کوونکی هم په پام کې ونیسئ. د TLS هویت لپاره کارېدونکی کوربه نوم له خدمت سره برابر وساتئ.

د تنظیم له یوه کنټرول شوي بدلون وروسته نحو وګورئ او د ټاکلې بېلګې تنظیم بیا بار کړئ، هماغه غوښتنه تکرار کړئ او شواهد یې وڅېړئ. په کېش کې مثبت او منفي ځوابونه پر تکراري ازموینو اغېز کولای شي. بریالۍ پلټنه او ورپسې د اتصال د وخت پای ته رسېدل د وروسته پړاو د لارې یا اجازې ناکامي ده؛ د هغې د سمولو لپاره DNS مه بدلوئ. د سرور بدلون د ارزولو پر مهال د پېرودونکي DNS، د لوړې پراکسي لارې او د پراکسي پروتوکول ثابت وساتئ.

اړوندې مقالې