AdGuard Home Trả Lời Các Khách Hàng WireGuard Từ Địa Chỉ LAN Của Bạn

Đường hầm đã hoạt động, tường lửa cho phép cổng 53, AdGuard Home đang chạy, nhưng tên miền vẫn không được phân giải cho client WireGuard. Truy vấn thường được gửi đến và câu trả lời thường được trả về, vì vậy bộ đếm gói trên bộ phân giải trông vẫn ổn và dịch vụ có vẻ vô tội. Điều sai là địa chỉ nguồn trên câu trả lời đó: nó được gửi đi từ một địa chỉ cục bộ mà client chưa từng yêu cầu, và trình phân giải stub của client loại bỏ nó. Một danh sách trong cấu hình của AdGuard Home quyết định điều này, và mặc định thông thường sẽ giao quyết định cho kernel.

Truy vấn đến, câu trả lời đi từ nơi khác

Một client được cấu hình với 10.6.0.1 làm resolver của nó gửi một truy vấn UDP đến 10.6.0.1 cổng 53. Gói tin đó đi qua tunnel và đến host, và AdGuard Home sẽ trả lời nó. Tuy nhiên, trên đường truyền, phản hồi là một gói mới có địa chỉ nguồn được chọn bởi stack của host, không phải theo mong đợi của client.

Khi resolver của client là một socket kết nối, điều mà systemd-resolved, dnsmasq và hầu hết các stub resolver sử dụng, nó chỉ chấp nhận các phản hồi từ đúng địa chỉ mà nó đã gửi đến. Một phản hồi có nguồn từ 192.168.1.10 đến truy vấn gửi đến 10.6.0.1 sẽ bị loại bỏ trước khi bất kỳ việc phân tích nào xảy ra. Resolver ghi lại một trả lời thành công, client ghi lại hết thời gian chờ, và cả hai đều nói sự thật.

Vì vậy các bộ đếm không nói dối và khách hàng cũng không. Bằng chứng bạn cần nằm ở ba nơi, theo thứ tự sau: địa chỉ mà người nghe bị ràng buộc, tuyến đường mà kernel sẽ sử dụng để quay lại client, và địa chỉ nguồn trên gói phản hồi thực tế.

Cách kernel chọn địa chỉ nguồn phản hồi

Một socket UDP được ràng buộc với0.0.0.0không có địa chỉ nguồn riêng, vì vậy mỗi phản hồi đi ra sẽ kích hoạt một tra cứu tuyến đường cho đích đến. Kernel sau đó lấy địa chỉ nguồn từ tuyến đó: địa chỉ được cố định bởi tuyến, hoặc địa chỉ chính của giao diện đi ra. Không có gì về địa chỉ đích của truy vấn được ghi nhớ.

Trên một máy chủ chỉ có một giao diện mạng, điều này không hiển thị, vì chỉ có một câu trả lời hợp lý. Trên một máy giữ địa chỉ LAN, địa chỉ WireGuard và địa chỉ quản lý, có nhiều câu trả lời khả thi, và câu trả lời được chọn phụ thuộc vào bảng định tuyến vào thời điểm đó. Thêm một tuyến bổ sung, một địa chỉ thứ hai trên cùng một giao diện, một chuyển hướng NAT trước bộ giải quyết tên, hoặc chạy AdGuard trong một container với namespace riêng, và nguồn được chọn có thể khác với nguồn mà client đã truy vấn.

ss -lunp | grep :53chỉ ra bạn đang ở trong trò chơi nào. Một listener trên0.0.0.0:53là trường hợp wildcard; một listener trên10.6.0.1:53đã cố định câu trả lời. Đọc socket nhanh hơn đọc YAML, và nó phản ánh những gì đang thực sự chạy thay vì những gì được lưu lần cuối.

Những gì bind_hosts thực sự điều khiển

AdGuard Home'sdns.bind_hostslà danh sách các địa chỉ cục bộ mà trình nghe DNS sử dụng. Mặc định được cung cấp là ký tự đại diện, có nghĩa là chấp nhận trên mọi địa chỉ cục bộ và để nhân hệ điều hành chọn địa chỉ nguồn cho từng phản hồi. Thay ký tự đại diện bằng địa chỉ mà khách hàng truy vấn sẽ thay đổi socket, và theo đó thay đổi địa chỉ nguồn trên mỗi câu trả lời.

Danh sách có thể chứa nhiều hơn một mục, điều này quan trọng đối với một trình phân giải phục vụ hai mạng. Liệt kê10.6.0.1và192.168.1.10sẽ tạo hai socket ràng buộc, và một truy vấn đến bất kỳ socket nào cũng sẽ được trả lời từ địa chỉ mà nó đến. Đó là hành vi mà hầu hết mọi người cho rằng ký tự đại diện đã cung cấp.

YAML là dạng thuần, và địa chỉ trong đó là địa chỉ mà các khách hàng sử dụng đường hầm của bạn được yêu cầu sử dụng, không phải địa chỉ chính của máy chủ:

dns:
  bind_hosts:
    - 10.6.0.1
  port: 53

Tại sao hai cài đặt của cùng một trình phân giải lại không đồng ý

Trong bối cảnh này, quản lý bởi plugin có nghĩa là resolver được cài đặt và giám sát bởi một gói khác: một gói firmware router, một gói NAS, hoặc một add-on tự động hóa tại nhà. Gói đó thường đi kèm với bản sao YAML riêng của AdGuard Home và khởi động lại tiến trình theo lịch trình riêng của nó, trong khi một phiên bản độc lập là nhị phân hoặc container của nhà cung cấp mà bạn tự cấu hình. Dù theo cách nào, bạn đều đang xem xét hai tiến trình độc lập với các tập tin cấu hình riêng biệt và các lựa chọn bind riêng, ngay cả khi cả hai đều đọc cùng danh sách upstream và cùng danh sách bộ lọc. Một tiến trình có thể bind địa chỉ tunnel cụ thể trong khi tiến trình kia kế thừa wildcard, và giao diện web trông giống nhau từ cả hai phía.

Đó là lý do tại sao "cùng một resolver đã hoạt động trước khi di chuyển" không chứng tỏ gì về liên kết hiện tại. Kiểm tra ổ cắm, sau đó kiểm tra tệp cấu hình mà tiến trình đang chạy thực sự đã tải. Một bản sao cũ trong thư mục khác là lý do phổ biến khiến việc chỉnh sửa có vẻ không có hiệu lực.

Ghim nó lại, sau đó thử từ phía hầm

Thay đổibind_hostsđến địa chỉ hầm, khởi động lại dịch vụ và xác nhận socket đã di chuyển:ss -lunp | grep :53nên hiển thị bây giờ10.6.0.1:53và không có mục nhập ký tự đại diện. Nếu nó vẫn hiển thị0.0.0.0,quá trình đang chạy không đọc tệp mà bạn đã chỉnh sửa.

Sau đó kiểm tra từ phía khách hàng, vì đó là bên duy nhất quan trọng. Một truy vấn vớidig @10.6.0.1 example.comthực hành con đường mà người dùng thực hành, và một bản ghi lại trên máy chủ vớitcpdump -ni wg0 udp port 53hiển thị địa chỉ nguồn của phản hồi trên mạng. So sánh nó với địa chỉ trong cài đặt bộ phân giải của client; khi chúng bằng nhau, thời gian chờ không còn là điều bí ẩn.

ip route get 10.6.0.2giải thích bất kỳ điều kỳ lạ còn lại nào, vì nó in ra giao diện và nguồn mà host sẽ sử dụng để trả về client. Nếu đầu ra đó tên giao diện LAN, việc thay đổi bind không phải là toàn bộ giải pháp và bảng định tuyến là thứ tiếp theo cần đọc.

Những gì cài đặt bind không thể sửa

Gắn listener không sửa được danh sách truy cập mà bỏ qua subnet tunneling, quy tắc tường lửa cho phép truy vấn nhưng không cho phản hồi, hoặc lộ trình bị thiếu trở về pool WireGuard. Những trường hợp đó thất bại sớm hơn hoặc muộn hơn địa chỉ nguồn, và mỗi trường hợp có chủ sở hữu khác nhau.

Nó cũng không thay đổibộ phân giải sẽ chuyển tiếp lên phía trên nào, liệu bảo vệ ràng buộc lại có từ chối một câu trả lời riêng tư cho một tên riêng tư hay cách mà khách hàng áp dụng các miền tìm kiếm của chính nó. Đó là những kiểm soát riêng biệt. Thay đổi địa chỉ bind khi nguồn trả lời sai, và thay đổi một thứ khác khi nó không sai.