AdGuard Home odpovedá klientom WireGuard z vašej LAN adresy

Tunel je funkčný, firewall povoľuje port 53, AdGuard Home beží a mená sa stále neriešia pre klienta WireGuard. Dopyt bežne prichádza a odpoveď bežne odchádza, takže počítadlá paketov na resolveri vyzerajú zdravo a služba sa javí ako nevinne. Čo sa pokazí, je zdrojová adresa tejto odpovede: odchádza z lokálnej adresy, ktorú klient nikdy nepožiadal, a stub resolver klienta ju zahodí. Jeden zoznam v konfigurácii AdGuard Home toto rozhoduje, a jeho bežná predvolená hodnota odovzdáva rozhodnutie jadru.

Dopyt prichádza, odpoveď odchádza odniekiaľ inde

Klient nakonfigurovaný s 10.6.0.1 ako svojím resolverom odosiela UDP dotaz na 10.6.0.1 port 53. Tento paket prechádza tunelom a dostane sa na hostiteľa, a AdGuard Home naň odpovie. Na linke je však odpoveď nový paket, ktorého zdrojová adresa je vybraná zásobníkom hostiteľa, nie podľa očakávania klienta.

Keď je resolver klienta pripojená zásuvka, čo používajú systemd-resolved, dnsmasq a väčšina stub resolverov, prijíma iba odpovede z presnej adresy, na ktorú bol odoslaný. Odpoveď zo zdroja 192.168.1.10 na dotaz odoslaný na 10.6.0.1 je zahodená ešte pred akýmkoľvek parsovaním. Resolver zapisuje úspešnú odpoveď, klient zapisuje časový limit, a oba hlásenia hovoria pravdu.

Takže počítadlá nelžú a ani klient. Dôkazy, ktoré potrebujete, sú na troch miestach, v tomto poradí: adresa, ku ktorej je pripojený poslucháč, trasa, ktorú by jadro použilo späť ku klientovi, a zdrojová adresa na skutočnom odpoveďovom pakete.

Ako jadro vyberá zdroj odpovede

UDP socket pripojený k0.0.0.0nemá vlastnú zdrojovú adresu, takže každá odchádzajúca odpoveď spúšťa vyhľadávanie trasy k cieľu. Jadro potom vezme zdroj z tejto trasy: adresu priradenú trasou alebo primárnu adresu odchádzajúceho rozhrania. Nič o cieľovej adrese dopytu si nepamätá.

Na hostiteľovi s jednou sieťovou kartou je to neviditeľné, pretože existuje iba jedna pravdepodobná odpoveď. Na počítači, ktorý má LAN adresu, adresu WireGuard a adresu pre správu, je niekoľko odpovedí pravdepodobných a víťaz závisí od smerovacej tabuľky v tom momente. Pridajte dodatočnú trasu, druhú adresu na rovnakom rozhraní, NAT presmerovanie pred resolverom alebo spustite AdGuard v kontajneri s vlastným menným priestorom a vybraná zdrojová adresa môže byť odlišná od tej, ktorú klient dotazoval.

ss -lunp | grep :53ukazuje, v ktorej hre ste. Listener na0.0.0.0:53je prípad s univerzálnym znakom; listener na10.6.0.1:53už priklincoval odpoveď. Čítanie zásuvky je rýchlejšie než čítanie YAML a odráža, čo sa skutočne vykonáva, namiesto toho, čo bolo naposledy uložené.

Čo bind_hosts vlastne ovláda

AdGuard Home'sdns.bind_hostsje zoznam miestnych adries, ktoré používa DNS listener. Štandardne dodávaná predvolená hodnota je zástupný znak, čo znamená akceptovať na každej miestnej adrese a nechať jadro vybrať zdroj podľa odpovede. Nahradením zástupného znaku adresou, ktorú klienti dotazujú, sa zmení socket a s ním aj zdrojová adresa pri každej odpovedi.

Zoznam môže obsahovať viac než jednu položku, čo je dôležité pri resolveri slúžiacom dvom sieťam. Zoznam10.6.0.1a192.168.1.10dáva dva viazané sockety a dotaz prichádzajúci na ktorýkoľvek z nich je odpovedaný z adresy, na ktorú prišiel. Toto je správanie, ktoré väčšina ľudí predpokladá, že zástupný znak už poskytuje.

YAML je jednoduchý a adresa v ňom je tá, ktorú vašim tunnelem klientom povedali používať, nie primárna adresa hostiteľa:

dns:
  bind_hosts:
    - 10.6.0.1
  port: 53

Prečo sa dve inštalácie jedného resolvera nezhodujú

Spravované pluginom v tomto kontexte znamená, že resolver bol nainštalovaný a je kontrolovaný iným balíkom: balíkom firmvéru routera, balíkom NAS alebo doplnkom domácej automatizácie. Tento balík zvyčajne dodáva vlastnú kópiu YAML súboru AdGuard Home a reštartuje proces podľa vlastného harmonogramu, zatiaľ čo samostatná inštancia je binárka alebo kontajner od dodávateľa, ktorý konfiguruješ sám. Tak či tak sa pozeráte na dva nezávislé procesy s oddelenými konfiguračnými súbormi a oddelenými voľbami väzby, aj keď oba čítajú rovnaký upstream zoznam a rovnaké filtre. Jeden môže viazať konkrétnu adresu tunelu, zatiaľ čo druhý dedi k wildcard, a webové rozhranie vyzerá z oboch strán rovnako.

To je dôvod, prečo „ten istý resolver fungoval pred migráciou“ nedokazuje nič o aktuálnom viazaní. Skontrolujte socket a potom skontrolujte konfiguračný súbor, ktorý aktuálne bežiaci proces skutočne načítal. Zastaralá kópia v inom adresári je bežným dôvodom, prečo sa zdá, že úprava nemá žiadny efekt.

Pripnite ho, potom otestujte zo strany tunela

Zmeňtebind_hostsna adresu tunela, reštartujte službu a potvrďte, že sa socket presunul:ss -lunp | grep :53by teraz mal ukazovať10.6.0.1:53a žiadny záznam s hviezdičkou. Ak stále ukazuje0.0.0.0,bežiaci proces nečíta súbor, ktorý ste upravili.

Potom otestujte zo strany klienta, pretože to je jediná strana, ktorá má význam. Dotaz sdig @10.6.0.1 example.comprechádza cestou, ktorú používateľ využíva, a zachytenie na hostiteľovi stcpdump -ni wg0 udp port 53zobrazuje zdrojovú adresu odpovede na sieťovom kábli. Porovnajte ju s adresou v nastavení resolvera klienta; keď sú rovnaké, časový limit prestáva byť záhadou.

ip route get 10.6.0.2vysvetľuje zostávajúcu zvláštnosť, pretože zobrazuje rozhranie a zdroj, ktorý by hostiteľ použil na odoslanie späť klientovi. Ak tento výstup uvádza LAN rozhranie, zmena bind nie je celé riešenie a ďalšia vec na kontrolu je smerovacia tabuľka.

Čo nastavenie bind nemôže opraviť

Pripnutie poslucháča neopravuje zoznam prístupov, ktorý vynecháva podsieť tunela, pravidlo firewallu, ktoré povolí dotaz, ale nie odpoveď, ani chýbajúcu cestu späť do poolu WireGuard. Tieto zlyhajú skôr alebo neskôr než zdrojová adresa a každé má iného vlastníka.

To tiež nemenína ktorého upstream resolver smeruje, či ochrana proti opätovnému väzobeniu odmieta súkromnú odpoveď pre súkromné meno, alebo ako klient používa vlastné vyhľadávacie domény. To sú samostatné kontroly. Zmeňte adresu väzby, keď je zdroj odpovede nesprávny, a niečo iné, keď nie je.