AdGuard Home odpovídá klientům WireGuard z vaší LAN adresy

Tunel je aktivní, firewall povoluje port 53, AdGuard Home běží a přesto se jména pro klienta WireGuard neřeší. Dotaz obvykle dorazí a odpověď obvykle odejde, takže počítadla paketů na resolveru vypadají zdravě a služba se jeví nevinně. Co se pokazí, je zdrojová adresa v té odpovědi: odchází z lokální adresy, o kterou klient nikdy nežádal, a klientův stub resolver ji zahodí. Jeden seznam v konfiguraci AdGuard Home toto rozhoduje a jeho obvyklé výchozí nastavení předává rozhodnutí jádru.

Dotaz dorazí, odpověď odejde odněkud jinud

Klient nakonfigurovaný s 10.6.0.1 jako svým resolverem odesílá UDP dotaz na 10.6.0.1 port 53. Tento paket projde tunelem a dorazí na hostitele, a AdGuard Home na něj odpoví. Na síti je však odpověď nový paket, jehož zdrojovou adresu vybírá zásobník hostitele, nikoli očekávání klienta.

Když je resolver klienta připojená zásuvka, což je to, co používají systemd-resolved, dnsmasq a většina stub resolverů, přijímá pouze odpovědi z přesné adresy, na kterou odeslal dotaz. Odpověď pocházející z 192.168.1.10 na dotaz odeslaný na 10.6.0.1 je zahozená dříve, než dojde k jakémukoli parsování. Resolver zaznamená úspěšnou odpověď, klient zaznamená vypršení časového limitu, a oba říkají pravdu.

Takže čítače nelžou a ani klient. Důkazy, které potřebujete, jsou na třech místech, v tomto pořadí: adresa, na kterou je posluchač navázán, trasa, kterou by jádro použilo zpět k klientovi, a zdrojová adresa na samotném odpovědním paketu.

Jak jádro vybírá zdroj odpovědi

UDP socket navázaný na0.0.0.0nemá vlastní zdrojovou adresu, takže každá odchozí odpověď spouští vyhledání trasy pro cílovou adresu. Jádro pak bere zdroj z této trasy: adresu přidělenou trasou, nebo primární adresu odchozího rozhraní. Nic z cílové adresy dotazu se neukládá.

Na jednom hostiteli s jedním rozhraním je to neviditelné, protože existuje pouze jedna pravděpodobná odpověď. Na stroji s adresou LAN, adresou WireGuard a správcovskou adresou je několik odpovědí pravděpodobných a vítěz závisí na směrovací tabulce v daném okamžiku. Přidejte další trasu, druhou adresu na stejném rozhraní, přesměrování NAT před resolverem, nebo spusťte AdGuard v kontejneru s vlastním namespace, a vybrané zdrojové adresy se mohou lišit od těch, které klient dotazoval.

ss -lunp | grep :53ukazuje, ve které hře se nacházíte. Listener na0.0.0.0:53je případ univerzálního zástupce; listener na10.6.0.1:53již odpověď připnul. Čtení socketu je rychlejší než čtení YAML a odráží to, co skutečně běží, spíše než to, co bylo naposledy uloženo.

Co vlastně bind_hosts kontroluje

AdGuard Homedns.bind_hostsje seznam místních adres, které posluchač DNS používá. Výchozí nastavení je zástupný znak, což znamená přijímat na všech místních adresách a nechat jádro vybrat zdrojovou adresu pro každou odpověď. Nahrazení zástupného znaku adresou, na kterou klienti dotazují, změní soket a s ním i zdrojovou adresu u každé odpovědi.

Seznam může obsahovat více než jednu položku, což je důležité u resolveru obsluhujícího dvě sítě. Zápis10.6.0.1a192.168.1.10vytvoří dva vázané sokety a dotaz dorazivší na kterékoli z nich je zodpovězen z adresy, na které dorazil. To je chování, které většina lidí předpokládá, že zástupný znak již poskytuje.

YAML je jednoduchý a adresa v něm je ta, kterou klienti vašeho tunelu měli použít, nikoli primární adresa hostitele:

dns:
  bind_hosts:
    - 10.6.0.1
  port: 53

Proč dvě instalace jednoho resolveru nesouhlasí

Spravovaný pluginem, v tomto kontextu, znamená, že resolver byl nainstalován a je řízen jiným balíčkem: balíčkem firmware routeru, balíčkem NAS nebo doplňkem domácí automatizace. Tento balíček obvykle poskytuje vlastní kopii YAML AdGuard Home a restartuje proces podle vlastního harmonogramu, zatímco samostatná instance je binární soubor od dodavatele nebo kontejner, který si nakonfigurujete sami. Tak či onak se jedná o dva nezávislé procesy s oddělenými konfiguračními soubory a samostatnými volbami bind, i když oba čtou stejný upstream seznam a stejné filtrační seznamy. Jeden může svázat konkrétní adresu tunelu, zatímco druhý dědí wildcard, a webové rozhraní vypadá z obou stran identicky.

To je důvod, proč „stejný resolver fungoval před migrací“ nic nedokazuje o aktuálním přiřazení. Zkontrolujte socket, poté zkontrolujte konfigurační soubor, který proces skutečně načetl. Starší kopie v jiném adresáři je běžným důvodem, proč úprava vypadá, že nemá žádný efekt.

Připněte jej, poté otestujte ze strany tunelu

Změňtebind_hostsna adresu tunelu, restartujte službu a potvrďte, že se socket přesunul:ss -lunp | grep :53by nyní měl ukazovat10.6.0.1:53a žádný zástupný záznam. Pokud stále ukazuje0.0.0.0,běžící proces nečte soubor, který jste upravili.

Poté otestujte ze strany klienta, protože to je jediná strana, která je důležitá. Dotaz sdig @10.6.0.1 example.comprověřuje cestu, kterou uživatel využívá, a zachycení na hostiteli setcpdump -ni wg0 udp port 53ukazuje zdrojovou adresu odpovědi na síti. Porovnejte ji s adresou v nastavení resolveru klienta; když jsou stejné, vypršení času přestává být záhadou.

ip route get 10.6.0.2vysvětluje jakoukoli zbývající zvláštnost, protože tiskne rozhraní a zdroj, který by host použil zpět ke klientovi. Pokud výstup pojmenuje rozhraní LAN, změna bind není úplnou opravou a dalším krokem je čtení směrovací tabulky.

Co nastavení bind nemůže opravit

Připevnění posluchače neopraví seznam přístupů, který vynechává tunelovou podsíť, pravidlo firewallu, které povoluje dotaz, ale ne odpověď, nebo chybějící trasu zpět do poolu WireGuard. Tyto selhají dříve nebo později než zdrojová adresa a každý má jiného vlastníka.

Také to neměnína který upstream resolver přeposílá, zda ochrana proti přemapování odmítne soukromou odpověď pro soukromé jméno, nebo jak klient aplikuje své vlastní vyhledávací domény. To jsou samostatné kontroly. Změňte bind adresu, když je zdroj odpovědi nesprávný, a změňte něco jiného, když není.