AdGuard Home atbild WireGuard klientiem no jūsu LAN adreses

Tuneļa savienojums ir izveidots, ugunsmūris atļauj portu 53, AdGuard Home darbojas, un nosaukumi joprojām netiek atrisināti WireGuard klientam. Pieprasījums parasti pienāk un atbilde parasti tiek nosūtīta, tāpēc pakešu skaitītāji risinātājā izskatās veselīgi un pakalpojums šķiet nevainīgs. Tas, kas noiet greizi, ir atbildes avota adrese: tā iznāk no lokālas adreses, kuru klients nekad neprasīja, un klienta īsa risinātāja programmatūra to atmest. Viens saraksts AdGuard Home konfigurācijā lemj par to, un parasti noklusējuma iestatījums šo lēmumu nodod kodolam.

Pieprasījums pienāk, atbilde iziet no citas vietas

Klients, kurš konfigurēts ar 10.6.0.1 kā savu resolveri, nosūta UDP pieprasījumu uz 10.6.0.1 portu 53. Šis pakets pāriet caur tuneli un nonāk uz saimniekdatora, un to atbild AdGuard Home. Tomēr uz tīkla līnijas atbilde ir jauns pakets, kura avota adrese tiek izvēlēta pēc saimniekdatora tīkla steka, nevis pēc klienta gaidām.

Kad klienta resolveris ir savienots ligzda, ko izmanto systemd-resolved, dnsmasq un lielākā daļa stub resolveru, tas pieņem tikai atbildes no precīzas adreses, uz kuru tas nosūtīja pieprasījumu. Atbilde, kas nāk no 192.168.1.10 uz pieprasījumu, nosūtītu uz 10.6.0.1, tiek noraidīta, pirms notiek kāda parsināšana. Resolveris reģistrē veiksmīgu atbildi, klients reģistrē laika pārsniegšanu, un abi saka patiesību.

Tātad skaitītāji nemelo, un arī klients nemelo. Pierādījumi, kas jums nepieciešami, atrodas trīs vietās, šādā secībā: adresē, pie kuras piesaistīts klausītājs, maršrutā, ko kodols izmantotu, lai atgrieztos pie klienta, un avota adrese faktiskajā atbildes paketē.

Kā kodols izvēlas atbildes avotu

UDP ligzdai, kas piesaistīta0.0.0.0, nav sava avota adreses, tāpēc katra iznākuma atbilde izraisīs maršruta meklēšanu galamērķim. Pēc tam kodols izmanto avotu no šī maršruta: adresi, ko piespraudis maršruts, vai izejošā interfeisa primāro adresi. Nekas par pieprasījuma galamērķa adresi netiek atcerēts.

Vienam saimniekdatoram tas ir neredzams, jo pastāv tikai viens ticams atbildes variants. Mašīnā, kas tur gan LAN adresi, gan WireGuard adresi, gan pārvaldības adresi, vairāki atbildes varianti ir ticami, un uzvarētājs ir atkarīgs no maršrutēšanas tabulas tajā brīdī. Pievienojiet papildu maršrutu, otru adresi uz tā paša interfeisa, NAT pāradresējumu pirms resolvera vai palaidiet AdGuard konteinerā ar savu vārdu telpu, un izvēlētais avots var atšķirties no tā, ko pieprasīja klients.

ss -lunp | grep :53parāda, kurā spēlē jūs esat. Klausītājs uz0.0.0.0:53ir vispārējais gadījums; klausītājs uz10.6.0.1:53jau ir piesaistījis atbildi. Ligzdas lasīšana ir ātrāka nekā YAML lasīšana, un tā atspoguļo to, kas patiesībā darbojas, nevis to, kas tika saglabāts pēdējo reizi.

Kas bind_hosts patiesībā kontrolē

AdGuard Home'sdns.bind_hostsir vietējo adresu saraksts, ko izmanto DNS klausītājs. Piegādātais noklusējums ir universālais simbols (wildcard), kas nozīmē, ka tiek pieņemts uz katras vietējās adreses un ļauj kodolam izvēlēties avota adresi katrai atbildei. Universālā simbola aizstāšana ar adresi, uz kuru klienti veic vaicājumu, maina ligzdu un kopā ar to avota adresi katrā atbildē.

Saraksts var saturēt vairākus ierakstus, kas ir būtiski risinātājā, kas apkalpo divas tīklos esošas vietas. Saraksta10.6.0.1un192.168.1.10pievienošana nodrošina divas piesaistītas ligzdas, un vaicājums, kas ierodas uz jebkuru no tām, tiek atbildēts no adreses, uz kuras tas ieradās. Tas ir uzvedības veids, ko lielākā daļa cilvēku pieņem, ka universālais simbols jau nodrošina.

YAML ir vienkāršs, un adrese tajā ir tā, kuru jūsu tuneļa klientiem tika norādīts izmantot, nevis galvenā saimnieka adrese:

dns:
  bind_hosts:
    - 10.6.0.1
  port: 53

Kāpēc divas vienas risinātāja instalācijas nesakrīt

Spraudņa pārvaldīts, šajā kontekstā, nozīmē, ka atrisinātājs tika instalēts un tiek uzraudzīts no cita pakotnes: maršrutētāja programmaparatūras pakotnes, NAS pakotnes vai mājas automatizācijas papildinājuma. Šī pakotne parasti nodrošina savu AdGuard Home YAML kopiju un restartē procesu pēc savas grafika, kamēr atsevišķs instances ir ražotāja binārā vai konteineris, kuru jūs konfigurējat pats. Jebkurā gadījumā jūs skatāties uz diviem neatkarīgiem procesiem ar atsevišķiem konfigurācijas failiem un atsevišķām sasaistes izvēlēm, pat ja abi lasa to pašu augšupielādes sarakstu un tās pašas filtru sarakstus. Viens var sasaistīt konkrēto tuneļa adresi, kamēr otrs manto vispārīgo, un tīmekļa saskarne izskatās identiska abpusējās pusēs.

Tāpēc “tas pats atrisinātājs darbojās pirms migrācijas” neko neapliecina par pašreizējo saistību. Pārbaudiet ligzdu, pēc tam pārbaudiet konfigurācijas failu, kuru patiešām ielādē darbības procesā. Novecojusi kopija citā direktorijā bieži ir iemesls, kāpēc rediģējums šķiet neefektīvs.

Fiksējiet to, pēc tam testējiet no tunelēšanas puses

Aizstājietbind_hostsar tunelēšanas adresi, restartējiet servisu un pārliecinieties, ka ligzda ir pārvietojusies:ss -lunp | grep :53tagad vajadzētu rādīt10.6.0.1:53un nevienu universālu ierakstu. Ja tas joprojām rādā0.0.0.0,, tad darbības process nelasa failu, kuru jūs rediģējāt.

Pēc tam testējiet no klienta puses, jo tā ir vienīgā puse, kas ir svarīga. Vaicājums ardig @10.6.0.1 example.compārbauda ceļu, ko lietotājs izmanto, un uztvere uz saimniekdatora artcpdump -ni wg0 udp port 53parāda atbildes avota adresi tīklā. Salīdzini to ar adresi klienta resolvera iestatījumos; kad tās sakrīt, taimauta noslēpums pazūd.

ip route get 10.6.0.2izskaidro jebkuru pāri palikušo dīvainību, jo tas izdrukā interfeisu un avotu, ko hosts izmantotu, lai atbildētu klientam. Ja šajā izvaddatnē tiek norādīts LAN interfeiss, bind izmaiņa nav pilnīgais risinājums, un nākamā lieta, ko izlasīt, ir maršrutēšanas tabula.

Ko bind iestatījums nevar salabot

Klausītāja piespraušana nesalabo piekļuves sarakstu, kas izlaiž tuneļa apakštīklu, ugunsmūra noteikumu, kas atļauj vaicājumu, bet ne atbildi, vai trūkstošu maršrutu atpakaļ uz WireGuard baseinu. Tie neveicas agrāk vai vēlāk nekā avota adrese, un katram ir atšķirīgs īpašnieks.

Tas arī nemainauz kuru augšupstrādes resolvers pārsūta, vai pārsaiste aizsardzība noraida privātu atbildi uz privātu vārdu, vai kā klients piemēro savus meklēšanas domēnus. Tie ir atsevišķi kontroles mehānismi. Mainiet saistīšanas adresi, kad atbildes avots ir nepareizs, un mainiet kaut ko citu, kad tas nav tāds.