Vì sao nslookup phân giải qua VPN nhưng trình duyệt thì không

nslookup gửi truy vấn đến máy chủ bạn chỉ định và in ra câu trả lời, vì vậy nó có thể thành công trong khi mọi thẻ trình duyệt đều thất bại. Trình duyệt yêu cầu hệ điều hành phân giải, và hệ điều hành cân nhắc bộ phân giải của từng giao diện, quy tắc chính sách phân giải tên và vị trí mạng của bộ điều hợp. Sau đó trình duyệt có thể thêm DNS mã hóa của riêng nó lên trên. Ba đường đi khác nhau, một triệu chứng, và đường hầm thường không phải là phần bị hỏng.

Các kiểm tra dưới đây đi theo những đường đó từ hệ thống ra ngoài. Không sửa hồ sơ VPN cho đến khi bạn biết đường nào đã trả lời và đường nào đã thất bại.

Ba chính sách quyết định câu trả lời

Mỗi giao diện mang danh sách bộ phân giải và hậu tố tìm kiếm riêng. Bộ điều hợp VPN thêm máy chủ trong khi bộ điều hợp vật lý giữ của riêng nó, và hệ thống có thể lấy cái trả lời trước, nên một truy vấn có thể được phục vụ ngoài đường hầm mà không ai chọn điều đó. Các quy tắc của bảng chính sách phân giải tên có thể gửi những miền được chọn đến những máy chủ được chọn, đó là cách split DNS thường được biểu đạt trên Windows. Và ứng dụng khách hoặc cổng VPN có thể đẩy một địa chỉ bộ phân giải chỉ tồn tại bên trong mạng riêng.

Ba thứ đó tương tác theo những cách mà từ trình duyệt trông có vẻ tùy tiện. Một bộ phân giải được đẩy đến địa chỉ riêng mà không có tuyến qua đường hầm tách khiến mọi truy vấn bị treo rồi thất bại. Một quy tắc chính sách bao phủ hậu tố nội bộ và trỏ đến máy chủ đã tắt tạo ra đúng lỗi nhìn thấy được như thiếu tuyến. Một hậu tố tìm kiếm thiếu trên bộ điều hợp VPN biến một tên ngắn thành truy vấn công khai cho miền sai. Mỗi thứ cần một cách sửa khác nhau.

Vì sao trình duyệt hỏi một câu khác

nslookup phát truy vấn của riêng nó đến máy chủ mà nó chọn và không tuân theo chính sách không gian tên hay thiết lập DNS mã hóa của trình duyệt. Vì vậy một truy vấn thủ công đến bộ phân giải công cộng vẫn có câu trả lời trong khi trình duyệt báo rằng trang không tồn tại. Bạn đang so sánh hai chương trình, không phải hai trạng thái của một chương trình.

Ưu tiên họ địa chỉ giải thích sự chậm trễ chứ không phải thất bại. Trình duyệt hỏi bản ghi IPv6 trước trên một đường hầm chỉ mang IPv4 sẽ chờ hết thời gian chờ trước khi lùi lại. Firefox đã có một tùy chọn đúng cho việc này, và tắt nó là bước chẩn đoán, không phải sửa chữa.

Đọc danh sách bộ phân giải và các quy tắc

Trên Windows, hãy in ra những gì hệ thống đang giữ trước khi lý thuyết hóa. Get-DnsClientServerAddress hiển thị máy chủ theo từng giao diện, Get-DnsClientNrptRule liệt kê các quy tắc không gian tên, và Resolve-DnsName trả lời tên chính xác qua đường đi của hệ thống. So sánh câu trả lời đó với truy vấn trực tiếp đến máy chủ của VPN theo địa chỉ. Khi Resolve-DnsName thất bại và truy vấn trực tiếp thành công, nghi phạm là danh sách bộ phân giải hoặc một quy tắc không gian tên.

Kiểm tra cả bản thân tên. Một tên ngắn nội bộ có thể cần hậu tố riêng mà chỉ bộ điều hợp VPN cung cấp, trong khi tên đủ điều kiện phân giải tốt. Cảnh báo chứng chỉ sau một truy vấn thành công thuộc về một vấn đề khác.

Bộ phân giải được đẩy không thể tiếp cận

Cổng hoặc ứng dụng khách có thể đẩy một địa chỉ bộ phân giải, và địa chỉ đó phải tiếp cận được qua đường hầm. Trên đường hầm tách, dải riêng chứa bộ phân giải có thể không nằm trong các tuyến được bao gồm, tạo ra truy vấn không bao giờ nhận được câu trả lời. Xác nhận rằng tuyến tồn tại, rồi hỏi chính địa chỉ đó qua đường hầm. Đây là thất bại đằng sau lỗi miền trong trình duyệt trong khi bộ phân giải công cộng vẫn trả lời.

Nếu bộ phân giải không thể tiếp cận, cách sửa là một tuyến hoặc một mạng con được bao gồm, không phải máy chủ DNS khác.

DNS mã hóa đi vòng qua toàn bộ đường đi

Trình duyệt có DNS-over-HTTPS tự phân giải tên qua kết nối HTTPS đến nhà cung cấp được chọn. Khi bật, bộ phân giải hệ thống và các quy tắc split DNS bị bỏ qua hoàn toàn cho những truy vấn đó, nên tên nội bộ thất bại trong trình duyệt trong khi hệ điều hành phân giải chúng đúng. Điều ngược lại cũng xảy ra: tên nội bộ thành công trong trình duyệt qua một nhà cung cấp lẽ ra không bao giờ được thấy chúng, và đó là vấn đề chính sách, không phải kết nối.

Hãy quyết định có ý thức liệu DNS mã hóa có được phép trên thiết bị được quản lý hay không, rồi cấu hình nó qua bề mặt quản lý của trình duyệt để lựa chọn hiển thị. Để nó cho sở thích cá nhân tạo ra một đội máy trong đó cùng một VPN hành xử khác nhau trên mỗi máy tính xách tay.

Các cách sửa phù hợp với thất bại

Nếu VPN đẩy bộ phân giải của nó, hãy để đường hầm mang lưu lượng đến nó và để cùng thiết lập đó hiển thị trên các bộ điều hợp tham gia phân giải. Nếu các trang cục bộ ngừng phân giải khi đang kết nối, hãy thêm ngoại lệ không gian tên rõ ràng hoặc bộ chuyển tiếp có điều kiện thay vì thay toàn bộ bộ phân giải. Nếu DNS mã hóa của trình duyệt đi vòng qua chính sách, đó là thiết lập cần thay đổi. Không bao giờ thêm bộ phân giải công cộng để sửa một tên nội bộ: nó làm rò rỉ truy vấn riêng và không phân giải tên.

Sau đó tách phân giải khỏi kết nối. Một tên phân giải đúng địa chỉ nhưng từ chối kết nối là vấn đề dịch vụ, tường lửa hoặc chứng chỉ, và thay đổi DNS sẽ không sửa được.

Ghi lại đường nào đã trả lời, đường nào thất bại và bạn đã thay đổi gì. Báo cáo tiếp theo về cùng triệu chứng khi đó sẽ tốn một lệnh thay vì cả buổi chiều.