ရှာဖွေမှုကျရှုံးသည့်နေရာတွင် DNS ကို စစ်ဆေးပါ။ သင့်လက်ပ်တော့က အမည်တစ်ခုကို ဖြေရှင်းနိုင်ခြင်းသည် Squid သို့မဟုတ် နောက်ဆက်တွဲချိတ်ဆက်မှုလုပ်သည့် အထက် proxy ကလည်း ဖြေရှင်းနိုင်ကြောင်း မသက်သေပြပါ။

ချို့ယွင်းနေသော instance ၏ cache log ကို ဖတ်ပြီး server ၏ resolver ဆက်တင်များကို စစ်ဆေးပါ။ host အဆင့် အထောက်အကူပြုစစ်ဆေးမှုမှာ—

getent ahosts target.example

တကယ့်ပစ်မှတ်ကို သုံးပါ။ getent သည် host ၏ အမည်ရှာဖွေရေးစနစ်ကို သုံးသည်။ Squid ၏ အတွင်း resolver သို့မဟုတ် cache က ကွဲပြားနိုင်သည်။ တူညီသည်ဟု မယူဆမီ အတိအလင်းသတ်မှတ်ထားသော dns_nameservers နှင့် hosts_file input များကို စစ်ဆေးပါ။

Squid 6.13 တွင် အတိအလင်းသတ်မှတ်သော nameserver စာရင်း၌ IP လိပ်စာများ ပါဝင်သည်—

dns_nameservers 192.0.2.53

ဤစာတမ်းသုံးလိပ်စာကို Squid server မှ ရောက်ရှိနိုင်သော အတည်ပြုထားသည့် resolver ဖြင့် အစားထိုးပါ။ သီးသန့်အမည်များအတွက် အဖွဲ့အစည်း၏ resolver လိုနိုင်သည်။ မသက်ဆိုင်သည့် အများသုံး resolver ၏ DNS အမြင်တွင် ထိုအမည်များကို မတွေ့နိုင်ပါ။

လက်ပ်တော့ hosts ဖိုင်ထဲက အမည်ပွားသည် proxy မှတစ်ဆင့်ပို့သော host အမည် request နှင့်အတူ မပါသွားပါ။ ရှာဖွေမှုပြုလုပ်သောစက်တွင် တပ်ဆင်ထားသော Squid ဗားရှင်း၏ hosts_file ဆက်တင် ကို စစ်ဆေးပြီး သက်ဆိုင်သည့်အခါ အထက် proxy ၏ resolver ကိုလည်း ထည့်တွက်ပါ။ TLS အထောက်အထားအတွက် သုံးသည့် host အမည်ကို service နှင့် ကိုက်ညီစေပါ။

ထိန်းချုပ်ထားသော configuration ပြောင်းလဲမှုတစ်ခု ပြုလုပ်ပြီးနောက် syntax စစ်ဆေးကာ ရည်ရွယ်ထားသည့် instance ၏ configuration ကို ပြန်လည်တင်ပါ။ တူညီသော request ကို ထပ်လုပ်ပြီး ၎င်း၏အထောက်အထားကို စစ်ဆေးပါ။ cache ထဲရှိ အပြုနှင့်အငြင်းအဖြေများက ထပ်ခါစမ်းသပ်မှုကို သက်ရောက်နိုင်သည်။ ရှာဖွေမှုအောင်မြင်ပြီးနောက် ချိတ်ဆက်ချိန်ကုန်ဆုံးခြင်းသည် နောက်အဆင့်ရှိ လမ်းကြောင်း သို့မဟုတ် ခွင့်ပြုချက်ပြဿနာဖြစ်သည်။ ယင်းကိုပြင်ရန် DNS ကို ဆက်မပြောင်းပါနှင့်။ server ပြောင်းလဲမှုကို အကဲဖြတ်နေစဉ် client DNS၊ အထက် proxy routing နှင့် proxy protocol တို့ကို မပြောင်းဘဲ ထားပါ။

ဆက်စပ်ဆောင်းပါးများ