AdGuard Home-k WireGuard bezeroei zure LAN helbideatik erantzuten die

Tunela martxan dago, suebakiak 53. portua baimentzen du, AdGuard Home martxan dago, eta izenak oraindik ez dira konpontzen WireGuard bezeroarentzat. Kontsulta normalean iristen da eta erantzuna normalean irteten da, beraz, resolver-aren pakete-kontagailuak osasuntsuak dirudite eta zerbitzua errugabea dirudi. Okerrena erantzun horretan dagoen iturburuko helbidea da: tokiko helbide batetik ateratzen da, bezeroak inoiz ez duen eskatu, eta bezeroaren stub resolverrak baztertzen du. AdGuard Home-ren konfigurazioko zerrenda batek erabakitzen du hau, eta bere lehenetsia normalean kernelari ematen dio erabakia.

Kontsulta iristen da, erantzuna bestelako toki batetik ateratzen da

Bezero bat 10.6.0.1 bidez konfiguratutako bere ebazlea izango da eta UDP kontsulta bat bidaltzen du 10.6.0.1 helbidera, 53 portuaren bidez. Paket hori tunelatik pasatzen da eta hostean iristen da, eta AdGuard Home-ek erantzuten dio. Hala ere, sarean, erantzuna pakete berri bat da, non iturburu helbidea hostaren stackak aukeratzen duen, bezeroaren esperoaren arabera ez.

Bezeroaren ebazlea konexio-puntu bat denean, hau da, systemd-resolved, dnsmasq eta stub ebazle gehienek erabiltzen duten modua, bidalitako helbide zehatzetik iristen diren erantzunak bakarrik onartzen ditu. 192.168.1.10 helbidetik datorren erantzun bat, 10.6.0.1 helbidera bidalitako kontsulta bati, jasoko ez da, ulermena hasi baino lehen. Ebazleak erantzun arrakastatsua jasotzen duela jasotzen du, bezeroak epea amaitu dela jasotzen du, eta biek egia esaten dute.

Beraz, kontagailuak ez dira gezurretan ari eta bezeroa ere ez. Behar duzun froga hiru lekutan dago, honako hurrenkera honetan: entzuleak lotuta duen helbidean, kernelak bezeroarengana itzultzeko erabiliko lukeen ibilbidean, eta benetako erantzun paketean dagoen iturburu helbidean.

Nola aukeratzen duen kernelak erantzun iturburua

UDP soketa batek lotuta0.0.0.0ez du bere iturburu helbiderik, beraz, irteerako erantzun bakoitzak helmugako ibilbide bilaketa bat pizten du. Kernelak, ondoren, ibilbide horretatik hartzen du iturburua: ibilbideak pinatutako helbidea, edo irteerako interfaze nagusia. Kontsultaren helmuga helbideari buruzko ezer ere ez da gogoratzen.

Bakarrik etxeko gailu batean hau ez da ikusgai, koska erantzun plausible bakarra dagoelako. LAN helbidea, WireGuard helbidea eta kudeaketa helbidea dituen makinaren batean, hainbat erantzun plausible daude, eta irabazlea une horretako ibilbide taularen arabera izango da. Gehitu ibilbide osagarria, helbide bigarren bat interfaze berean, NAT birbiderketa ebatzailea aurrean, edo exekutatu AdGuard kontainer batean bere izena izenekin, eta hautatutako iturburuak ezberdina izan daiteke bezeroak kontsultatutakoarekin.

ss -lunp | grep :53erakusten du zein jokoan zauden.0.0.0.0:53gaineko entzule bat kasu orokorra da;10.6.0.1:53gaineko entzule batek erantzuna jadanik finkatu du. Soketa irakurtzea YAML-a irakurtzea baino azkarragoa da, eta benetan exekutatzen ari dena islatzen du, azken aldiz gordeta zegoena baino.

Zerk kontrolatzen duen bind_hosts benetan

AdGuard Home-rendns.bind_hostsDNS entzuleak erabiltzen dituen tokiko helbideen zerrenda da. Lehenetsitako konfigurazio bidalia izar-marka da, honek esan nahi du onartu tokiko helbide guztietan eta kernelari utzi itzulitako erantzunaren iturburua aukeratzen. Istar-marka ordezkatzea bezeroek kontsultatzen duten helbidearekin soketa aldatzen du, eta horrekin batera erantzun bakoitzeko iturburu helbidea ere aldatzen da.

Zerrendak sartze bat baino gehiago onartzen du, garrantzitsua izanik bi sare zerbitzatzen dituen bereizlearentzat. Sartzea10.6.0.1eta192.168.1.10bi soketa lotu ematen ditu, eta kontsulta bat edozeinetik iristen bada, iristen den helbide beretik erantzuten da. Hau da gehienek asumitzen dutena isar-markak jada ematen duena.

YAML-a sinplea da, eta horren barruko helbidea zure tunel bezeroei erabil dezaten esandakoa da, ez ostalariaren helbide nagusia:

dns:
  bind_hosts:
    - 10.6.0.1
  port: 53

Zergatik ados ez dauden bereizle baten bi instalazio

Pluginak kudeatuta, testuinguru honetan, esan nahi du ebazlea beste pakete batek instalatu eta gainbegiratzen duela: ibilbide emateko firmware pakete bat, NAS pakete bat edo etxeko automatizaziorako gehigarri bat. Pakete horrek normalean AdGuard Home-ren YAML-en kopia propioa bidaltzen du eta prozesua bere ordutegian berrabiarazten du, bitartean adierazpen bakarreko instantzia erabili ahal denban konfiguratzen duzun hornitzailearen binarioa edo kontainerraren bidez. Edozein kasutan, bi prozesu independente dituzu, banakako konfigurazio fitxategiekin eta banakako lotura-aukerak dituztenak, nahiz eta biek goi-mailako zerrenda berdina eta iragazki-zerrenda berdina irakurri. Batekoak tunel helbide zehatza lotu dezake, bestek berriz komatakinaren ondorengo helbidea jasotzen du, eta web interfazea alde batetik edo bestetik berdina dirudi.

Horregatik, “bertsio bera aurrez migratu aurretik funtzionatu zuen” ez du ezer frogatzen egungo loturari buruz. Egiaztatu konexioa, gero egiaztatu martxan dagoen prozesuak benetan kargatu duen konfigurazio fitxategia. Beste direktorio batean dagoen kopia zaharkitua ohiko arrazoia da editatzeak inolako eraginik ez duela ematen.

Finkatu, gero probatu tunneleko aldetik

Aldatubind_hoststunelaren helbidearekin, berrabiarazi zerbitzua, eta egiaztatu konexioa aldatu dela:ss -lunp | grep :53orain erakutsi beharko luke10.6.0.1:53eta ez dago inongo ondoko sarrerarik. Oraindik ere0.0.0.0erakusten badu,martxan dagoen prozesuak ez du zuk editatutako fitxategia irakurtzen.

Gero probatu bezeroaren aldetik, hori delako bakarrik garrantzitsua den aldea.dig @10.6.0.1 example.combateko kontsultak erabiltzaileak erabiltzen duen bidea probatzen du, eta hostean egindako harrapaketa batek montré egiten dutcpdump -ni wg0 udp port 53harrapaketaren iturri helbidea kablean erakusten du. Konparatu bezeroaren ebazlearen ezarpeneko helbidearekin; berdinak direnean, denbora-muga ez da misterioa izaten.

ip route get 10.6.0.2gainerako bitxikeria azaltzen du, koska bezeroari atzera bidaliko liokeen hostearen interfaze eta iturria inprimatzen dituelako. Irteera horrek LAN interfaze izena badu, loturaren aldaketa ez da konponketa osoa eta hurrengo irakurketarako zerbait da ibilbide-taula.

Loturaren ezarpenak ezin duena

Entzulea finkatzeak ez du konpontzen tunel azpidomeinuak baztertzen dituen sarrera-zerrenda, kontsulta onartzen duen baina erantzunik ez ematen duen suteen hormaren araua, edo WireGuard-eko pool-era itzultzeko bidegabea. Horiek iturri helbidearen aurretik edo ondoren huts egiten dute, eta bakoitzak jabe desberdin bat du.

Gainera, ez du aldatzenzein behera-mailako itzultzaileari bidaltzen dion, berriro lotzeko babesa izen pribatu baterako erantzun pribatu bat baztertzen duen ala ez, edo nola aplikatzen dituen bezeroak bere bilaketa-domeinuak. Kontrol bereiziak dira horiek. Aldatu lotura helbidea erantzun iturria okerra denean, eta aldatu beste zerbait oker ez denean.