VPN có thay đổi DNS của tôi không? So sánh trước và sau
Một hồ sơ có thể chủ động di chuyển các truy vấn của bạn. Hãy so sánh chính sách của bộ phân giải và câu trả lời thực tế trước và sau khi VPN kết nối, giữ cố định một biến số.
Bạn kết nối đường hầm, mở bảng điều khiển riêng và tên được phân giải thành một địa chỉ bạn chưa từng thấy. Hoặc điều ngược lại xảy ra: trình duyệt vẫn hoạt động trong khi một công cụ dòng lệnh đột nhiên không phân giải được gì. Cả hai kết quả đều đến từ cùng một thay đổi, và mọi người thường giải thích bằng một câu về VPN "dùng DNS riêng của nó", điều này không đủ chính xác để gỡ lỗi hay xác minh. Trong câu đó ẩn hai câu hỏi: hồ sơ này nên tiếp quản những truy vấn nào, và máy của bạn có thực sự gửi chúng đến bộ phân giải được cấp cho nó không? Tách chúng ra chính là toàn bộ phương pháp, vì một phép thử trộn lẫn chúng sẽ cho câu trả lời sai một cách tự tin theo cả hai hướng.
Vì sao một hồ sơ lại cung cấp bộ phân giải
Bên trong một đường hầm, các tên phía sau đầu xa thường phân giải thành những địa chỉ chỉ tồn tại trong mạng đó. Một vùng riêng tư như corp.internal không có ủy quyền công khai, nên bộ phân giải phục vụ nó phải truy cập được từ bên trong đường hầm. Cùng một cơ chế phục vụ mục đích thứ hai: khi các truy vấn nếu không sẽ đi ra ngoài qua nhà cung cấp của bạn, một bộ phân giải ở phía xa giữ truy vấn trong đường đi được mã hóa. Đó là lý do địa chỉ máy chủ DNS đến như một phần chính sách của kết nối chứ không phải một thiết lập toàn cục bạn chọn một lần cho máy.
Chỉ bản thân địa chỉ thì không quyết định gì. Một bộ phân giải chỉ có thể trả lời nếu có đường đi đến nó, và lỗi phổ biến nhất là bộ phân giải chỉ truy cập được khi đường hầm đang hoạt động. Khi đường hầm sập và chính sách còn lại, các truy vấn đi đến một địa chỉ không có đường, và triệu chứng là hết thời gian chứ không phải lỗi rõ ràng. Sự khác biệt đó quan trọng khi bạn đọc kết quả thử tiếp theo, vì hết thời gian đẩy người ta vào những thiết lập truyền tải chưa từng liên quan.
So sánh hai thiết kế trước khi so sánh câu trả lời
Đường hầm đầy đủ và DNS chia tách tạo ra những kỳ vọng trái ngược, và không cái nào là sự cố. Dưới đường hầm đầy đủ, mọi truy vấn có thể chuyển sang nhà cung cấp hoặc sang bộ phân giải doanh nghiệp, nên việc tên công khai trả lời khác đi sau khi kết nối là điều dự kiến. Dưới DNS chia tách, chỉ các miền được liệt kê mới đi đến bộ phân giải riêng trong khi mọi thứ khác vẫn ở cục bộ; trên Windows danh sách miền nằm trong Name Resolution Policy Table, trên macOS trong các miền khớp của thiết lập DNS, và trên máy chủ systemd-resolved trong các miền định tuyến theo từng liên kết.
Đó là phép so sánh cần làm trước tiên, vì nó quyết định điều gì được coi là lỗi. Với DNS chia tách, một tên công khai trả lời từ bộ phân giải mới là thứ đáng điều tra, trong khi một tên nội bộ trả lời đúng là hệ thống đang làm việc của nó. Với đường hầm đầy đủ, điều bất thường là một tên công khai vẫn trả lời từ bộ phân giải của nhà cung cấp bạn. Tài liệu của Microsoft về phân giải tên VPN mô tả thứ tự trên Windows của các quy tắc này, bao gồm cách một mục chính sách khớp được xem xét trước các máy chủ riêng của bộ điều hợp.
Có một bộ phân giải thứ ba trong phòng dễ bị quên. DNS bảo mật của trình duyệt tự phân giải tên và có thể tiếp tục trả lời sau khi đường hầm đã thay đổi chính sách của hệ điều hành, nên một trang tải được chứng minh bộ phân giải của trình duyệt đã hoạt động, chứ không phải hồ sơ đã được áp dụng. Nếu bạn chỉ so sánh những gì trình duyệt hiển thị, nửa thời gian bạn đang thử sai tầng.
Ghi lại đường cơ sở chỉ với một biến số
Thay đổi đường hầm. Đừng đổi luôn tên, công cụ hay hậu tố tìm kiếm trong cùng một bước. Chọn một tên mà bạn được phép truy vấn, ghi lại ứng dụng bạn đã dùng, và viết ra hoặc địa chỉ trả về hoặc lỗi chính xác. Trên Windows, Get-DnsClientServerAddress -AddressFamily IPv4 in các máy chủ theo từng bộ điều hợp và Get-DnsClientNrptPolicy in các mục chính sách; trên Linux với systemd-resolved, resolvectl status hiển thị máy chủ DNS và miền định tuyến theo từng liên kết; trên macOS, scutil --dns in thứ tự bộ phân giải mà hệ thống thực sự sẽ theo.
Sau đó kết nối qua các điều khiển thông thường của ứng dụng khách và lặp lại đúng những lệnh đó. Hãy lưu đầu ra đầu tiên thay vì ghi nhớ nó, vì phép so sánh là toàn bộ vấn đề và lần đọc thứ hai sau khi xóa bộ nhớ đệm đã là một phép đo khác. Nếu đường cơ sở được lấy khi trình duyệt ở phía trước và lần chạy sau khi kết nối diễn ra trong terminal, bạn đang so sánh hai bộ phân giải, không phải hai trạng thái của một bộ phân giải.
Truy vấn rõ ràng và tìm kiếm của ứng dụng là hai phép thử khác nhau
Hỏi một máy chủ cụ thể, bằng nslookup name 10.20.0.1 hoặc dig @10.20.0.1 name, chứng minh một điều: máy chủ bạn nêu tên trả lời khi bạn đến được nó. Nó bỏ qua hoàn toàn logic chọn lựa, nên không thể cho biết hệ thống có chọn máy chủ đó cho tên này hay không. Hãy dùng nó để kiểm tra bộ phân giải được gán có truy cập được không, và đừng dùng nó để kiểm tra chính sách.
Tìm kiếm qua bộ phân giải cục bộ thực sự dùng đến việc chọn lựa. resolvectl query name đi qua cùng các quy tắc miền định tuyến và báo cáo giao thức nào đã trả lời, Resolve-DnsName trên Windows đi qua bảng chính sách và bộ nhớ đệm của ứng dụng khách, và scutil --dns hiển thị thứ tự mà một tìm kiếm sẽ theo. Chạy cả hai loại và giữ chúng trong các cột riêng của ghi chú. Một truy vấn rõ ràng thành công bên cạnh một tìm kiếm ứng dụng thất bại là vấn đề định tuyến hoặc chọn lựa, không phải bộ phân giải từ chối hoạt động.
Bộ nhớ đệm đứng giữa bạn và câu trả lời. Hệ điều hành, bộ phân giải stub cục bộ, trình duyệt và bộ nhớ đệm âm đều giữ kết quả, nên một tìm kiếm có thể thành công mà không một gói tin nào rời khỏi máy. Ghi lại kết quả trước khi xóa bất cứ thứ gì: ipconfig /flushdns, resolvectl flush-caches hoặc sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder trên macOS. Bỏ qua việc đặt lại mạng rộng ở giai đoạn này, vì nó phá hủy bằng chứng bạn vẫn đang thu thập.
Sự khác biệt có nghĩa là gì
So sánh hai dòng đã ghi và phân loại thay đổi trước khi chạm vào một thiết lập duy nhất.
| Observation after connect | Most likely cause | Next step |
|---|---|---|
| Answer moves to a private address range | Expected under split DNS or a private zone | Confirm the suffix is in the effective policy, then test the service |
| Lookup times out while connected, works after disconnect | The assigned resolver has no route from this machine | Probe it with an explicit query, then re-read the policy |
| Internal name fails, public names work | Wrong namespace or a suffix missing from the policy | Query the fully qualified name and check the domain list per platform |
| Internal name returns a public address | Split DNS not applied; a public resolver answered | Check browser secure DNS first, then the per-link domain list |
Một dòng đáng được nhấn mạnh. Một tên phân giải được không phải là một dịch vụ hoạt động, và thành công của DNS chỉ nói rằng đã tìm thấy một địa chỉ. Nó không nói gì về chuyển tiếp, quy tắc tường lửa hay việc tài khoản của bạn có được dùng dịch vụ hay không, nên hãy kết thúc bằng việc thử ứng dụng thực tế thay vì giả định rằng lỗi đã tự rút đi.
Khôi phục đường cơ sở và xác minh
Ngắt kết nối qua chính các điều khiển của ứng dụng khách thay vì giết tiến trình, rồi đọc lại đúng ba lệnh đó. Các máy chủ theo liên kết, các mục chính sách và câu trả lời cho tên thử của bạn phải trở về đường cơ sở bạn đã ghi trước đó. Một mục chính sách còn lại sau khi ngắt kết nối sạch là một khiếm khuyết thực sự đáng ghi lại, và đó cũng là lý do việc sửa tay một tệp bộ phân giải được tạo ra là thói quen xấu: tệp bị ghi lại và phần sửa biến mất, hoặc phần sửa tồn tại và ghim một bộ phân giải không còn đường đi.
Đi qua danh sách này một lần, theo thứ tự. Quyết định hồ sơ triển khai thiết kế nào trước khi đánh giá bất kỳ kết quả nào. Giữ tên, công cụ và hậu tố cố định trong cả hai lần chạy. Tách truy vấn rõ ràng khỏi tìm kiếm ứng dụng. Đọc chính sách hiệu lực, không chỉ câu trả lời. Xóa bộ nhớ đệm sau cùng, sau khi phép so sánh đã được ghi. Xác minh với ứng dụng thực, rồi khởi động lại một lần và xác nhận trạng thái ngắt kết nối vẫn sạch.