AdGuard Home WireGuard Müştərilərinə LAN Ünvanınızdan Cavab Verir

Tunel açıqdır, firewall port 53-ə icazə verir, AdGuard Home işləyir və yenə də WireGuard müştərisi üçün adlar həll olunmur. Sorğu normal olaraq gəlir və cavab normal olaraq çıxır, buna görə də resolverdə paket sayğacları sağlam görünür və xidmət günahsız görünür. Yanlış olan isə həmin cavabın mənbə ünvanıdır: o, müştərinin heç vaxt soruşmadığı yerli ünvandan çıxır və müştərinin stub resolveri onu atır. AdGuard Homenin konfiqurasiyasında bir siyahı bunu qərarlaşdırır və onun adi defolt dəyəri qərarı nüvəyə verir.

Sorğu gəlir, cavab isə başqa yerdən çıxır

10.6.0.1 ünvanı ilə konfiqurasiya edilmiş müştəri, 10.6.0.1 port 53-ə UDP sorğu göndərir. Bu paket tunel üzrə keçərək hosta çatır və AdGuard Home ona cavab verir. Lakin kabel üzərində cavab yeni paket kimi görünür və mənbə ünvanı hostun yığını tərəfindən seçilir, müştərinin gözləntisi ilə deyil.

Müştərinin resolveri bir qoşulmuş soket olduqda, bu sistemd-resolved, dnsmasq və əksər stub resolverlər tərəfindən istifadə olunur, o yalnız dəqiq göndərdiyi ünvandan gələn cavabları qəbul edir. 192.168.1.10 mənbəli cavab, 10.6.0.1-ə göndərilmiş sorğuya uyğun gəlmədiyi üçün hər hansı emal başlamadan atılır. Resolver uğurlu cavabı loglayır, müştəri zaman aşımını loglayır və hər ikisi həqiqəti deyir.

Beləliklə, sayğaclar yalan danışmır və müştəri də yalan danışmır. Sizin lazım olan sübut üç yerdədir, bu sırayla: dinləyiciyə bağlanmış ünvan, nüvənin müştəriyə geri dönmək üçün istifadə edəcəyi marşrut və cavab paketinin üzərindəki mənbə ünvanı.

Kernellin cavab mənbəyini necə seçməsi

Bir UDP soketi bağlı0.0.0.0özünün mənbə ünvanı yoxdur, buna görə hər çıxış cavabı təyinat üçün marşrut axtarışını tetikler. Sonra nüvə mənbəni həmin marşrutdan alır: marşrut tərəfindən təyin edilmiş ünvan, ya da çıxış interfeysinin əsas ünvanı. Sorğunun təyinat ünvanı haqqında heç nə yadda saxlanmır.

Tək evli bir hostda bu görünməzdir, çünki yalnız bir mümkün cavab var. LAN ünvanına, WireGuard ünvanına və idarəetmə ünvanına sahib bir maşında bir neçə cavab mümkündür və qalib həmin anda marşrutlaşdırma cədvəlinə bağlıdır. Əlavə bir marşrut əlavə edin, eyni interfeys üzərində ikinci bir ünvan əlavə edin, resolverin qarşısında bir NAT yönləndirməsi edin və ya AdGuard-ı öz namespace'i olan bir konteynerdə işlədin, və seçilmiş mənbə müştərinin sorğu verdiyi ünvanla fərqli ola bilər.

ss -lunp | grep :53hansı oyunda olduğunuzu göstərir.0.0.0.0:53üzərindəki dinləyici universal haldır;10.6.0.1:53üzərindəki dinləyici artıq cavabı təyin edib. Soketi oxumaq YAML oxumaqdan daha sürətlidir və son saxlananı deyil, faktiki olaraq işləyənləri əks etdirir.

bind_hosts əslində nəyi idarə edir

AdGuard Home-undns.bind_hostsDNS dinləyicisinin istifadə etdiyi yerli ünvanların siyahısıdır. Göndərilən standart seçim vahid işarəsidir (wildcard), bu da bütün yerli ünvanlarda qəbul etmək və cavaba uyğun olaraq kernelin mənbə ünvanını seçməsini deməkdir. Vahid işarəni müştərilərin sorğu verdiyi ünvanla əvəz etmək soketi dəyişdirir və hər cavabda mənbə ünvanını da dəyişdirir.

Siyahıda birdən çox giriş ola bilər, bu ikili şəbəkəyə xidmət edən həll edən üçün vacibdir.10.6.0.1və192.168.1.10göstərmək iki bağlanmış soket verir və həmin soketlərin hər hansı birinə çatmış sorğu onu alındığı ünvandan cavablananır. Bu, əksər insanların qəbul etdiyini düşündüyü vahid işarənin göstərdiyi davranışdır.

YAML sadədir və içindəki ünvan sizin tunel müştərilərinizə istifadə etmək üçün deyildiyi ünvandır, hostun əsas ünvanı deyil:

dns:
  bind_hosts:
    - 10.6.0.1
  port: 53

Niyə bir həll edən iki quraşdırma arasında razılaşmır

Plugin tərəfindən idarə olunan, bu kontekstdə, deməkdir ki, həll edici başqa bir paket tərəfindən quraşdırılıb və nəzarət olunur: bir router proqram təminatı paketi, NAS paketi, və ya ev avtomatlaşdırması əlavəsi. O paket adətən öz AdGuard Home YAML nüsxəsini göndərir və prosesi öz cədvəlinə uyğun yenidən başladır, halbuki müstəqil nümunə satıcı ikili faylı və ya konteynerdir ki, siz onu özünüz konfiqurasiya edirsiniz. Hər iki halda siz iki müstəqil prosesi ayrı-ayrı konfiqurasiya faylları və ayrı-ayrı bağlanma seçimləri ilə görürsünüz, həmçinin hər ikisi eyni upstream siyahısını və eyni filtr siyahılarını oxusa belə. Biri müəyyən tunel ünvanını bağlaya bilər, digəri isə wildcard-i miras alır və veb interfeys hər iki tərəfdən identik görünür.

Buna görə də “eyni həll edici köçürməzdən əvvəl işləyirdi” ifadəsi cari bağlamanın heç bir şeyini sübut etmir. Soketi yoxlayın, sonra isə işləyən prosesin əslində yüklədiyi konfiqurasiya faylını yoxlayın. Başqa bir kataloqda köhnəlmiş nüsxə redaktənin heç bir təsir göstərməməsinin ümumi səbəbidir.

Onu sırala, sonra tunel tərəfdən test et

Dəyişməkbind_hoststunel ünvanına, xidməti yenidən işə salın və soketin hərəkət etdiyini təsdiqləyin:ss -lunp | grep :53indi göstərməlidir10.6.0.1:53və joker giriş yoxdur. Hələ də göstərirsə0.0.0.0,işləyən proses sizin redaktə etdiyiniz faylı oxumur.

Sonra müştəridən test edin, çünki önəmli olan yeganə tərəf odur. Bir sorğu ilədig @10.6.0.1 example.comistifadəçinin istifadə etdiyi yolu məşq edir və hostda bir tutma ilətcpdump -ni wg0 udp port 53cavabın tel üzərindəki mənbə ünvanını göstərir. Onu müştərinin resolver təyinatında göstərilən ünvanla müqayisə edin; onlar eyni olduğunda, zaman aşımı artıq sirr deyil.

ip route get 10.6.0.2qalan hər hansı qəribəliyi izah edir, çünki o, hostun müştəriyə geri istifadə edəcəyi interfeysi və mənbəni çap edir. Əgər həmin çıxış LAN interfeysini göstərirsə, bind dəyişimi tam həll deyil və növbəti oxunacaq şey marşrut cədvəlidir.

Bind təyinatının düzəldə bilmədiyi şey

Dinləyicini pinləmək, tunel subnetini buraxan giriş siyahısını, sorğunu icazə verən amma cavabı icazə verməyən firewall qaydasını və ya WireGuard hovuzuna geri qayıdan marşrutu bərpa etmir. Bunlar mənbə ünvanından əvvəl və ya sonra uğursuz olur və hər birinin fərqli sahibi var.

Həmçinin dəyişdirmirresolverin yuxarı axına yönəltdiyi upstream-u, bağlılıq qorumasının xüsusi bir ad üçün xüsusi cavabı rədd edib etmədiyi, yoxsa müştərinin öz axtarış domenlərini necə tətbiq etdiyi. Bunlar ayrı nəzarətlərdir. Cavab mənbəyi səhv olduqda bağlama ünvanını dəyişdirin və səhv olmadıqda başqa bir şeyi dəyişdirin.