AdGuard Home vastab WireGuardi klientidele LAN-i aadressilt

Tunnel on üleval, tulemüür lubab porti 53, AdGuard Home töötab ja nimed ei lahendu WireGuardi kliendi jaoks ikkagi. Päring jõuab tavaliselt kohale ja vastus väljub tavaliselt, nii et resolveri paketilugejad näevad terved välja ja teenus tundub süütu. Valesti läheb vastuse lähteaadressiga: see väljub kohalikult aadressilt, mida klient kunagi ei küsinud, ja kliendi stub-resolver viskab selle minema. Üks loend AdGuard Home'i konfiguratsioonis otsustab selle, ja selle tavaline vaikeväärtus annab otsuse kernelile.

Päring jõuab kohale, vastus väljub mujalt

Klient, mille resolveriks on seadistatud 10.6.0.1, saadab UDP-päringu aadressile 10.6.0.1 porti 53. See pakett läbib tunneli ja maandub hostis ning AdGuard Home vastab sellele. Juhtmel on vastus aga uus pakett, mille lähteaadressi valib hosti virn, mitte kliendi ootus.

Kui kliendi resolver on ühendatud sokkel, mida kasutavad systemd-resolved, dnsmasq ja enamik stub-resolvereid, võtab see vastu ainult vastuseid täpselt sellelt aadressilt, kuhu see saatis. Vastus, mille lähteks on 192.168.1.10, päringule, mis saadeti aadressile 10.6.0.1, visatakse enne mis tahes parsimist minema. Resolver logib edukat vastust, klient logib ajalõppu ja mõlemad räägivad tõtt.

Nii et lugejad ei valeta ja klient ei valeta samuti. Tõendid, mida vajad, on kolmes kohas, selles järjekorras: aadress, millega kuulaja on seotud, marsruut, mida kernel kliendi poole tagasi kasutaks, ja lähteaadress tegelikul vastusepaketil.

Kuidas kernel vastuse allikat valib

UDP-soklil, mis on seotud aadressiga 0.0.0.0, pole oma lähteaadressi, seega iga väljuv vastus käivitab sihtkoha marsruudiotsingu. Seejärel võtab kernel lähteaadressi sellelt marsruudilt: marsruudiga kinnitatud aadressi või väljuva liidese primaarse aadressi. Päringu sihtaadressi kohta ei jää midagi meelde.

Ühe võrguliidesega hostis on see nähtamatu, sest usutavaid vastuseid on ainult üks. Masinas, millel on LAN-i aadress, WireGuardi aadress ja haldusaadress, on usutavaid vastuseid mitu ja võitja sõltub sel hetkel kehtivast marsruutimistabelist. Lisa täiendav marsruut, teine aadress samale liidesele, NAT-i ümbersuunamine resolveri ette või jooksuta AdGuardi konteineris, millel on oma nimeruum, ja valitud allikas võib erineda sellest, mida klient küsis.

ss -lunp | grep :53 näitab, millises mängus sa oled. Kuulaja aadressil 0.0.0.0:53 on metamärgi juhtum; kuulaja aadressil 10.6.0.1:53 on vastuse juba kinni naelutanud. Sokli lugemine on kiirem kui YAML-i lugemine ja see kajastab seda, mis tegelikult töötab, mitte seda, mis viimati salvestati.

Mida bind_hosts tegelikult juhib

AdGuard Home'i dns.bind_hosts on kohalike aadresside loend, mida DNS-kuulaja kasutab. Kaasasolev vaikeväärtus on metamärk, mis tähendab: võta vastu igal kohalikul aadressil ja lase kernelil iga vastuse jaoks allikas valida. Metamärgi asendamine aadressiga, mida kliendid küsivad, muudab soklit ja koos sellega lähteaadressi igal vastusel.

Loend võtab vastu rohkem kui ühe kirje, mis on oluline kahte võrku teenindava resolveri puhul. Aadresside 10.6.0.1 ja 192.168.1.10 loetlemine annab kaks seotud soklit, ja kummalgi neist saabuvale päringule vastatakse aadressilt, millelt see saabus. See on käitumine, mida enamik inimesi eeldab, et metamärk juba pakub.

YAML on lihtne ja selles olev aadress on see, mida sinu tunneliklientidele kasutada öeldi, mitte hosti primaarne aadress:

dns:
  bind_hosts:
    - 10.6.0.1
  port: 53

Miks ühe resolveri kaks paigaldust erinevalt käituvad

Pistikprogrammi hallatav tähendab selles kontekstis, et resolveri paigaldas ja haldab teine pakett: ruuteri püsivara pakett, NAS-i pakett või koduautomaatika lisandmoodul. See pakett tarnib tavaliselt oma koopia AdGuard Home'i YAML-ist ja taaskäivitab protsessi oma ajakava järgi, samal ajal kui eraldiseisev eksemplar on müüja binaarfail või konteiner, mille seadistad ise. Mõlemal juhul vaatad kahte sõltumatut protsessi, millel on eraldi konfiguratsioonifailid ja eraldi sidumisvalikud, isegi kui mõlemad loevad sama ülesvoolu loendit ja samu filtriloendeid. Üks võib kuulata konkreetsel tunneli aadressil, samal ajal kui teine pärib metamärgi, ja veebiliides näeb mõlemal pool identne välja.

Seetõttu ei tõesta „sama resolver töötas enne migratsiooni” praeguse sidumise kohta midagi. Kontrolli soklit ja seejärel konfiguratsioonifaili, mille töötav protsess tegelikult laadis. Aegunud koopia teises kataloogis on tavaline põhjus, miks muudatus näib mõju puuduvat.

Naeluta see kinni ja testi tunnelipoolt

Muuda bind_hosts tunnelis aadressiks, taaskäivita teenus ja kinnita, et sokkel liikus: ss -lunp | grep :53 peaks nüüd näitama 10.6.0.1:53 ja mitte ühtegi metamärgi kirjet. Kui see näitab endiselt 0.0.0.0, ei loe töötav protsess faili, mida sa muutsid.

Seejärel testi kliendi poolt, sest ainult see pool loeb. Päring käsuga dig @10.6.0.1 example.com läbib sama tee, mida kasutaja läbib, ja hostis tehtud püük käsuga tcpdump -ni wg0 udp port 53 näitab vastuse lähteaadressi juhtmel. Võrdle seda aadressiga kliendi resolveri seadistuses; kui need on võrdsed, ei ole ajalõpp enam mõistatus.

ip route get 10.6.0.2 selgitab kõiki ülejäänud kummalisusi, sest see trükib liidese ja allika, mida host kliendi poole tagasi kasutaks. Kui see väljund nimetab LAN-i liidest, ei ole sidumise muudatus kogu parandus ja järgmine asi, mida lugeda, on marsruutimistabel.

Mida sidumisseade parandada ei saa

Kuulaja kinninaelutamine ei paranda juurdepääsuloendit, millest tunnelialavõrk puudub, tulemüürireeglit, mis lubab päringu, kuid mitte vastuse, ega puuduvat marsruuti WireGuardi pooli tagasi. Need ebaõnnestuvad lähteaadressist varem või hiljem ja igaühel on eri omanik.

See ei muuda ka seda, millisele ülesvoolule resolver edasi saadab, kas ümbersidumise kaitse lükkab tagasi privaatse vastuse privaatsele nimele, ega seda, kuidas klient rakendab oma otsingudomeene. Need on eraldi seadistused. Muuda sidumisaadressi, kui vastuse allikas on vale, ja midagi muud, kui see pole vale.