AdGuard Home përgjigjet klientëve WireGuard nga adresa juaj LAN

Tuneli është ngritur, firewall-i lejon portën 53, AdGuard Home po funksionon, dhe emrat ende nuk zgjidhen për klientin WireGuard. Pyetja zakonisht arrin dhe përgjigjja zakonisht largohet, kështu që numëruesit e paketave në resolver duken të shëndetshëm dhe shërbimi duket i pafajshëm. Ajo që shkon keq është adresa burimore në atë përgjigje: ajo largohet nga një adresë lokale që klienti kurrë nuk e ka kërkuar, dhe resolver-i stub i klientit hedh atë. Një listë në konfigurimin e AdGuard Home e vendos këtë, dhe parazgjedhja e zakonshme ja dorëzon vendimin kernel-it.

Pyetja arrin, përgjigjja largohet nga diku tjetër

Një klient i konfiguruar me 10.6.0.1 si zgjidhës i tij dërgon një pyetje UDP te 10.6.0.1 porta 53. Ai paketë kalon përmes tunelit dhe arrin te hosti, dhe AdGuard Home i përgjigjet asaj. Në kabllo, megjithatë, përgjigjja është një paketë e re e cila ka adresën e burimit të zgjedhur nga staku i hostit, jo nga pritshmëria e klientit.

Kur zgjidhësi i klientit është një soket i lidhur, që është ajo që përdorin systemd-resolved, dnsmasq dhe shumica e zgjidhësve të vegjël, ai pranon vetëm përgjigje nga adresa e saktë ku e dërgoi më parë. Një përgjigje e dërguar nga 192.168.1.10 për një pyetje të dërguar te 10.6.0.1 hidhet poshtë përpara se të ndodhë ndonjë analizë. Zgjidhësi regjistron një përgjigje të suksesshme, klienti regjistron një koha e kaluar, dhe të dy thonë të vërtetën.

Pra, matësit nuk po gënjejnë dhe as klienti. Dëshmia që ju duhet ndodhet në tre vende, në këtë rend: adresa me të cilën është lidhur dëgjuesi, rruga që do të përdorte bërthama për të kthyer përgjigjen tek klienti, dhe adresa burimore në paketën e vërtetë të përgjigjes.

Si e zgjedh bërthama burimin e përgjigjes

Një socket UDP i lidhur me0.0.0.0nuk ka një adresë burimore të vetën, kështu që çdo përgjigje që dërgohet nis një kërkim të rrugës për destinacionin. Bërthama pastaj merr burimin nga ajo rrugë: adresa fikse nga rruga, ose adresa kryesore e ndërfaqes që dërgon. Asgjë nga adresa e destinacionit të pyetjes nuk mbahet mend.

Në një host me një lidhje, kjo është e padukshme, sepse ekziston vetëm një përgjigje e mundshme. Në një makinë që mban një adresë LAN, një adresë WireGuard dhe një adresë menaxhimi, disa përgjigje janë të mundshme, dhe fituesi varet nga tabela e rutimit në atë moment. Shtoni një rrugë shtesë, një adresë të dytë në të njëjtin ndërfaqe, një redirection NAT përpara resolver-it, ose ekzekutoni AdGuard në një container me hapësirën e tij emërore, dhe burimi i zgjedhur mund të ndryshojë nga ai që klienti ka pyetur.

ss -lunp | grep :53tregon në cilin lojë jeni. Një dëgjues në0.0.0.0:53është rasti wildcard; një dëgjues në10.6.0.1:53ka fiksuar tashmë përgjigjen. Leximi i socket-it është më i shpejtë se leximi i YAML-it, dhe pasqyron atë që është duke u ekzekutuar aktualisht në vend të asaj që është ruajtur së fundi.

Çfarë kontrollon aktualisht bind_hosts

AdGuard Home'sdns.bind_hostsështë lista e adresave lokale që përdor dëgjuesi DNS. Default-i i dërguar është karakteri i përgjithshëm, që do të thotë pranoni në çdo adresë lokale dhe lejoni kernel-in të zgjedhë burimin për çdo përgjigje. Zëvendësimi i karakterit të përgjithshëm me adresën që klientët pyesin ndryshon socket-in, dhe me të, adresën burimore në çdo përgjigje.

Lista mund të përmbajë më shumë se një hyrje, që ka rëndësi për një resolver që shërben dy rrjete. Listimi i10.6.0.1dhe192.168.1.10jep dy socket-e të lidhura, dhe një pyetje që arrin në njërin prej tyre përgjigjet nga adresa nga e cila erdhi. Kjo është sjellja që shumica e njerëzve supozojnë se karakteri i përgjithshëm e ofron tashmë.

YAML është i thjeshtë, dhe adresa në të është ajo që klientët e tunelit tuaj u thanë të përdorin, jo adresa kryesore e host-it:

dns:
  bind_hosts:
    - 10.6.0.1
  port: 53

Pse dy instalime të një resolver-i nuk bien dakord

Menaxhuar nga plugin, në këtë kontekst, do të thotë se zgjidhësi u instalua dhe monitorohet nga një paketë tjetër: një paketë firmware për router, një paketë NAS, ose një shtesë për automatizimin e shtëpisë. Kjo paketë zakonisht shton kopjen e vet të YAML të AdGuard Home dhe rindez procesin sipas orarit të vet, ndërkohë që një instancë e pavarur është binari ose kontenieri i furnizuesit që ju vetë konfiguroni. Në çdo rast, po shikoni dy procese të pavarura me skedarë konfigurimi të ndarë dhe opsione bind të ndara, edhe kur të dy lexojnë të njëjtën listë upstream dhe të njëjtat lista filtrash. Njëri mund të lidhë adresën specifike të tunelit, ndërsa tjetri trashëgon wildcard-in, dhe ndërfaqja web duket identike nga të dy anët.

Prandaj, “i njëjti zgjidhës funksionoi para migrimit” nuk provon asgjë për lidhjen aktuale. Kontrolloni prizën, pastaj kontrolloni skedarin e konfigurimit që procesi që po funksionon e ka ngarkuar vërtet. Një kopje e vjetër në një direktorium tjetër është një arsye e zakonshme përse ndryshimi duket sikur nuk ka efekt.

Nguleni atë, pastaj testoni nga ana e tunelit

Ndryshonibind_hostsnë adresën e tunelit, rinisni shërbimin, dhe konfirmoni që priza u zhvendos:ss -lunp | grep :53tani duhet të tregojë10.6.0.1:53dhe të mos ketë asnjë hyrje universale. Nëse ende tregon0.0.0.0,procesi që po funksionon nuk po lexon skedarin që keni redaktuar.

Pastaj testoni nga klienti, sepse kjo është e vetmja anë që ka rëndësi. Një kërkesë medig @10.6.0.1 example.compërdor rrugën që përdoruesi përdor, dhe një kapje në host metcpdump -ni wg0 udp port 53tregon adresën e burimit të përgjigjes në rrjet. Krahasoni atë me adresën në cilësimin e zgjidhësit të klientit; kur ato janë të barabarta, kohëzgjatja ndalon së qeni një mister.

ip route get 10.6.0.2shpjegon çdo anomali të mbetur, sepse printon ndërfaqen dhe burimin që hosti do të përdorte për t'u kthyer te klienti. Nëse ajo dalje emëron ndërfaqen LAN, ndryshimi i lidhjes nuk është zgjidhja e plotë dhe tabela e rrugeve është gjëja tjetër për të lexuar.

Ajo që cilësimi i lidhjes nuk mund ta rregullojë

Këmbëzimi i dëgjuesit nuk riparon një listë aksesesh që lë jashtë nënrrjetin e tunelit, një rregull tufiresh që lejon kërkesën por jo përgjigjen, ose një rrugë të munguar mbrapsht te grupi i WireGuard. Këto dështojnë më herët ose më vonë se adresa e burimit, dhe secila ka një pronar të ndryshëm.

Ajo gjithashtu nuk ndryshonse cili upstream drejton zgjidhësi, nëse mbrojtja ndaj ribindimit refuzon një përgjigje private për një emër privat, ose se si klienti aplikon domenet e tij të kërkimit. Këto janë kontrolle të veçanta. Ndrysho adresën e lidhjes kur burimi i përgjigjes është i gabuar, dhe ndrysho diçka tjetër kur nuk është.