Điểm phát sóng Pi với Pi-hole và VPN: giao cho mỗi dịch vụ một việc
Hãy quyết định ai sở hữu DHCP, DNS và việc chuyển tiếp gói trước khi bật ba trình trợ giúp trên một Pi duy nhất. Chủ sở hữu trùng nhau tạo ra hợp đồng thuê cạnh tranh và vòng lặp resolver.
Một điện thoại kết nối vào điểm phát sóng của Pi, nhận được địa chỉ, nhưng trang vẫn không mở. Pi đang chạy trình trợ giúp điểm phát sóng, Pi-hole và một ứng dụng khách VPN, và mỗi thứ đều tin rằng mình sở hữu một phần đường đi. Phần lớn các cấu hình như vậy hỏng không phải vì một thành phần bị lỗi, mà vì hai thành phần làm cùng một việc. Hãy chỉ định một chủ sở hữu cho mỗi chức năng trước khi tinh chỉnh bất kỳ thứ nào.
Chỉ định một chủ sở hữu cho mỗi chức năng
Ở đây có bốn chức năng quan trọng, và mỗi chức năng cần đúng một chủ sở hữu. Bảng dưới đây nêu chức năng, chủ sở hữu khả thi và điều gì hỏng khi hai dịch vụ cùng đòi nó.
| Function | Workable owner | Duplicate-owner symptom |
|---|---|---|
| Client addresses | One DHCP server, such as the hotspot helper | Competing offers and changing leases |
| DNS reception | Pi-hole on port 53 | Bind failure or queries answered by the wrong process |
| Forwarding and NAT | One firewall manager | Double translation and broken return paths |
| VPN routing | One client configuration | Route flapping and traffic escaping outside the tunnel |
Sự chồng lấn thường đến từng gói một. Trình trợ giúp điểm phát sóng cài bản dnsmasq riêng, Pi-hole muốn cổng 53, và ứng dụng khách VPN thêm tuyến đường. Từng bước riêng lẻ có vẻ hợp lý, nhưng gộp lại thì tạo ra một cỗ máy mà dịch vụ khởi động sau lặng lẽ đổi hành vi của dịch vụ khởi động trước.
Hãy ghi các chủ sở hữu ra trước khi bật bất cứ thứ gì khác. Một bảng ngắn trong ghi chú dựng máy giúp lần cài đặt sau không chiếm mất chức năng đã có chủ.
Chọn một dải địa chỉ và giữ nó tránh xa đường hầm
Chọn dải của điểm phát sóng, địa chỉ của Pi trong dải đó, nhóm DHCP và resolver mà máy khách nhận được. Giữ dải đó tách khỏi LAN thượng nguồn và khỏi dải của đường hầm VPN, vì các mạng con chồng lấn biến một trục trặc định tuyến thành dự án dịch địa chỉ. Một dải chồng lấn với đường hầm khiến Pi thành bộ định tuyến ngoài ý muốn giữa hai tiền tố giống nhau. Hãy ghi dải và nhóm vào cấu hình điểm phát sóng thay vì để mặc định.
Nếu chế độ chia sẻ của NetworkManager sở hữu điểm phát sóng, hãy kiểm tra kết nối thực tế trước khi thêm máy chủ DHCP. Chế độ chia sẻ tự khởi động các trình trợ giúp và bật chuyển tiếp, nên nó đã là chủ sở hữu kế hoạch địa chỉ cho giao diện đó. Thêm máy chủ thứ hai chỉ vì nó có sẵn sẽ tạo ra các đề nghị cạnh tranh chứ không phải dự phòng.
Hãy quyết định về IPv6 một cách có chủ đích. Trong nhiều cấu hình, thông báo bộ định tuyến và DHCPv6 đến từ một trình trợ giúp khác với DHCPv4, và để IPv6 bật trong khi chính sách VPN chỉ phủ IPv4 sẽ cho máy khách một đường vòng qua đường hầm. Hãy quy hoạch phía IPv6 hoặc tắt nó trên giao diện điểm phát sóng kèm lý do bằng văn bản.
Ai thực sự trả lời trên cổng 53
Liệt kê mọi tiến trình đang lắng nghe cổng 53 trước khi đổi cấu hình. Trên một Pi chạy stub resolver cục bộ, Pi-hole và trình trợ giúp chia sẻ, danh sách người nghe là bản đồ đáng tin cậy duy nhất về ai trả lời truy vấn:
sudo ss -lunpt '( sport = :53 )'
ip -4 addr show
ip routeHướng dẫn giao diện của Pi-hole giải thích rằng chế độ nhận chỉ giới hạn ở một giao diện vẫn có thể dùng ổ cắm wildcard và loại bỏ những gói đến nơi khác. Điều đó không giống với việc chỉ gắn vào các giao diện được chọn, vốn là cách bố trí dự định khi một dịch vụ DNS khác phải dùng chung máy.
Hai tiến trình thường không thể gắn cùng địa chỉ và cổng, dù SO_REUSEPORT có thể làm cho việc gắn chung thành công; ngay cả khi đó, một trình nghe wildcard vẫn có thể nhận những gói dành cho dịch vụ hẹp hơn. Hãy chọn chế độ được ghi trong tài liệu cho vai trò mong muốn và khởi động lại các dịch vụ theo thứ tự dự kiến.
Giữ trang quản trị của Pi-hole ngoài mạng điểm phát sóng. Máy khách cần resolver, không cần giao diện web hay API có thể đổi cấu hình của resolver.
Hai chặng DNS, mỗi chặng một chính sách
Truy vấn của máy khách đi từ điện thoại tới Pi, và một truy vấn riêng đi từ Pi tới resolver thượng nguồn của nó. Một quy tắc định tuyến khớp với lưu lượng điểm phát sóng được chuyển tiếp không tự động áp dụng cho chặng thứ hai, vì Pi tạo ra lưu lượng đó tại chỗ. Nếu VPN phải mang DNS, đường đi cục bộ cần chính sách riêng.
Coi chừng vòng lặp. Trỏ thượng nguồn của Pi-hole vào một địa chỉ do chính Pi phục vụ, trực tiếp hay qua chuyển tiếp cổng, sẽ tạo ra các truy vấn quay vòng cho tới khi hết thời gian chờ. Hãy cho nó một thượng nguồn thật hoặc một forwarder có điều kiện cho các tên miền nó không trả lời được.
Hãy quyết định điều gì xảy ra khi đường hầm rớt. Quay về resolver cục bộ giữ cho việc duyệt web tiếp tục nhưng có thể làm rò rỉ tên ra ngoài VPN; chặn thì giữ nguyên chính sách và biến sự cố thành lỗi nhìn thấy được. Cả hai lựa chọn đều có lý, nhưng phải được chọn chứ không phải thừa hưởng từ mặc định.
Chứng minh đường đi và hành vi khi mất kết nối
Kiểm tra theo lớp: máy khách nhận địa chỉ, máy khách phân giải tên qua Pi, Pi phân giải qua thượng nguồn dự kiến, và một ứng dụng hoàn tất yêu cầu. Ping thành công không nói gì về DNS, và phân giải thành công không nói gì về chuyển tiếp.
dig @192.168.70.1 example.com
curl -sS -o /dev/null -w '%{http_code}\n' https://example.com/
ip -4 route get 1.1.1.1Sau đó dừng đường hầm và lặp lại. Hành vi dự kiến phải xuất hiện trong vài giây, chứ không phải sau khi khởi động lại Pi-hole hay dịch vụ điểm phát sóng bằng tay. Kiểm tra cài đặt resolver của máy khách trong lúc sự cố, vì resolver công cộng phụ vẫn tiếp tục trả lời ngay cả khi chính sách mong đợi thất bại.
Giữ một chủ sở hữu cho chuyển tiếp và NAT và xác minh từ máy khách, không phải từ chính Pi. Một yêu cầu rời Pi thành công vẫn có thể bị bỏ trên đường về, và máy khách là nơi duy nhất nhìn thấy toàn bộ đường đi.