AdGuard Home нь LAN хаягаасаа WireGuard үйлчлүүлэгчдэд хариу өгдөг

Туннель ажиллаж байна, гал хамгаалагч порт 53-г зөвшөөрдөг, AdGuard Home ажиллаж байна, гэхдээ WireGuard клиентэд нэрс хэвээр шийдэгддэггүй. Хүсэлт хэвийн ирдэг бөгөөд хариу хэвийн явдаг, тиймээс шийдвэрлэгчийн пакетуудын тоолуурууд хэвийн харагдаж, үйлчилгээ гэмт хэрэггүй мэт санагддаг. Алдаа болж буй зүйл нь хариу бичигчийн эх үүсвэр хаяг: энэ нь клиент асуугаагүй орон нутгийн хаягаас гарч байгаа бөгөөд клиентын stub шийдвэрлэгч үүнийг хаяж байна. AdGuard Home-ийн тохиргооны нэг жагсаалт үүнийг шийддэг бөгөөд түүний үндсэн тохиргоо шийдвэрийг kernel-д шилжүүлдэг.

Хүсэлт ирдэг, харин хариу нь өөр газраас гардаг

10.6.0.1-г өөрийн тайлбарлагчийн (resolver) хаягаар тохируулсан үйлчлүүлэгч (client) UDP асуулт (query)-ыг 10.6.0.1 порт 53 руу илгээдэг. Тэр пакет нүхээр дамжин хост дээр хүрч, AdGuard Home хариулдаг. Гэхдээ сүлжээнд явсан үед, хариулт нь шинэ пакет болж, эх сурвалжийн хаягийг хостын стек (stack) сонгосон байдаг, үйлчлүүлэгчийн хүлээлтээс шалтгаалан биш.

Хэрэв үйлчлүүлэгчийн тайлбарлагч нь холбогдсон сокет (connected socket) бол, энэ нь systemd-resolved, dnsmasq болон ихэнх stub resolvers ашигладаг шинж юм, тэр зөвхөн яг илгээсэн хаягаас ирсэн хариултыг хүлээн авдаг. 192.168.1.10-оос ирсэн хариулт 10.6.0.1 руу илгээгдсэн асуултад зориулан задлах явцад унагагдана. Тайлбарлагч амжилттай хариулт авсан гэж бүртгэдэг, үйлчлүүлэгч хугацаа дууссан гэж бүртгэдэг, хоёр нь ч үнэн мэдээллийг өгч байна.

Тэгэхээр тоолуурууд худлаа хэлээгүй, мөн үйлчлүүлэгч ч худлаа хэлээгүй байна. Танд хэрэгтэй нотолгоо гуравхан газар байдаг, дарааллаар нь: сонсогчтой холбогдсон хаяг, цөмийн систем үйлчлүүлэгч рүү буцахад ашиглах зам, мөн бодит хариу багц дээрх эх үүсвэрийн хаяг.

Кернел хариу эх сурвалжийг хэрхэн сонгодог вэ

UDP сокет холбогдсон0.0.0.0Өөрийн эх сурвалжийн хаяг байхгүй тул гарч буй хариулт бүр очих газрыг хайх үйлдлийг эхлүүлдэг. Дараа нь цөм нь эх сурвалжийг тэр замаас авдаг: тухайн замаар тогтоосон хаяг эсвэл гарч буй интерфэйсний үндсэн хаяг. Асуулгын очих газрын хаяг ямар ч хэлбэрээр санагдахгүй.

Нэг л гэрийн сүлжээгээр холбогдсон хост дээр энэ илрээгүй байдаг, учир нь зөвхөн một боломжтой хариулт байдаг. LAN хаяг, WireGuard хаяг болон удирдлагын хаягтай машин дээр хэд хэдэн хариулт боломжтой, ба ялагч тухайн мөчийн маршрутын хүснэгтээс хамаарна. Нэмэлт маршрут нэмэх, ижил интерфэйс дээр хоёр дахь хаяг үүсгэх, туслагчийн урд NAT чиглүүлэгч тавих, эсвэл AdGuard-г өөр нэрийн зайтай контейнерт ажиллуулах, тэгвэл сонгогдсон эх үүсвэр нь хэрэглэгч асуусан хариултаас ялгаатай байж болно.

ss -lunp | grep :53ямар тоглоомд байгаагаа харуулна.0.0.0.0:53дээрх сонсогч бол бүх боломжит тохиолдол;10.6.0.1:53дээрх сонсогч аль хэдийн хариултыг нарийвчлан тогтоосон. Сокет унших нь YAML уншихаас хурдан бөгөөд энэ нь яг юу ажиллаж байгааг илэрхийлдэг, сүүлийн удаа хадгалагдсан зүйлээс биш.

Bind_hosts үнэндээ юу хянадаг

AdGuard Home-ынdns.bind_hostsнь DNS сонсогч ашигладаг орон нутгийн хаягуудын жагсаалт юм. Анх суулгасан тохиргооны хувьд бүх хаягт хүлээн авахыг илэрхийлдэг wildсard бөгөөд үүнд kernel хариулт бүрт эх сурвалжийг сонгоно. Wildcard-г хэрэглэгчид асуусан хаяг руу солих нь socket-г солих бөгөөд үүнтэй хамт бүх хариултанд эх сурвалжийн хаяг нь өөрчлөгдөнө.

Жагсаалт нь нэгээс илүү оруулгыг авч болно, энэ нь хоёр сүлжээнд үйлчилдэг resolver-д чухал үүрэгтэй. Жагсаах нь10.6.0.1ба192.168.1.10хоёр холбоос socket үүсгэнэ, мөн аль нэг дээр ирсэн асуулт нь ирсэн хаягаас нь хариу авдаг. Энэ нь ихэнх хүмүүс wildcard аль хэдийн өгдөг гэж боддог үйлдэл юм.

YAML нь энгийн бөгөөд үүнд байгаа хаяг нь таны туннель хэрэглэгчид ашиглахыг хэлсэн хаяг бөгөөд хостын гол хаяг биш юм:

dns:
  bind_hosts:
    - 10.6.0.1
  port: 53

Нэг resolver-ийг хоёр удаа суулгасны улмаас хэрхэн зөрчилддөг

Энд plugin-ээр удирддаг гэдэг нь Resolver-г өөр багц суулгаж, хянаж байгааг хэлж байна: маршрутизаторын firmware багц, NAS багц, эсвэл гэрийн автоматжуулалтын нэмэлт. Тэр багц нь ихэвчлэн AdGuard Home-ийн YAML хувилбарыг өөрөө агуулж, процессийг өөрийн цагийн хуваарьт тохируулан дахин эхлүүлдэг бол, бие даасан хувилбар нь та өөрөө тохируулдаг үйлдвэрлэгчийн binary эсвэл контейнер юм. Аль ч замаар харсан хоёр тусдаа процесс, тусдаа тохиргооны файлууд, тусдаа bind сонголттой байдаг, аль аль нь ижил upstream жагсаалт болон ижил шүүлтүүр жагсаалтыг уншсан ч гэсэн. Нэг нь тодорхой туннелийн хаягт bind хийж чаддаг бол нөгөө нь wildcard-г өвлөн авдаг, ба веб интерфэйс аль тал ч адилхан харагддаг.

Тийм учраас “миграциас өмнө нэг л шийдэгч ажиллаж байсан” нь одоогийн холбоо барилтын талаар юу ч батлахгүй. Сокетыг шалгаад, дараа нь ажиллаж байгаа процесс үнэхээр ачаалсан тохиргооны файлыг шалгаарай. Өөр нэг директорид хуучирсан хувь байх нь засварт нөлөөгүй мэт харагдах нийтлэг шалтгаан юм.

Түүнийг шургуулж, дараа нь нүхний талаас туршиж үзээрэй

Өөрчлөхbind_hostsтуннелийн хаяг руу, үйлчилгээг дахин эхлүүлж, сокет шилжсэн эсэхийг баталгаажуулна уу:ss -lunp | grep :53одоо харуулах ёстой10.6.0.1:53мөн ямар ч агуулгын оролт байхгүй. Хэрэв энэ нь одоо ч гэсэн гарч байвал0.0.0.0,ажиллаж буй процесс та засварласан файлыг уншиж байгаагүй.

Дараа нь клиентээс туршина, учир нь тэнд л гол асуудал оршдог. Асуулт ньdig @10.6.0.1 example.comхэрэглэгчийн дасгалыг дасгалжуулдаг, ба хост дээр түүвэрлэлт хийдэгtcpdump -ni wg0 udp port 53хариу өгөгчийн эх үүсвэрийн хаягийг утсаар харуулж байна. Үүнийг клиентийн шийдвэр гаргах тохиргоонд байгаа хаягтай харьцуул; тэд тэнцвэл тохиргооны хугацааны дутагдал нууц биш болно.

ip route get 10.6.0.2Дараагийн үлдсэн хачин байдлыг тайлбарлахдаа, учир нь энэ нь интерфэйс болон сервер клиент рүү буцахад ашиглах эх үүсвэрийг хэвлэдэг. Хэрэв энэ гаралт LAN интерфэйсийг заавал нэрлэвэл, bind-ийн өөрчлөлт бүх асуудлыг шийдэхгүй бөгөөд дараагийн хийх зүйл бол чиглүүлэлтийн хүснэгтийг унших явдал юм.

Bind тохиргоо засаж чадахгүй зүйлийг

Сонсогчийг pin хийх нь туннелийн сүлжээний хэсгийг орхисон хандах жагсаалтыг, хайлтыг зөвшөөрөх боловч хариу өгдөггүй гал хамгаалагчийн дүрмийг эсвэл WireGuard сан руу буцах дутуу маршрутыг засдаггүй. Эдгээр нь эх үүсвэрийн хаягаас эрт эсвэл хожим илэрдэг бөгөөд тус бүрийн эзэн ялгаатай.

Мөн энэ нь өөрчилдөггүйшийдвэр гаргагч аль upstream руу дамжуулж байгааг, хувийн нэрэнд зориулсан хувийн хариуг дахин холболтын хамгаалалт нь хаасан эсэх, эсвэл клиент хэрхэн өөрийн хайлтын домэйнуудыг хэрэглэдэг эсэх. Эдгээр нь тусдаа хяналтын хэрэгслүүд юм. Хариулах эх сурвалж буруу байгаа бол bind хаягийг өөрчил, харин бусад тохиолдолд өөр зүйлсийг өөрчил.