Vì sao tên DNS riêng tư thất bại trên máy khách VPN và nơi cần kiểm tra

Bạn mở laptop trong phòng khách sạn, khởi động máy khách, gõ tên máy chủ tệp nội bộ và không nhận được gì. Đường hầm báo đã kết nối, và ping tới một địa chỉ trong cùng mạng con vẫn trả lời, nên bản thân đường truyền vẫn ổn. Chỉ có tên là thất bại, và khoảng trống đó thu hẹp vấn đề vào hai chỗ: máy khách đã hỏi trình phân giải nào và câu trả lời nhận được có thể quay lại qua đường hầm hay không. Sửa đúng một chỗ và bỏ qua chỗ kia, thì lỗi chỉ chuyển chỗ.

Trước khi sửa bất kỳ hồ sơ nào, hãy xác nhận máy khách làm gì với tên đó. Trên Linux, resolvectl query files.corp.example cho thấy liên kết và trình phân giải nào đã tạo ra câu trả lời. Trên Windows, Resolve-DnsName files.corp.example cho thấy máy chủ đã trả lời và địa chỉ mà nó trả về.

Đọc câu trả lời trước khi bạn thay đổi bất cứ điều gì

Nếu tên trả về NXDOMAIN trong vài mili giây, truy vấn chưa bao giờ tới vùng của bạn và một trình phân giải công cộng hoặc của khách sạn đã trả lời thay. Nếu nó trả về sau một khoảng dừng dài, có gì đó đang bỏ gói ở cổng UDP 53 trên đường đi và máy khách cuối cùng đã chuyển sang phương án dự phòng. Nếu nó trả lời bằng địa chỉ đúng nhưng kết nối vẫn khựng lại, việc tra cứu vẫn ổn và vấn đề của bạn nằm ở định tuyến hoặc ở chính dịch vụ.

Cách chia ba đó tiết kiệm một giờ đoán mò. Nó cũng cho bạn biết có cần chạm vào VPN hay không: một tên phân giải thành địa chỉ riêng tư đúng đã chứng minh đường đi của trình phân giải, nên phần việc còn lại nằm trên đường dữ liệu.

Cấp trình phân giải từ bên trong đường hầm

Máy khách chia thành hai nhóm. Một nhóm có thể được máy chủ gán trình phân giải trong lúc thiết lập kết nối; nhóm kia giữ thiết lập trong một tệp cục bộ mà không cổng nào có thể thay đổi từ xa.

OpenVPN thuộc nhóm thứ nhất. Trên máy chủ, push "dhcp-option DNS 10.8.0.53" và push "dhcp-option DOMAIN corp.example" đi xuống kênh điều khiển, nhưng chỉ khi cấu hình máy khách vẫn bật pull. Một máy khách bị sửa tay mang pull-filter ignore "dhcp-option" sẽ không bao giờ thấy chúng, và riêng dòng đó giải thích vô số trường hợp «máy chủ đẩy nó xuống nhưng laptop của tôi không đồng ý».

WireGuard thuộc nhóm thứ hai, vì giao thức hoàn toàn không có thương lượng tùy chọn. Trình phân giải và miền tìm kiếm nằm trong khối [Interface] của chính máy khách dưới dạng DNS = 10.8.0.53, corp.example. wg-quick áp dụng điều đó qua resolvconf hoặc systemd-resolved, và trên Windows máy khách chính thức cài các quy tắc NRPT chỉ tồn tại khi đường hầm đang lên: Get-DnsClientNrptPolicy liệt kê chúng, nhờ đó đây là cách nhanh để xem máy khách có bao giờ áp dụng tệp của bạn hay không.

IPsec/IKEv2 nằm ở giữa. Plugin attr của strongSwan có thể trả về một máy chủ DNS lấy từ nhóm, và máy khách Windows thường chấp nhận, nhưng một hồ sơ ghim máy chủ tên riêng của nó sẽ thắng mọi thứ cổng ngoại cung cấp. Trên máy khách Linux, bước thủ công tương đương là resolvectl dns wg0 10.8.0.53 rồi resolvectl domain wg0 '~corp.example'; cả hai biến mất cùng giao diện, đúng như bạn muốn với một thiết lập gắn với đường hầm.

Giới hạn hậu tố thay vì nuốt mọi truy vấn

Trỏ toàn bộ danh sách trình phân giải của máy khách vào máy chủ nội bộ của bạn thì dễ và thường sai. Khi đó mọi tên công cộng đều được phân giải qua lối ra của trung tâm dữ liệu, các CDN trả về địa chỉ xa, và một sự cố trình phân giải kéo theo cả việc duyệt web của người dùng.

Chỉ gửi hậu tố riêng tư vào trong. Trên systemd-resolved, một miền bắt đầu bằng ~ chỉ dùng để định tuyến, nên ~corp.example nghĩa là các truy vấn dưới hậu tố đó đi tới máy chủ của liên kết ấy trong khi mọi thứ khác vẫn dùng mạng vật lý. Windows làm điều tương tự bằng quy tắc NRPT giới hạn trong một không gian tên, và macOS bằng một tệp phân giải bổ sung dưới /etc/resolver/.

Tên multicast xứng đáng có câu trả lời riêng. Tên .local là link-local theo thiết kế (RFC 6762) và một giao diện tun điểm-điểm không mang nhóm multicast đó, nên thêm một trình phân giải công cộng sẽ không công bố chúng và hỏi một trình phân giải unicast nội bộ về chúng sẽ trả về NXDOMAIN. Một bộ phản xạ như avahi ở chế độ phản xạ có thể bắc cầu hai phân đoạn, nhưng đó là quyết định phía máy chủ mà không máy khách nào yêu cầu được. Nếu máy in hoặc NAS phải truy cập được bằng tên, hãy cấp cho nó một bản ghi A trong vùng của bạn.

Chứng minh rằng câu trả lời có thể quay lại

Một câu trả lời đúng trỏ tới địa chỉ không tới được trông giống hệt một vấn đề trình phân giải cho tới khi bạn kiểm tra tuyến. Hỏi nhân xem câu trả lời sẽ đi đâu: ip route get 10.20.5.20 nêu tên giao diện và, hữu ích hơn, địa chỉ nguồn mà nó sẽ dùng.

Để ý chính địa chỉ của trình phân giải. Một máy khách có DNS = 10.8.0.53 bên cạnh AllowedIPs = 10.20.0.0/16 gửi truy vấn của nó ra ngoài qua NIC vật lý, nơi chúng chết lặng lẽ, vì trình phân giải không nằm trong bất kỳ tiền tố nào mà đường hầm đòi hỏi. Sự không khớp đó là lỗi một nguyên nhân phổ biến nhất trong toàn bộ lĩnh vực này, và nó vô hình trừ khi bạn so sánh thiết lập DNS với các tiền tố được phép từng dòng một.

Các dải trùng nhau gây ra lỗi ngược lại. Câu trả lời đúng, tuyến tồn tại, và nó trỏ tới sai máy chủ, vì 192.168.0.0/24 ở nhà cụ thể hơn tuyến của đường hầm tới cùng dải đó. Đánh số lại một bên hoặc đẩy một tuyến hẹp hơn, rồi xác nhận tường lửa và đường trả về của máy chủ dịch vụ; ghi chú của strongSwan về chuyển tiếp bao gồm phía sysctl của đường đó.

Chứng thư số là một bước kiểm tra danh tính riêng mà người ta lại đổ lỗi cho DNS. Nếu trình duyệt báo sai lệch tên thay vì lỗi phân giải, việc tra cứu đã chạy được và SAN trên chứng thư mới là thứ cần sửa. Hãy thử HTTPS theo tên, không bao giờ theo IP trần.

Thử lại từ máy khách, không phải từ cổng ngoại

Hãy thử bên trong ứng dụng mà người dùng phàn nàn, vì tra cứu trên dòng lệnh không chứng minh trình duyệt đi cùng đường. DNS an toàn của Chrome và network.trr.mode của Firefox có thể bỏ qua hoàn toàn trình phân giải của hệ thống, và khi chúng làm vậy, một tên riêng tư hoặc thất bại hoặc rò rỉ tới trình phân giải công cộng. So sánh resolvectl query với một dig @10.8.0.53 files.corp.example chạy tay sẽ cho bạn biết điều nào trong hai đã xảy ra.

Sau đó ngắt và kết nối lại trước khi tuyên bố đã sửa. Các thiết lập đặt tay lên giao diện sẽ biến mất cùng giao diện, và một hồ sơ chỉ trông đúng nhờ một chỉnh sửa cục bộ còn sót lại sẽ hỏng ở lần khởi động sau.

Một danh sách kiểm tra ngắn cho máy tiếp theo: tên phân giải qua trình phân giải của đường hầm, hậu tố được giới hạn chứ không toàn cục, địa chỉ trình phân giải nằm trong các tiền tố được phép, máy chủ trong câu trả lời trả lời trên cổng dịch vụ, và chứng thư bao phủ tên người dùng đã gõ.