Trỏ máy khách OpenVPN tới trình phân giải Pi-hole trên máy chủ khác

Đặt địa chỉ Pi-hole vào hồ sơ OpenVPN không tạo ra đường tới nó, không cấp quyền truy vấn nó và không bảo đảm máy khách sẽ dùng nó. Khi Pi-hole nằm trên một máy LAN riêng, bốn thứ phải khớp nhau: tuyến từ máy khách, chuyển tiếp từ cổng, đường về tới nhóm địa chỉ và chính sách tiếp nhận trên Pi-hole. Mỗi lỗi hiện ra khác nhau trong nhật ký. Xử lý theo đúng thứ tự đó nhanh hơn là sửa cái cuối trước. Lối tắt quen thuộc, mở đệ quy cho mọi nguồn, đổi một vấn đề nhỏ lấy một vấn đề vĩnh viễn.

Tùy chọn DNS được đẩy xuống làm gì và không làm gì

Máy chủ quảng bá một trình phân giải bằng chỉ thị dưới đây, giả định 192.168.50.53 là máy Pi-hole. Máy khách nhận tùy chọn và, tùy nền tảng và cách tích hợp trình phân giải , áp dụng nó cho giao diện đường hầm hoặc bỏ qua để dùng stub cục bộ. Dòng tuyến quan trọng ngang dòng DNS, vì một trình phân giải mà máy khách không tới được thì không phải trình phân giải. Không điều nào trong số này nhìn thấy được từ phía máy chủ.

server 10.90.0.0 255.255.255.0
push "dhcp-option DNS 192.168.50.53"
push "route 192.168.50.0 255.255.255.0"

Nhận tùy chọn không giống với dùng nó. Một máy khách Linux có trình quản lý phân giải có thể chấp nhận máy chủ được đẩy xuống và chỉ gửi một số miền tới đó; máy khách tự quản lý DNS có thể ghi đè hoàn toàn cài đặt. Các tuyến được đẩy xuống cũng bị hạn chế trên một số nền tảng, khiến trình phân giải không tới được dù tùy chọn đã được chấp nhận. Hãy kiểm tra trên máy khách xem máy chủ nào trả lời, chứ không phải trên máy chủ xem đã gửi gì.

Tùy chọn cũng không nói gì về phía máy chủ. Lưu lượng DNS vẫn phải đi từ máy khách tới cổng và từ cổng tới Pi-hole trước khi bất kỳ tùy chọn nào có ý nghĩa. Tuyến thiếu và truy vấn bị từ chối trông giống nhau từ phía máy khách, nên hãy xác nhận chuyển tiếp trên cổng trước.

Đường về từ Pi-hole tới nhóm địa chỉ

Nếu địa chỉ nguồn của máy khách được giữ nguyên, Pi-hole trả lời tới một địa chỉ bên trong nhóm VPN. Bảng tuyến của nó có lẽ không biết gì về nhóm này, nên trả lời đi tới cổng mặc định và biến mất. Nhật ký truy vấn hiện một yêu cầu không có trả lời khớp, điều dễ bị hiểu nhầm thành vấn đề tường lửa.

Cho router LAN một tuyến tĩnh tới nhóm với cổng OpenVPN là chặng kế tiếp, hoặc dịch địa chỉ nguồn trên cổng trước khi chuyển tiếp tới Pi-hole. Cách thứ nhất giữ địa chỉ của từng máy khách hiện rõ trong nhật ký truy vấn của Pi-hole. Cách thứ hai bỏ yêu cầu tuyến về nhưng làm mọi truy vấn trông như đến từ cổng. Cả hai đều không sai; chúng trả lời những câu hỏi khác nhau.

Nếu báo cáo hay chính sách theo từng máy khách quan trọng, tuyến tĩnh là lựa chọn đánh đổi tốt hơn. Nếu LAN do người khác quản lý và không có tuyến, dịch địa chỉ là lựa chọn thực dụng, kèm ghi chú mất danh tính máy khách. Ghi lại bạn chọn cách nào, vì mọi câu hỏi nhật ký về sau đều phụ thuộc vào nó.

Chế độ lắng nghe của Pi-hole cho máy khách được định tuyến

Danh sách thả xuống về hành vi lắng nghe giao diện trên trang cài đặt trong mục DNS quyết định Pi-hole trả lời những nguồn nào. Tùy chọn nghiêm nhất chỉ nhận máy khách trên mạng kết nối trực tiếp; tùy chọn cho phép thiết bị cách xa tối đa một chặng mở rộng điều đó tới các mạng con sau một router liền kề, và máy khách VPN được định tuyến trông đúng như vậy. Gói tin thực sự tới giao diện LAN, nhưng địa chỉ nguồn của nó thuộc một mạng con khác. Đây là sự từ chối theo chính sách chứ không phải lỗi định tuyến, và khác biệt này quan trọng khi đọc nhật ký.

Hướng dẫn lắng nghe của Pi-hole tách nguồn kết nối cục bộ khỏi nguồn gốc được định tuyến, và giao diện đến không phải tiêu chí. Chọn chế độ cho phép nhóm VPN mà không cho phép toàn bộ internet, rồi ghép với một quy tắc tường lửa chỉ nhận DNS từ nhóm đó.

Mở đệ quy cho mọi nguồn gốc để truy vấn đầu tiên chạy được là cách sửa sai. Nó biến một trình phân giải riêng tư thành công khai, và cách sửa đúng là cấp quyền có phạm vi chứ không phải toàn cục.

Khớp câu trả lời với nhật ký truy vấn

Hỏi máy khách, rồi kiểm tra máy chủ và so sánh hai bên. Trên máy khách systemd-resolved, các lệnh dưới đây cho biết trình phân giải nào tạo ra câu trả lời và máy chủ nào được cấu hình cho từng liên kết. Dùng một tên chỉ Pi-hole biết, vì truy vấn trực tiếp tới địa chỉ Pi-hole chứng minh khả năng tới được chứ không phải cấu hình.

resolvectl query intranet.example.lan
resolvectl dns

Câu trả lời mong đợi nêu 192.168.50.53 là máy chủ và trả về một địa chỉ mà chỉ trình phân giải đó biết. Sau đó xem góc nhìn của chính Pi-hole: pihole -t theo dõi nhật ký truy vấn trực tiếp, và mỗi dòng mang địa chỉ nguồn. Nếu nguồn là địa chỉ đường hầm của máy khách, tuyến của nhóm còn nguyên. Nếu là địa chỉ LAN của cổng, việc dịch nguồn đang diễn ra và địa chỉ của chính máy khách sẽ không bao giờ xuất hiện.

Nếu nhật ký không hiện gì cả, truy vấn chưa bao giờ tới Pi-hole và việc cần kiểm tra tiếp theo là chuyển tiếp trên cổng. Nếu truy vấn hiện ra mà không có trả lời quay về, vấn đề là đường về, tức phần trước. Chia lỗi theo cách này giúp một lỗi định tuyến không bị nhầm thành quy tắc tường lửa.

Kiểm tra quy tắc chuyển tiếp của cổng

Cổng phải chuyển tiếp gói DNS của máy khách về phía Pi-hole, và quy tắc làm việc đó đáng được đọc chứ không phải giả định. Các lệnh dưới đây liệt kê những quy tắc chạm cổng 53 kèm bộ đếm, trên máy nftables và trên máy iptables. Một quy tắc tồn tại nhưng hiện không khớp lần nào là dấu hiệu lưu lượng bị bỏ trước khi được dịch.

sudo nft list ruleset | grep -A3 'dport 53'
sudo iptables -t nat -L POSTROUTING -n -v | grep 53

Đọc bộ đếm, không chỉ đọc quy tắc. Một quy tắc không bao giờ khớp nghĩa là gói đi ra qua giao diện khác, hoặc máy khách chưa bao giờ gửi nó. Một quy tắc khớp ở mọi truy vấn nghĩa là chuyển tiếp hoạt động và vấn đề nằm xa hơn trên đường.

Dù máy chủ dùng công cụ nào, hãy giữ phạm vi kiểm tra hẹp: nhóm địa chỉ làm nguồn, cổng 53 làm đích và Pi-hole là mục tiêu duy nhất được phép. Một quy tắc chuyển tiếp rộng cho phép cả cổng 80 là một vấn đề khác đang chờ xảy ra.