Cấp cho VPN gia đình bản ghi DNS riêng cho nas.home.arpa

Khi đường hầm đã lên, bước cuối thường là một cái tên hoạt động thay cho địa chỉ mà bạn dán vào dấu trang. Một bản ghi máy chủ của dnsmasq cùng địa chỉ resolver mà máy khách đến được làm điều đó với hai tệp và không cần multicast. Quyết định thực sự cần suy nghĩ thì hẹp hơn: máy khách gửi toàn bộ DNS qua resolver trong nhà, hay chỉ những tên dưới home.arpa? Mọi thứ bên dưới giả định một cấu hình WireGuard đã được phê duyệt với máy khách Linux và một resolver phòng thí nghiệm do quản trị viên gia đình đã vận hành.

Ba cách cấp resolver cho máy khách

Với một máy tính xách tay thỉnh thoảng tham gia đường hầm, split-DNS là mặc định tốt hơn: nó giữ các tên internet thông thường ở resolver mà máy đã tin cậy. Với một máy tồn tại để đến các dịch vụ trong nhà, đẩy resolver xuống đơn giản hơn và chi phí phạm vi không quan trọng.

Xuất bản bản ghi tại resolver sở hữu vùng

Tách vai trò trước khi viết cấu hình: địa chỉ máy khách VPN, resolver và dịch vụ là ba máy chủ khác nhau với ba nhiệm vụ khác nhau. Trong phòng thí nghiệm này chúng là 10.77.0.2 cho máy khách, 192.168.50.53 cho dnsmasq và 192.168.50.20 cho NAS, với đường hầm định tuyến LAN trong nhà.

listen-address=127.0.0.1,192.168.50.53
bind-interfaces
local=/home.arpa/
host-record=nas.home.arpa,192.168.50.20

Dòng host-record cung cấp địa chỉ và dòng local= giữ các câu hỏi home.arpa chưa biết bên trong resolver này thay vì chuyển tiếp lên trên. Trước tiên hãy đọc cấu hình hiện có và đối chiếu mọi thứ đã định nghĩa một máy chủ, một giao diện hoặc cùng miền cục bộ; chồng một mảnh lên một mảnh xung đột sẽ tạo ra resolver tải vui vẻ và trả lời sai. Sách hướng dẫn dnsmasq định nghĩa cả hai chỉ thị và các điều khiển lắng nghe.

Sau đó xác minh dịch vụ đang chạy, không phải tệp. Một bài kiểm tra cấu hình cùng khởi động lại là mức tối thiểu, và câu trả lời hiệu quả là thứ mà truy vấn trả về.

Định tuyến resolver, không chỉ trang web

AllowedIPs của WireGuard quyết định đích nào đi vào đường hầm. Nếu địa chỉ resolver nằm ngoài nó, truy vấn đi ra theo tuyến thông thường và không bao giờ đến dnsmasq, dù bản thân NAS có thể truy cập được. Hãy bao gồm địa chỉ của resolver, hoặc tiền tố LAN chứa nó, và kiểm tra chính sách chuyển tiếp của cổng ở phía bên kia.

Cho phép UDP và TCP trên cổng 53 từ dải đường hầm được ủy quyền, với đường quay lại địa chỉ đường hầm của máy khách. Đừng chuyển tiếp cổng 53 từ WAN để dễ kiểm thử hơn: một resolver đệ quy mở trên kết nối gia đình sẽ bị tìm thấy trong vài giờ. Gắn với một giao diện tự nó không phải là chính sách truy cập.

Kiểm tra câu trả lời trước ứng dụng

Hỏi resolver trực tiếp trước, rồi hệ thống, rồi ứng dụng. Mỗi bước cô lập một mắt xích trong chuỗi, và sự khác biệt giữa chúng chính là chẩn đoán.

dig @192.168.50.53 nas.home.arpa. A
dig +tcp @192.168.50.53 nas.home.arpa. A
getent ahostsv4 nas.home.arpa
curl -sS --max-time 5 http://nas.home.arpa/ -o /dev/null -w '%{http_code}\n'

Đáng chạy truy vấn TCP vì một câu trả lời UDP bị cắt buộc phải thử lại, và chính sách bỏ TCP 53 tạo ra những sự cố trông như gián đoạn. Bước getent cho thấy cấu hình resolver của máy thực sự làm gì, điều không phải lúc nào cũng là thứ bạn đã đẩy xuống.

Quyết định điều gì xảy ra khi đường hầm xuống

Nếu DNS chung của máy khách trỏ tới 192.168.50.53, mọi phân giải tên dừng hoạt động khi đường hầm không lên. Điều đó chấp nhận được trên một máy chỉ hữu ích khi có đường hầm, và không chấp nhận được trên máy tính xách tay cũng dùng Wi-Fi quán cà phê. Split-DNS tránh hoàn toàn câu hỏi này, vì chỉ các tra cứu home.arpa phụ thuộc vào resolver trong nhà.

Hãy nhớ tên đó là gì: home.arpa được dành riêng cho mạng dân cư và không duy nhất trên toàn cầu, nên một mạng khác có thể dùng cùng tên một cách hợp pháp. Đó là tiện ích cục bộ, không phải định danh đáng tin cậy. Giữ bản ghi cập nhật khi dịch vụ chuyển đi, và gỡ chính sách resolver khi phòng thí nghiệm ngừng hoạt động thay vì để lại một máy tính xách tay trỏ tới địa chỉ mà nó chỉ đến được qua một đường hầm không còn tồn tại.