AdGuard Home vastaa WireGuard-asiakkaille LAN-osoitteestasi

Tunneli on päällä, palomuuri sallii portin 53, AdGuard Home on käynnissä, mutta nimet eivät silti ratkea WireGuard-asiakkaalle. Kysely saapuu normaalisti ja vastaus lähtee normaalisti, joten pakettien laskurit resolverissa näyttävät kunnossa ja palvelu vaikuttaa syyttömältä. Mikä menee pieleen, on sen vastauksen lähdeosoite: se lähtee paikallisesta osoitteesta, jota asiakas ei koskaan pyytänyt, ja asiakkaan tilapäinen resolver hylkää sen. Yksi lista AdGuard Homen asetuksissa päättää tästä, ja sen tavallinen oletus antaa päätöksen kernelille.

Kysely saapuu, vastaus lähtee jostain muualta

Asiakas, joka on määritetty käyttämään 10.6.0.1:n resolverinä, lähettää UDP-kyselyn osoitteeseen 10.6.0.1 portti 53. Tämä paketti kulkee tunnelin läpi ja päätyy isäntään, ja AdGuard Home vastaa siihen. Vaikka verkossa vastaus on uusi paketti, jonka lähdeosoitteen valitsee isännän pino, ei asiakkaan odotus.

Kun asiakkaan resolver on yhdistetty socket, kuten systemd-resolved, dnsmasq ja useimmat stub-resolverit käyttävät, se hyväksyy vain vastaukset täsmälleen siihen osoitteeseen, johon kysely lähetettiin. Vastaus, jonka lähteenä on 192.168.1.10 kyselyyn, joka on lähetetty osoitteeseen 10.6.0.1, hylätään ennen kuin mitään analysoidaan. Resolver kirjaa onnistuneen vastauksen, asiakas kirjaa aikakatkaisun, ja molemmat kertovat totuuden.

Joten laskurit eivät valehtele eivätkä asiakaskaan. Tarvitsemasi todisteet ovat kolmessa paikassa, tässä järjestyksessä: osoitteessa, johon kuuntelija on sidottu, reitillä, jota ydin käyttäisi palatakseen asiakkaalle, ja lähdeosoitteessa varsinaisessa vastauspaketissa.

Kuinka ydin valitsee vastaavan lähteen

UDP-soketilla, joka on sidottu0.0.0.0, ei ole omaa lähdeosoitetta, joten jokainen lähtevä vastaus laukaisee reitinhaku kohteeseen. Ydin ottaa sitten lähteen tuosta reitistä: reitin kiinnittämä osoite tai lähtevän käyttöliittymän ensisijainen osoite. Kyselyn kohdeosoitteesta ei tallenneta mitään.

Yksinäisellä isännällä tämä on näkymätöntä, koska on vain yksi uskottava vastaus. Koneella, jolla on LAN-osoite, WireGuard-osoite ja hallintaosoite, useita vastauksia on mahdollista, ja voittaja riippuu kyseisen hetken reititystaulusta. Lisää ylimääräinen reitti, toinen osoite samalle rajapinnalle, NAT-uudelleenohjaus resolverin eteen tai aja AdGuardia säiliössä omalla nimialueellaan, ja valittu lähde voi poiketa siitä, mitä asiakas kysyi.

ss -lunp | grep :53näyttää, missä pelissä olet. Kuuntelija osoitteessa0.0.0.0:53on yleistapauksen villikortti; kuuntelija osoitteessa10.6.0.1:53on jo määrittänyt vastauksen. Socketin lukeminen on nopeampaa kuin YAML:n lukeminen, ja se heijastaa sitä, mikä todella on käynnissä, eikä sitä, mikä tallennettiin viimeksi.

Mitä bind_hosts todella ohjaa

AdGuard Homendns.bind_hostson luettelo paikallisista osoitteista, joita DNS-kuuntelija käyttää. Toimitettu oletus on jokerimerkki, mikä tarkoittaa, että hyväksytään kaikki paikalliset osoitteet ja annetaan ytimen valita lähde vastauksen mukaan. Korvaamalla jokerimerkki osoitteella, jota asiakkaat kysyvät, vaihdetaan socketia ja sen mukana lähdeosoite jokaisessa vastauksessa.

Luettelo voi sisältää useamman kuin yhden merkinnän, mikä on tärkeää, kun resolver palvelee kahta verkkoa. Listaamalla10.6.0.1ja192.168.1.10saadaan kaksi sidottua socketia, ja kyselyyn, joka saapuu jommallekummalle, vastataan sen osoitteen mukaan, johon se saapui. Tämä on käyttäytyminen, jonka useimmat ihmiset olettavat jokerimerkin jo tarjoavan.

YAML on yksinkertaista, ja osoite siinä on se, jota tunneliasiakkaille kerrottiin käyttää, ei isännän ensisijainen osoite:

dns:
  bind_hosts:
    - 10.6.0.1
  port: 53

Miksi kahden resolver-asennuksen mielipiteet eroavat

Liitännäisen hallinnoima, tässä yhteydessä, tarkoittaa, että ratkaisija on asennettu ja sitä valvoo toinen paketti: reitittimen laiteohjelmistopaketti, NAS-paketti tai koti-automaatio-lisäosa. Tämä paketti yleensä toimittaa oman kopionsa AdGuard Homen YAML-tiedostosta ja käynnistää prosessin uudelleen omien aikataulujensa mukaan, kun taas itsenäinen instanssi on valmistajan binääri tai kontti, jonka konfiguroit itse. Joka tapauksessa tarkastelussa on kaksi itsenäistä prosessia, joilla on omat konfiguraatiotiedostonsa ja omat sitomisvalintansa, vaikka molemmat lukevat saman upstream-listan ja samat suodatuslistat. Toinen voi sitoa tietyn tunneliosoitteen, kun taas toinen perii jokerimerkin, ja verkkokäyttöliittymä näyttää identtiseltä kummaltakin puolelta.

Siksi 'sama ratkaisin toimi ennen migraatiota' ei todista mitään nykyisestä sitoutumisesta. Tarkista liitin, sitten tarkista kokoonpanotiedosto, jonka käynnissä oleva prosessi todella luki. Vanha kopio toisessa hakemistossa on yleinen syy siihen, että muutos ei näytä vaikuttavan.

Kiinnitä se, sitten testaa tunnelin puolelta

Vaihdabind_hoststunnelin osoitteeseen, käynnistä palvelu uudelleen ja varmista, että liitin siirtyi:ss -lunp | grep :53tulisi nyt näyttää10.6.0.1:53eikä mitään yleismerkki-merkintää. Jos se edelleen näyttää0.0.0.0,käynnissä oleva prosessi ei lue muokkaamaasi tiedostoa.

Sitten testaa asiakkaalta, koska ainoa merkityksellinen puoli on asiakas. Kyselydig @10.6.0.1 example.comharjoittaa samaa polkua, jota käyttäjä käyttää, ja kaappaus isännästä mukanatcpdump -ni wg0 udp port 53näyttää vastauksen lähdeosoitteen viivalla. Vertaile sitä asiakkaan resolver-asetuksessa olevaan osoitteeseen; kun ne ovat yhtä suuret, aikakatkaisu ei ole enää mysteeri.

ip route get 10.6.0.2selittää mahdollisen jäljellä olevan omituisuuden, koska se tulostaa käyttöliittymän ja lähteen, jota isäntä käyttäisi palatessaan asiakkaalle. Jos kyseisessä tulosteessa mainitaan LAN-käyttöliittymä, sidontamuutos ei ole koko ratkaisu ja reititystaulu on seuraava asia, joka kannattaa tarkistaa.

Mitä sidonta-asetus ei voi korjata

Kuuntelijan kiinnittäminen ei korjaa pääsylistaa, joka jättää tunneliverkon pois, palomuurisääntöä, joka sallii kyselyn mutta ei vastausta, tai puuttuvaa reittiä takaisin WireGuard-alueelle. Nämä epäonnistuvat aikaisemmin tai myöhemmin kuin lähdeosoite, ja jokaisella on eri omistaja.

Se ei myöskään muutamihin ylävirtaan resolver ohjaa, hylkääkö uudelleenkytkentäsuojaus yksityisen vastauksen yksityiselle nimelle vai kuinka asiakas soveltaa omia hakudomainejaan. Nämä ovat erillisiä ohjauksia. Muuta sidontosoitetta, kun vastauslähde on väärä, ja muuta jotain muuta, kun se ei ole.