Vì sao Pi-hole v6 bỏ qua truy vấn DNS từ các máy khách WireGuard

Pi-hole v6 nhận một truy vấn DNS trên cổng 53 rồi quyết định xem gói tin đến có được phép trả lời hay không. Trên máy chủ WireGuard, quyết định thứ hai đó thường là lý do một máy khách bị hết thời gian chờ trong khi trình phân giải trông vẫn khỏe từ LAN. Cổng đang mở, FTL đang chạy, vậy mà không có gì quay lại từ 10.90.0.1. Ba thứ tương tác trước khi một câu trả lời rời đi: dns.interface, dns.listeningMode và tường lửa phía trước cả hai.

Socket lắng nghe không quyết định ai nhận được câu trả lời

FTL mở các bộ lắng nghe UDP và TCP trên cổng 53. Trong cấu hình mặc định, socket thường là wildcard, nên ss -lunp | grep :53 hiển thị 0.0.0.0:53 và [::]:53 bất kể máy khách VPN có được phục vụ hay không. Socket wildcard chấp nhận gói tin, sau đó FTL áp dụng các quy tắc giao diện và nguồn trước khi trả lời. Đó là lý do câu "cổng đang lắng nghe" chứng minh rất ít về một máy khách đường hầm.

Hãy đọc cấu hình đang chạy thay vì tệp bạn cho là đang hoạt động. pihole-FTL --config dns.interface và pihole-FTL --config dns.listeningMode in ra các giá trị thực tế, và chúng có thể khác tệp của máy chủ khi một container, biến môi trường hoặc trình quản lý triển khai sở hữu thiết lập đó. Tài liệu tham chiếu cấu hình Pi-hole FTL liệt kê các chế độ và chế độ nào dựa trên giao diện.

LOCAL hỏi subnet nào, SINGLE hỏi giao diện nào

LOCAL, chế độ mặc định, trả lời các truy vấn có địa chỉ nguồn thuộc một subnet được cấu hình trên một trong các giao diện của máy chủ. Một wg0 đơn giản với 10.90.0.1/24 vượt qua bài kiểm tra đó, vì máy khách ở 10.90.0.2 nằm bên trong subnet của đường hầm. Máy khách được định tuyến ở phía bên kia của một peer, hoặc một máy khách ẩn sau NAT ở tiền tố khác, không vượt qua, dù gói tin đã đến wg0, và không có truy vấn nào xuất hiện trong nhật ký.

SINGLE thay đổi câu hỏi. Nó chấp nhận các truy vấn đến trên giao diện được nêu trong dns.interface, bao gồm loopback, và bỏ qua subnet nguồn. Đây là chế độ tồn tại trong một cấu trúc VPN nối chuỗi hoặc định tuyến. Đặt cả hai khóa cùng nhau, vì một chế độ không có giao diện được nêu không phải là chỉ dẫn đầy đủ:

sudo pihole-FTL --config dns.interface "wg0"
sudo pihole-FTL --config dns.listeningMode "SINGLE"

BIND thay đổi socket, và điều đó có giá

BIND không lọc socket wildcard; nó chỉ liên kết cổng 53 với các địa chỉ tồn tại trên giao diện được nêu, nên nhân từ chối các gói tin đến nơi khác. Nó nghiêm ngặt hơn SINGLE và không phải từ đồng nghĩa của nó. Cái giá xuất hiện khi khởi động: nếu wg0 chưa lên khi FTL khởi động, có thể không có địa chỉ để liên kết, và trình phân giải có thể chạy mà không có bộ lắng nghe cho đến khi giao diện xuất hiện và FTL khởi động lại.

Chọn BIND khi bạn kiểm soát thứ tự khởi động, ví dụ một unit systemd được sắp sau giao diện WireGuard, và khi bạn muốn nhân loại bỏ các gói tin lạc trước khi FTL nhìn thấy chúng. Chọn SINGLE khi đường hầm lên xuống thường xuyên, hoặc khi giao diện được tạo bởi một công cụ khởi động sau FTL.

Tường lửa là cổng thứ hai

Một chế độ FTL đúng vẫn thất bại nếu tường lửa của máy chủ bỏ cổng 53 trên wg0. Cho phép dải nguồn VPN cho cả hai giao thức và giữ phía internet đóng. Trong nftables, với chuỗi input hiện có trong bảng inet filter, các quy tắc trông như sau:

sudo nft add rule inet filter input iifname "wg0" ip saddr 10.90.0.0/24 udp dport 53 accept
sudo nft add rule inet filter input iifname "wg0" ip saddr 10.90.0.0/24 tcp dport 53 accept

Thêm các quy tắc IPv6 tương ứng nếu đường hầm mang IPv6, và đặt chúng trước chính sách drop của chuỗi. Nếu máy chủ dùng ufw hoặc firewalld, hãy diễn đạt cùng sự khớp đó trong trình quản lý ấy thay vì trộn lẫn công cụ. Đừng chuyển tiếp cổng 53 từ bộ định tuyến internet; máy khách nên đến địa chỉ VPN của trình phân giải qua đường hầm.

Hai đường đi vẫn tách biệt. Truy vấn của máy khách kết thúc tại FTL. Các tra cứu thượng nguồn của chính FTL đi ra theo bảng định tuyến của máy chủ, bảng này có thể dùng hoặc không dùng đường hầm, nên một trình phân giải trả lời nhưng không trả về gì hữu ích là vấn đề thượng nguồn. Giao diện quản trị web và API lắng nghe trên cổng riêng và cần giới hạn riêng.

Xác minh câu trả lời và sự từ chối

Từ một máy khách VPN, truy vấn địa chỉ của trình phân giải qua cả hai giao thức: dig @10.90.0.1 example.com và dig +tcp @10.90.0.1 example.com. Sau đó kiểm tra nhật ký truy vấn trong giao diện quản trị để xác nhận FTL đã ghi lại truy vấn. Hết thời gian chờ ở máy khách mà không có mục nhật ký chỉ về tường lửa hoặc bộ lọc giao diện; một mục nhật ký không có câu trả lời chỉ về việc phân giải thượng nguồn.

Kiểm tra đường âm từ một máy chủ bên ngoài VPN. dig @10.90.0.1 example.com sẽ hết thời gian chờ, và ss -lunp trên trình phân giải sẽ không hiển thị cổng 53 gắn với một địa chỉ công cộng. Khởi động lại dịch vụ một lần, sau đó khởi động lại máy chủ và xác nhận trình phân giải vẫn trả lời khi wg0 xuất hiện trở lại. Một truy vấn chỉ hoạt động đến lần khởi động lại tiếp theo chưa phải là thay đổi hoàn tất.