AdGuard Home د WireGuard مراجعینو ته ستاسو د LAN پته څخه ځوابونه ورکوي

سرنګ پورته دی، فایروال په پورټ 53 اجازه ورکوي، AdGuard Home روان دی، او بیا هم د وایرګارډ کلاینټ لپاره نومونه نه حل کېږي. پوښتنه عموماً رسیږي او ځواب عموماً ځي، نو په حلګر کې د پاکټ شمېرونکي سالم ښکاري او خدمت بې ګناه ښکاري. هغه څه چې غلط کېږي د دې ځواب سرچینې پته ده: دا د محلي پتې څخه ځي چې کلاینټ هیڅکله نه ده غوښتې، او د کلاینټ سټب حلګر دا ردوي. په AdGuard Home کې یوه لست دا پرېکړه کوي، او عموماً د دې معمولي ډیفالټ پرېکړه کرنل ته سپاري.

پوښتنه رسیږي، ځواب له بل ځایه ځي

یو پیرودونکی چې د 10.6.0.1 په توګه خپل ریزولور تنظیم شوی وي، یو UDP غوښتنه 10.6.0.1 پورټ 53 ته لیږي. هغه پاکټ د تونل څخه تېرېږي او پر کوربه ځي، او AdGuard Home ورته ځواب ورکوي. په تار کې، په هرصورت، ځواب یو نوی پاکټ دی چې د هغه سرچینې پته د کوربه د سټیک لخوا ټاکل کیږي، نه د پیرودونکي تمې لخوا.

کله چې د پیرودونکي ریزولور یو تړلی ساکټ وي، چې همدا هغه څه دي چې systemd-resolved، dnsmasq او ډیری سټب ریزولورونه کاروي، نو یوازې د هماغه پته څخه ځوابونه مني چې ورته لیږل شوي وي. د 192.168.1.10 څخه سرچینه لرونکی ځواب چې د 10.6.0.1 ته لیږل شوې غوښتنې لپاره وي، د کومې پارس کولو دمخه غورځول کېږي. ریزولور د بریالي ځواب لاګ کوي، پیرودونکی د وختOut لاګ کوي، او دواړه ریښتیا وایي.

نو کانټرونه درواغ نه وایي او مشتری هم درواغ نه وايي. هغه شواهد چې تاسو ورته اړتیا لرئ په درې ځایونو کې دي، په دې ترتیب: هغه پته چې اوریدونکی ورته تړلی دی، هغه لار چې کرنل به د مشتری ته د بیرته تګ لپاره وکاروي، او د اصلي ځواب پاکټ باندې د سرچینې پته.

څنګه کرنل د ځواب سرچینه غوره کوي

یو UDP ساکټ چې تړلی وي0.0.0.0خپله سرچینه پته نه لري، نو هر وتونکی ځواب د رسید ځای لپاره د لارې لټون رامینځته کوي. کرنل بیا د دغه لارې څخه سرچینه اخلي: هغه پته چې د لارې لخوا ټاکل شوې، یا د وتونکي انترفیس اصلي پته. د پوښتنې د رسید پته هیڅ شی نه یاد ساتل کېږي.

په یوه یوازې کوربه کې دا ناپیدا دی، ځکه چې یوازې یو معقول ځواب شته. په یوه ماشین کې چې د LAN پته، د WireGuard پته او د مدیریت پته لري، څو ځوابونه معقول دي، او ګټونکی پر هغه وخت د روتینګ جدول پورې اړه لري. یوه اضافي لار اضافه کړئ، په همدې انترفیس کې دوهمه پته اضافه کړئ، د ریزولر مخې ته NAT ریډایرکټ ترسره کړئ، یا AdGuard په یوه کانتینر کې په خپل نوم ځای کې وچلوئ، او ټاکل شوی سرچینه ممکن له هغه څه توپیر ولري چې مشتری یې پوښتنه کړې وه.

ss -lunp | grep :53ښیي چې تاسو په کومه لوبه کې یاست. په0.0.0.0:53باندې یو اوریدونکی د وایلډکارډ قضیه ده؛ په10.6.0.1:53باندې اوریدونکی لا مخکې ځواب ټاکلی دی. ساکټ لوستل د YAML لوستلو څخه ګړندي دي، او دا هغه څه انځوروي چې په حقیقت کې روان دي نه هغه څه چې وروستی ساتل شوی و.

د bind_hosts اصلي کنټرول څه دی

د AdGuard Homedns.bind_hostsدا د محلي پتې لیست دی چې د DNS اوریدونکی یې کاروي. د نصب شوي ډیفالټ ارزښت وایلډکارډ دی، چې معنی یې دا ده چې په هر محلي پته کې منل کیږي او کرنل ته اجازه ورکوي چې د هر ځواب لپاره سرچینه وټاکي. د وایلډکارډ ځای په ځای کول د هغه پتې سره چې پیرودونکي یې پوښتنه کوي، ساکټ بدلوي، او د دې سره د هر ځواب سرچینه پته هم بدلوي.

لیست کولی شي یوه نه یوازې یو داخلونه واخلي، چې په هغه حالت کې مهم دی کله چې یوه حلونکی دوه شبکې خدمت وکړي. د10.6.0.1او192.168.1.10لیست کول دوه تړلي ساکټونه تولیدوي، او هره پوښتنه چې په دې کې یوه باندې راځي د هغه پتې څخه ځواب کیږي چې دا پرې راغلې. دا هغه چلند دی چې ډیری خلک ګومان کوي چې وایلډکارډ یې مخکې لا چمتو کړی دی.

YAML ساده دی، او په دې کې پته هغه ده چې ستاسو د ټنل پیرودونکو ته د کارولو امر ورکړل شوی و، د کوربه اصلي پته نه:

dns:
  bind_hosts:
    - 10.6.0.1
  port: 53

ولې د یوې حلونکي دوه نصبونه په اختلاف دي

په دې سیاق کې د پلګین لخوا مدیریت شوی، معنی لري چې ریزولور د بلې کڅوړې لخوا نصب شوی او څارل کیږي: د روټر فرم ویئر کڅوړه، د NAS کڅوړه، یا د کور اتومات اضافي بڼه. دغه کڅوړه معمولاً د AdGuard Home د YAML خپله کاپي لري او پروسه په خپله مهالویش کې بیا پیلوي، پداسې حال کې چې یوه جلا بڼه هغه وینډور باینري یا کانټینر دی چې تاسو ځان تنظیموئ. په هر حالت کې، تاسو د دوو خپلواکو پروسو سره مخ یاست چې جلا تنظیمات فایلونه او جلا باینډ انتخابونه لري، حتی که دواړه د ورته اپ سټریم لیست او د ورته فلټر لیستونه ولولي. یو کولای شي ځانګړې ټونل آدرس سره باینډ وکړي پداسې حال کې چې بل د وایلډکارډ میراث کوي، او ویب انٹرفیس له هرې خوا څخه ورته ښکاري.

دغه وجه ده چې "هماغه حل کوونکی د لیږد څخه مخکې کار کاوه" د اوسني تړاو په اړه هیڅ نه ثابته وي. ساکټ وګورئ، بیا هغه ترتیب فایل وګورئ چې روان پروسه یې واقعیا بار کړی دی. په بل ډایرکټري کې یو زاړ کاپي یوه عامه لامل دی چې ایډیټ هیڅ اغیزه نلري.

دا تثبیت کړئ، بیا له تونل اړخه ازموینه وکړئ

بدل کړئbind_hostsته د تونل پتې سره، خدمت بیا پیل کړئ، او تایید کړئ چې ساکټ منتقل شوی دی:ss -lunp | grep :53اوس باید وښيي10.6.0.1:53او هېڅ ځانګړی داخله نه وي. که لا هم وښيي0.0.0.0،روانه پروسه هغه فایل نه لولي چې تاسو یې ایډیټ کړی دی.

بیا د پیرودونکي له خوا ازموینه وکړئ، ځکه چې یوازې دا اړخ مهم دی. یوه پوښتنه دdig @10.6.0.1 example.comسره هغه لاره تجربه کوي چې کاروونکی یې تجربه کوي، او په کوربه کې یو نیول شوی فایل دtcpdump -ni wg0 udp port 53په کیبل باندې د ځواب سرچینې پته ښيي. دا د پیرودونکي د حلګر تنظیماتو کې د پتې سره پرتله کړئ؛ کله چې دوی مساوي وي، د وخت ختمیدل نور لوی راز نه وي.

ip route get 10.6.0.2پاتې عجیبه حالت تشریح کوي، ځکه چې دا هغه انٹرفیس او سرچینه چاپوي چې کوربه به بیرته پیرودونکي ته وکاروي. که هغه تولید د LAN انٹرفیس نوم ورکړي، د بایند بدلول ټول حل ندی او د راتلونکي کار د لارې جدول لوستلو ته اړتیا لري.

هغه څه چې د بایند تنظیم یې حل نشي کولی

د اوریدونکي تثبیت کول د لاسرسي لیست چې ټنل سب نیټ پریږدي، د فایروال قاعده چې پوښتنه اجازه ورکوي خو ځواب نه ورکوي، یا د WireGuard پول ته د بیرته مسیر نه شتون نه سموي. هغه مخکې یا وروسته د سرچینې پتې ناکام کیږي، او هر یو مختلف مالک لري.

دا هم نه بدلويکوم ته چې حلګر مخکینیانې واستويکه د بیا بایند پروتکشن د شخصي نوم لپاره شخصي ځواب ردوي، یا مشتری خپل د لټون ډومینونه څنګه پلي کوي. دا جلا کنټرولونه دي. کله چې د ځواب سرچینه غلطه وي، د بایند پته بدل کړئ، او کله چې نه وي، نو بل څه بدل کړئ.