Pi-hole không chặn quảng cáo sau khi VPN kết nối: năm bước kiểm tra

Quảng cáo vẫn hiển thị trên một máy khách, Pi-hole báo mình khỏe mạnh và đường hầm đang hoạt động, nên phản xạ là định tuyến lưu lượng của máy khách đó qua Pi. Đó là ngã rẽ sai. Việc lọc cần các câu hỏi, không phải các gói tin, và một máy khách có truy vấn đi tới trình phân giải của nhà cung cấp vẫn không được lọc dù lưu lượng của nó chảy đi đâu. Đi qua danh sách này theo thứ tự và dừng ở bước đầu tiên thất bại, vì bước sau không thể nói gì trong khi bước trước đã hỏng.

1. Đọc trình phân giải mà máy khách thực sự dùng

Hỏi máy khách, không hỏi bộ định tuyến. Trên Linux, resolvectl status in ra các máy chủ DNS theo từng liên kết và liên kết nào thắng; chỉ riêng /etc/resolv.conf thường là một stub trỏ tới 127.0.0.53. Trên Windows, ipconfig /all liệt kê các máy chủ do DHCP cấp theo từng bộ điều hợp, và trên macOS scutil --dns hiển thị điều tương tự theo phạm vi. Nếu câu trả lời không phải địa chỉ của Pi-hole, bạn có vấn đề gán và bước 2 là nơi nó nằm.

Hai thứ đánh bại trình phân giải của hệ thống ngay cả khi nó được đặt đúng. Các trình duyệt có DNS bảo mật riêng (tùy chọn “Use secure DNS” của Chrome, network.trr.mode của Firefox) gửi truy vấn qua HTTPS tới một trình phân giải công cộng và không bao giờ mở cổng 53. Và một máy khách VPN trên chính máy khách có thể cài một máy chủ DNS trên giao diện đường hầm của nó với miền định tuyến ~., điều này làm cho liên kết đó có thẩm quyền với mọi tên.

Kiểm tra con đường mà ứng dụng đi, không phải con đường mà công cụ gỡ lỗi đi. resolvectl query example.com cho biết liên kết nào đã trả lời, và getent hosts example.com đi qua cùng đường NSS như một ứng dụng; trên macOS, dscacheutil -q host -a name example.com đọc các trình phân giải theo phạm vi mà scutil --dns liệt kê. Một lệnh dig trần không làm điều này: nó đọc /etc/resolv.conf và bỏ qua việc chọn theo liên kết, nên nó có thể trả lời từ Pi-hole trong khi mọi ứng dụng dùng trình phân giải được đẩy, và đó chính là lỗi mà danh sách này tồn tại để bắt. Giữ dig @192.168.1.53 để kiểm tra một máy chủ cụ thể.

2. Xác nhận ai là người phân phát câu trả lời

Việc gán đến từ bất cứ thứ gì trả lời DHCP. Trên dnsmasq đó là một dòng, dhcp-option=6,192.168.1.53; trong giao diện web của bộ định tuyến đó là trường DNS trong phần DHCP của LAN. Máy khách phải gia hạn trước khi thấy nó. Một thiết bị đã bật nhiều ngày vẫn giữ hợp đồng thuê cũ, và một thiết bị có trình phân giải được gõ tay giữ nó mãi mãi. Gia hạn trên một máy khách thử nghiệm thay vì giả định sự lan truyền.

IPv6 là nửa bị bỏ quên. Các thông báo của bộ định tuyến có thể mang máy chủ DNS riêng của chúng (RDNSS), và trên OpenWrt đó là tùy chọn ra_dns của odhcpd; một máy khách ưu tiên IPv6 dùng máy chủ đó trong khi tùy chọn DHCPv4 bạn vừa đặt vẫn không được dùng. Nếu bạn chưa sẵn sàng phục vụ DNS qua IPv6, hãy chỉ xóa thông báo DNS: ra_dns trong odhcpd, hoặc tùy chọn RDNSS trong bất cứ thứ gì trả lời thông báo của bộ định tuyến. Tắt toàn bộ thông báo cũng gỡ bỏ việc đánh địa chỉ IPv6 khỏi LAN, đó là thay đổi lớn hơn nhiều so với ý định của bạn, trong khi chỉ xóa tùy chọn DNS giữ nguyên việc đánh địa chỉ và làm cho RDNSS còn thiếu hiện ra trong một lần bắt gói.

3. Chứng minh truy vấn tới được Pi-hole

Một truy vấn từ Pi không chứng minh gì về đường đi của mạng. Chạy nó từ máy khách và đọc mã phản hồi:

dig @192.168.1.53 example.com
dig @192.168.1.53 doubleclick.net

Hết thời gian chỉ ra việc lọc hoặc một tuyến đường; REFUSED chỉ ra một quy tắc truy cập; SERVFAIL chỉ ra trình phân giải thượng nguồn phía sau Pi-hole; một câu trả lời đúng không bao giờ xuất hiện trong nhật ký truy vấn nghĩa là máy khách đã hỏi điều khác. Kiểm tra UDP và TCP 53, vì các câu trả lời lớn và một số trình phân giải rơi về TCP, và công bố cả hai khi Pi-hole chạy trong một container. Một ánh xạ chỉ bao phủ UDP tạo ra những lỗi ngắt quãng trông như mất gói.

Sau đó chế độ lắng nghe của Pi-hole quyết định liệu nó có trả lời hay không. Ở chế độ chỉ cục bộ, dnsmasq bỏ qua các truy vấn từ những nguồn không nằm trên một mạng con được kết nối trực tiếp, và đó chính xác là dáng vẻ của một máy khách đứng sau một bộ định tuyến khác hoặc đến qua đường hầm: máy khách hết thời gian và truy vấn không bao giờ tới nhật ký. Một truy vấn vẫn xuất hiện dưới dạng REFUSED đã bị từ chối bởi danh sách truy cập hoặc một quy tắc tường lửa. Cho phép mọi nguồn gốc là cách sửa thông thường, đi kèm một quy tắc tường lửa giới hạn cổng 53 cho các mạng con của chính bạn.

4. Kiểm tra xem đường hầm đã thay thế hay nuốt mất câu trả lời

Đây là trường hợp cả hai triệu chứng ẩn náu. Khi bộ định tuyến tự nó là một máy khách VPN, một tùy chọn DNS được đẩy có thể ghi đè thiết đặt LAN ngay khi đường hầm dựng lên: các máy chủ OpenVPN đẩy dhcp-option DNS, và các hồ sơ WireGuard mang mục DNS riêng. Đọc trình phân giải hiệu lực của bộ định tuyến khi đường hầm đang hoạt động, không phải trước đó, và bỏ qua những gì trang LAN khẳng định.

Lỗi khác là khả năng tới được chứ không phải thay thế. Nếu các tiền tố được phép của đường hầm bao gồm mạng con LAN của bạn, bộ định tuyến có một tuyến đường gửi các truy vấn cho 192.168.1.53 vào đường hầm, và phía bên kia không có tuyến quay lại: các truy vấn hết thời gian dù đường hầm vẫn khỏe. Điều ngược lại xảy ra khi Pi-hole nằm trên một mạng con mà đường hầm không mang theo. So sánh địa chỉ với các tiền tố được phép của đường hầm và bảng tuyến đường của bộ định tuyến trước khi chạm vào DNS lần nữa.

Chọn một cách sửa, không phải cả hai. Hoặc giữ đường hầm xa DNS — với pull-filter ignore “dhcp-option DNS” trên OpenVPN và không có tiền tố LAN trong AllowedIPs trên WireGuard —, hoặc chấp nhận trình phân giải được đẩy và từ bỏ việc lọc cục bộ cho các máy khách phía sau bộ định tuyến đó. Dù bạn chọn gì, hãy viết nó bên cạnh hồ sơ, vì người tiếp theo sửa nó sẽ nếu không vô tình đảo ngược quyết định.

5. Lặp lại bài kiểm tra sau khi kết nối lại

Truy vấn từ một máy khách, xác nhận máy khách đó xuất hiện trong nhật ký của Pi-hole, sau đó phân giải một miền lẽ ra phải bị chặn và kiểm tra rằng bạn nhận được câu trả lời chặn thay vì câu trả lời thật. Kết nối lại đường hầm và chạy hai truy vấn như cũ, vì một thiết đặt trình phân giải chỉ tồn tại tới lần kết nối tiếp theo là kết quả thông thường của một cách sửa áp dụng ở tầng sai.

Để lại một đường phân giải thứ cấp không phụ thuộc vào đường hầm, để sự cố Pi-hole thoái hóa thành duyệt web không lọc thay vì không duyệt được gì. Giữ các giá trị DHCP và trình phân giải trước đó cho tới khi bài kiểm tra qua hai lần; một thay đổi làm hỏng internet của cả nhà vào bữa tối khó gỡ lỗi hơn nhiều so với một thay đổi bạn có thể hoàn tác trong một phút.