Az AdGuard Home a WireGuard kliensseknek a LAN-címéről válaszol

A tunnel fel van állítva, a tűzfal engedélyezi a 53-as portot, az AdGuard Home fut, és a nevek mégsem oldódnak fel a WireGuard kliens számára. A lekérdezés normálisan megérkezik, a válasz normálisan elindul, így a csomagszámlálók a feloldón egészségesnek tűnnek, és a szolgáltatás ártatlannak látszik. Ami rosszul megy, az a válasz forráscíme: az egy olyan helyi címről jön, amit a kliens soha nem kért, és a kliens stub feloldója eldobja azt. Egy lista az AdGuard Home konfigurációjában dönt erről, és az alapértelmezett beállítás általában a döntést a kernelre bízza.

A lekérdezés megérkezik, a válasz máshonnan indul

Egy kliens, amelyet 10.6.0.1-re konfiguráltak feloldóként, egy UDP lekérdezést küld a 10.6.0.1 53-as portjára. Ez a csomag áthalad a tunnelen, és a hosztra érkezik, ahol az AdGuard Home válaszol rá. Azonban a hálózaton a válasz egy új csomagként jelenik meg, amelynek forráscímét a hoszt hálózati verem választja ki, nem a kliens elvárása szerint.

Amikor a kliens feloldója egy csatlakoztatott socket, ami a systemd-resolved, a dnsmasq és a legtöbb stub resolver esetében igaz, csak a pontosan ugyanarról a címről érkező válaszokat fogadja el, ahová küldte a kérdést. Egy 192.168.1.10-ről származó válasz, amelyet egy 10.6.0.1-hez küldött lekérdezésre kapunk, a feldolgozás előtt eldobásra kerül. A feloldó a sikeres választ naplózza, a kliens a timeoutot naplózza, és mindketten az igazat mondják.

Tehát a számlálók nem hazudnak, és az ügyfél sem. A szükséges bizonyíték három helyen található, ebben a sorrendben: a cím, amelyhez a hallgató kötve van, az útvonal, amelyet a kernel a klienshez visszafelé használna, és a forráscím a tényleges válaszcsomagon.

Hogyan választja ki a kernel a válaszforrást

Egy UDP socket, amely ehhez kötve van,0.0.0.0nincs saját forráscíme, így minden kimenő válasz egy útvonal-keresést indít a cél felé. A kernel ezután az útvonalból veszi a forrást: az útvonal által rögzített címről, vagy a kimenő interfész elsődleges címéről. Semmi sem kerül megőrzésre a lekérdezés célcíméről.

Egy egyetlen hálózati kártyával rendelkező gépen ez láthatatlan, mert csak egy ésszerű válasz lehetséges. Egy olyan gépen, amely LAN címet, WireGuard címet és egy kezelő címet is tartalmaz, több válasz is lehetséges, és a győztes a pillanatnyi routing táblától függ. Adj egy extra útvonalat, egy második címet ugyanazon az interfészen, egy NAT átirányítást a feloldó előtt, vagy futtasd az AdGuardot egy konténerben a saját névtérrel, és a kiválasztott forrás eltérhet attól, amit az ügyfél lekérdezett.

ss -lunp | grep :53megmutatja, melyik játékban vagy. Egy hallgató a0.0.0.0:53címen a wildcard eset; egy hallgató a10.6.0.1:53címen már rögzítette a választ. A socket olvasása gyorsabb, mint a YAML olvasása, és azt tükrözi, ami valójában fut, nem azt, ami utoljára lett mentve.

Amit a bind_hosts valójában vezérel

AdGuard Homedns.bind_hostsa helyi címek listája, amelyet a DNS hallgató használ. Az alapértelmezett, amelyet szállítanak, a helyettesítő karakter (wildcard), ami azt jelenti, hogy minden helyi címre elfogad, és hagyja, hogy a kernel válassza ki a választási forrást. A helyettesítő karakter cseréje az ügyfelek által lekérdezett címre megváltoztatja a socketet, és ezáltal a forráscímet minden válaszon.

A listában több bejegyzés is lehet, ami számít egy olyan feloldónál, amely két hálózatot szolgál ki. A10.6.0.1és192.168.1.10felsorolása két lefoglalt socketet ad, és bármelyikre érkező lekérdezést az érkezett címről válaszolják. Ez az a viselkedés, amit a legtöbb ember feltételez, hogy a helyettesítő karakter már biztosít.

A YAML egyszerű, és a benne szereplő cím az, amelyet a tunnel ügyfeleidnek mondtak használni, nem pedig a gazda elsődleges címe:

dns:
  bind_hosts:
    - 10.6.0.1
  port: 53

Miért nem értenek egyet egy feloldó két telepítése

A bővítménykezelés ebben a kontextusban azt jelenti, hogy a feloldót egy másik csomag telepítette és felügyeli: egy router firmware csomag, egy NAS csomag vagy egy otthoni automatizálási kiegészítő. Ez a csomag általában saját példányát szállítja az AdGuard Home YAML fájljából, és saját ütemezése szerint újraindítja a folyamatot, míg a különálló példány a gyártó bináris fájlja vagy konténere, amelyet maga konfigurál. Akárhogy is, két független folyamatról van szó, külön konfigurációs fájlokkal és külön kötési lehetőségekkel, még akkor is, ha mindkettő ugyanazt a felülről jövő listát és ugyanazokat a szűrőlistákat olvassa. Az egyik kikötheti a konkrét alagútcímet, míg a másik örökli a helyettesítő karaktert, és a webes felület mindkét oldalról azonosnak tűnik.

Ezért az, hogy „ugyanaz a feloldó a migráció előtt működött”, semmit nem bizonyít a jelenlegi kötésről. Ellenőrizze a socketet, majd ellenőrizze a konfigurációs fájlt, amelyet a futó folyamat ténylegesen betöltött. Egy elavult példány egy másik könyvtárban gyakori oka annak, hogy a szerkesztésnek nincs látszólagos hatása.

Tűzze ki, majd tesztelje a tunnel oldaláról

Cserélje lebind_hostsa tunnel címre, indítsa újra a szolgáltatást, és győződjön meg róla, hogy a socket áthelyeződött:ss -lunp | grep :53most már10.6.0.1:53és nincs wildcard bejegyzés. Ha még mindig0.0.0.0-t mutat,a futó folyamat nem olvassa a szerkesztett fájlt.

Ezután teszteljen a kliens oldaláról, mert csak az a oldal számít. Egy lekérdezésdig @10.6.0.1 example.com-tel azt az utat használja, amelyet a felhasználó is használ, és egy rögzítés a hoszton atcpdump -ni wg0 udp port 53megmutatja a válasz forráscímét a hálózaton. Hasonlítsd össze a kliens feloldójának beállításában szereplő címmel; amikor megegyeznek, a timeout már nem titok.

ip route get 10.6.0.2elmagyarázza az esetleges fennmaradó furcsaságokat, mert kiírja azt a interfészt és forrást, amelyet a host visszaadna a kliensnek. Ha ez a kimenet a LAN-interfészt jelöli, a bind változtatás nem a teljes megoldás, és a következő dolog, amit át kell nézni, a routing tábla.

Amit a bind beállítás nem tud javítani

A listener rögzítése nem javítja a hozzáférési listát, amely kihagyja a tunnel alhálózatot, egy tűzfal szabályt, amely engedélyezi a lekérdezést, de nem a választ, vagy a hiányzó útvonalat a WireGuard poolhoz. Ezek korábban vagy később buknak el, mint a forráscím, és mindegyiknek más a felelőse.

Az sem változtatja meghogy melyik upstream felé továbbítja a feloldó., hogy a kötésvédelmi beállítás visszautasít-e egy privát választ egy privát névre, vagy hogy az ügyfél hogyan alkalmazza a saját keresési tartományait. Ezek külön vezérlések. Változtassa meg a kötéscímet, ha a válasz forrása hibás, és változtasson valami mást, ha nem az.