AdGuard Home به کلاینت‌های WireGuard از آدرس LAN شما پاسخ می‌دهد

تونل فعال است، دیوار آتش پورت 53 را مجاز می‌داند، AdGuard Home در حال اجرا است، و با این حال نام‌ها همچنان برای کلاینت WireGuard حل نمی‌شوند. پرس‌وجو معمولاً می‌رسد و پاسخ معمولاً ارسال می‌شود، بنابراین شمارنده‌های بسته روی حل‌کننده به نظر سالم می‌آیند و سرویس بی‌گناه به نظر می‌رسد. چیزی که اشتباه می‌رود، آدرس مبدا در آن پاسخ است: از یک آدرس محلی که کلاینت هرگز درخواست نکرده خارج می‌شود و حل‌کننده موقت کلاینت آن را دور می‌اندازد. یک فهرست در پیکربندی AdGuard Home این را تعیین می‌کند، و پیش‌فرض معمولی آن تصمیم را به کرنل می‌سپارد.

پرس‌وجو می‌رسد، پاسخ از جای دیگری ارسال می‌شود

یک مشتری که 10.6.0.1 را به عنوان حل‌کننده خود تنظیم کرده است، یک پرس‌وجوی UDP به پورت 53 آدرس 10.6.0.1 ارسال می‌کند. آن بسته از تونل عبور می‌کند و به میزبان می‌رسد و AdGuard Home به آن پاسخ می‌دهد. اما روی کابل، پاسخ یک بسته جدید است که آدرس مبدأ آن توسط پشته میزبان انتخاب شده است، نه طبق انتظار مشتری.

وقتی حل‌کننده مشتری یک سوکت متصل است، که همان چیزی است که systemd-resolved، dnsmasq و اکثر حل‌کننده‌های کوتاه استفاده می‌کنند، تنها پاسخ‌هایی را می‌پذیرد که دقیقاً از همان آدرسی که به آن ارسال شده‌اند آمده باشند. پاسخی که از 192.168.1.10 به پرس‌وجویی که به 10.6.0.1 ارسال شده است برسد، قبل از هر تحلیل کنار گذاشته می‌شود. حل‌کننده یک پاسخ موفق را ثبت می‌کند، مشتری یک تایم‌اوت را ثبت می‌کند و هر دو حقیقت را می‌گویند.

بنابراین کانترها دروغ نمی‌گویند و مشتری هم دروغ نمی‌گوید. شواهدی که نیاز دارید در سه مکان موجود است، به این ترتیب: آدرسی که شنونده به آن متصل است، مسیری که کرنل برای بازگشت به مشتری استفاده می‌کند، و آدرس منبع روی بسته پاسخ واقعی.

چگونه کرنل منبع پاسخ را انتخاب می‌کند

یک سوکت UDP که به0.0.0.0متصل است، آدرس منبع خاص خودش را ندارد، بنابراین هر پاسخ خروجی باعث جستجوی مسیر برای مقصد می‌شود. سپس کرنل منبع را از آن مسیر می‌گیرد: آدرسی که مسیر تعیین کرده است، یا آدرس اصلی رابط خروجی. هیچ چیزی درباره آدرس مقصد پرس‌وجو به خاطر سپرده نمی‌شود.

در یک میزبان تک‌خانه‌ای این نامرئی است، زیرا تنها یک پاسخ محتمل وجود دارد. در ماشینی که یک آدرس LAN، یک آدرس WireGuard و یک آدرس مدیریت دارد، چندین پاسخ محتمل هستند و برنده به جدول مسیریابی در آن لحظه بستگی دارد. اضافه کردن یک مسیر اضافی، یک آدرس دوم روی همان رابط، یک تغییر مسیر NAT جلوی حل‌کننده، یا اجرای AdGuard در یک کانتینر با فضای نام خود، می‌تواند منبع انتخاب‌شده را از چیزی که کلاینت پرسیده است متفاوت کند.

ss -lunp | grep :53نشان می‌دهد که در کدام بازی هستید. شنونده روی0.0.0.0:53حالت wildcard است؛ شنونده روی10.6.0.1:53پاسخ را قبلاً قفل کرده است. خواندن سوکت سریع‌تر از خواندن YAML است و آنچه واقعاً در حال اجرا است را منعکس می‌کند، نه آخرین چیزی که ذخیره شده است.

چیزی که bind_hosts در واقع کنترل می‌کند

AdGuard Home'sdns.bind_hostsاین فهرست آدرس‌های محلی است که شنونده DNS از آن‌ها استفاده می‌کند. پیش‌فرض ارائه شده، کاراکتر عمومی (*) است، که به این معنی است که روی هر آدرس محلی پذیرش انجام شود و کرنل منبع را برای هر پاسخ انتخاب کند. جایگزینی کاراکتر عمومی با آدرسی که مشتریان روی آن پرس و جو می‌کنند سوکت را تغییر می‌دهد و با آن آدرس منبع در هر پاسخ تغییر می‌کند.

این فهرست می‌تواند بیش از یک ورودی داشته باشد، که در یک حل‌کننده که به دو شبکه خدمات می‌دهد اهمیت دارد. فهرست کردن10.6.0.1و192.168.1.10دو سوکت متصل می‌دهد و پرس و جوهایی که روی هرکدام می‌رسند از آدرسی که روی آن آمده‌اند پاسخ داده می‌شوند. این رفتاری است که بیشتر افراد فرض می‌کنند کاراکتر عمومی (*) قبلاً ارائه می‌دهد.

YAML ساده است و آدرسی که در آن است همان است که به مشتریان تونل شما گفته شد استفاده کنند، نه آدرس اصلی میزبان:

dns:
  bind_hosts:
    - 10.6.0.1
  port: 53

چرا دو نصب یک حل‌کننده ناسازگار هستند

در این زمینه، منظور از مدیریت‌شده توسط پلاگین این است که رزولور توسط یک بسته دیگر نصب شده و تحت نظارت آن قرار دارد: یک بسته فریمور روتر، یک بسته NAS، یا یک افزونه خانه هوشمند. آن بسته معمولاً نسخه خودش از YAML مربوط به AdGuard Home را ارائه می‌دهد و فرآیند را طبق برنامه خودش مجدداً راه‌اندازی می‌کند، در حالی که یک نمونه مستقل، باینری یا کانتینر فروشنده است که خودتان آن را پیکربندی می‌کنید. به هر حال، شما با دو فرآیند مستقل با فایل‌های پیکربندی جداگانه و انتخاب‌های جداگانه برای Bind مواجه هستید، حتی زمانی که هر دو همان لیست منبع و همان لیست فیلتر را می‌خوانند. یکی می‌تواند به آدرس تونل خاص متصل شود در حالی که دیگری Wildcard را به ارث می‌برد، و رابط وب از هر دو سمت به‌طور یکسان به نظر می‌رسد.

به همین دلیل است که «همان حل‌کننده قبل از مهاجرت کار می‌کرد» هیچ چیز در مورد اتصال فعلی ثابت نمی‌کند. سوکت را بررسی کنید، سپس فایل پیکربندی‌ای که فرایند در حال اجرا واقعاً بارگذاری کرده است را بررسی کنید. یک نسخه قدیمی در یک پوشه دیگر دلیل رایجی است که ویرایش به نظر نمی‌رسد تأثیری داشته باشد.

آن را پین کنید، سپس از سمت تونل تست کنید

تغییرbind_hostsبه آدرس تونل، سرویس را دوباره راه‌اندازی کنید و تأیید کنید که سوکت منتقل شده است:ss -lunp | grep :53اکنون باید10.6.0.1:53و هیچ ورودی wildcard نداشته باشد. اگر هنوز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 را نشان دهد، تغییر bind کل راه‌حل نیست و جدول مسیر بعدی چیزی است که باید خوانده شود.

چیزی که تنظیم bind نمی‌تواند برطرف کند

پایبند کردن شنونده لیست دسترسی‌ای که شبکه تونل را حذف کرده، قانونی در فایروال که پرس‌وجو را مجاز می‌داند اما پاسخ را نه، یا مسیر برگشتی به استخر WireGuard را تعمیر نمی‌کند. این‌ها زودتر یا دیرتر از آدرس مبدا شکست می‌خورند و هر کدام مالک متفاوتی دارد.

همچنین تغییر نمی‌دهدکه حل‌کننده به کدام upstream فرستاده می‌شودچه حفاظت از rebinding یک پاسخ خصوصی را برای یک نام خصوصی رد کند، یا اینکه کلاینت چگونه دامنه‌های جستجوی خود را اعمال می‌کند. این‌ها کنترل‌های جداگانه‌ای هستند. زمانی که منبع پاسخ اشتباه است، آدرس bind را تغییر دهید و زمانی که اشتباه نیست، چیزی دیگر را تغییر دهید.