Bạn gõfilesvào một trình giả lập terminal và không có gì trả về; bạn gõfiles.corp.examplevà cùng máy chủ đó trả lời ngay lập tức. Thông tin đăng nhập VPN không thay đổi gì, và máy chủ DNS riêng chưa bao giờ hỏng. Trên Android, nhãn ngắn và tên đầy đủ đi theo những con đường khác nhau qua trình phân giải, và một trong những con đường đó phụ thuộc vào một cài đặt mà chủ sở hữu đường hầm phải cung cấp. Quyết định trước mặt bạn không phải là đổi máy chủ DNS nào, mà là ai kiểm soát mạng mà ứng dụng thực sự dùng.

Miền tìm kiếm không phải là địa chỉ. Đó là danh sách các hậu tố mà trình phân giải gắn vào một nhãn trần trước khi bỏ cuộc.

Hậu tố tìm kiếm và máy chủ DNS là hai trường riêng biệt

Địa chỉ trình phân giải cho Android biết nơi cần hỏi. Hậu tố tìm kiếm cho biết cần hỏi gì khi bạn chỉ cung cấp nhãn ngoài cùng bên trái. Cả hai sống trên cùng một đối tượng mạng, và mỗi cái có thể thiếu một mình.

Chính sự độc lập đó giải thích vì sao tên máy chủ đầy đủ hoạt động. Một tên được định danh đầy đủ không cần hậu tố, vì nó đã là chuỗi đi đến máy chủ.

Android phơi bày sự tách biệt này quaLinkProperties. Danh sách máy chủ DNS và danh sách tìm kiếm miền nằm trên cùng một đối tượng, và danh sách thứ hai thường trống ngay cả khi danh sách thứ nhất đầy. Một mạng có trình phân giải nhưng không có miền là mạng mà hậu tố chưa bao giờ được áp dụng — không phải máy chủ đã từ chối tên ngắn.

Đọc mạng hiệu lực trước khi thay đổi bất cứ điều gì

Wi-Fi, mạng di động và giao diện VPN là ba mạng riêng biệt, và đường hầm trở thành mặc định ngay khi nó lên. Vì vậy hậu tố từng hoạt động trên Wi-Fi văn phòng không tự động là hậu tố có hiệu lực khi đường hầm đang hoạt động. Hãy kiểm tra mạng mà ứng dụng thực sự được chọn, không phải mạng bạn cấu hình tuần trước.

Shell terminal trên thiết bị là nhân chứng kém ở đây, vìresolv.confcủa nó phản ánh một góc nhìn của trình phân giải chứ không phải của mọi ứng dụng.

Thanh địa chỉ của trình duyệt thêm một lớp nữa: một từ trần có thể bị coi là truy vấn tìm kiếm, hoặc được phân giải quachính sách DNS mã hóa của riêng trình duyệt, nên một trang tải trong Chrome không chứng minh được gì về tra cứu hệ thống. Hãy thử bằng thứ gì đó dùng trình phân giải của nền tảng và in ra những gì trả về. Sau đó chạy dạng ngắn và dạng đầy đủ trong cùng một phiên, trên cùng một mạng, và ghi lại cái nào cho ra câu trả lời.

Nếu bạn xây dựng ứng dụng VPN, hãy gắn hậu tố trong builder

Khi ứng dụng của bạn thiết lập giao diện quaVpnService,addSearchDomainthì đây là đầu vào được hỗ trợ cho việc này. Nó nhận một chuỗi miền nhưcorp.example, và đây không phải là cách thay thế để truyền địa chỉ máy chủ.

Lời gọi ràng buộc hậu tố vào mạng bạn đang xây, nên không có cài đặt toàn cục nào để lật lại sau đó. Nếu ứng dụng tháo giao diện và dựng lại khi kết nối lại, builder mới phải thêm hậu tố một lần nữa, nếu không mạng thay thế sẽ lên mà không có nó.

Đây là nơi nhiều bản nhập cấu hình desktop làm mất trường này. Trình xuất ghi miền vào mô hình riêng của nó, giao diện Android chỉ ánh xạ những tùy chọn nó biết, và giao diện tạo ra trông đúng ở mọi khía cạnh khác. Một cấu hình chạy trên laptop và thất bại trên điện thoại thường là lỗ hổng trong ánh xạ, không phải vấn đề giao thức.

Nếu bạn chỉ dùng VPN, đây không phải việc của bạn để đặt

Không có chỉnh sửa phía máy khách nào thêm hậu tố, và cũng không có thuộc tính toàn cục nào bạn có thể đổi để làm giả một cái. Giá trị do người sở hữu đường hầm cung cấp: trong cấu hình của máy khách được quản lý, trong ánh xạ theo nền tảng của nó, hoặc qua những gì máy chủ đẩy xuống. Hãy nói bạn đang ở nền tảng nào và tên nào thất bại, vì giao diện desktop và di động khác nhau đúng ở trường này.

Nhập lại một cấu hình desktop vẫn không chứng minh được gì về ánh xạ di động.

Ba điều kiện quyết định bạn đang gặp khiếm khuyết hay một giới hạn được mong đợi. Thứ nhất, tổ chức có coi nhãn ngắn là tên được hỗ trợ hay không, hay đó chỉ là tiện ích từng chạy trên Wi-Fi văn phòng? Thứ hai, tra cứu thất bại có đến từ trình duyệt, thứ có thể bỏ qua hoàn toàn trình phân giải hệ thống? Thứ ba, tên ngắn có phải tiếp cận được qua đường hầm, hay chỉ từ LAN? Nếu câu trả lời cuối là chỉ-LAN, thêm hậu tố sẽ tạo ra một tên được phân giải bên ngoài văn phòng và sau đó không được định tuyến.

Khi hậu tố đã có mà tên ngắn vẫn thất bại

Nếu danh sách tìm kiếm miền đã hiển thịcorp.example, đừng đổ lỗi cho hậu tố nữa. Hãy kiểm tra xem trình phân giải có trả về câu trả lời cho tên đã mở rộng hay không, vì hậu tố chỉ thay đổi câu hỏi bạn đặt ra. Nó không bao giờ làm máy chủ có thẩm quyền cho một vùng mà nó không lưu trữ.

Sau đó kiểm tra tuyến đường. Một địa chỉ được phân giải nhưng không được đường hầm chở sẽ thất bại lúc kết nối, trông giống hệt một tra cứu thất bại trong trình duyệt lặng lẽ bỏ cuộc.

Chứng chỉ đáng được nhắc riêng. Việc xác thực HTTPS dùng tên máy chủ bạn thực sự đã gõ, nên một tên ngắn mở rộng đúng vẫn trình bàyfilestrong bắt tay. Một chứng chỉ được cấp chofiles.corp.examplesẽ không hợp lệ cho nó, và lỗi đó là hành vi đúng chứ không phải triệu chứng của vấn đề DNS bạn khởi đầu.

Bước tiếp theo nên làm gì

Xác nhận sự tách biệt trước khi chạm vào bất cứ thứ gì: tên đầy đủ phân giải được, tên ngắn thì không, cùng ứng dụng, cùng phiên. Sau đó tìm mạng được chọn và đọc danh sách tìm kiếm miền của nó bên cạnh danh sách trình phân giải. Cái nào trong hai cái trống sẽ cho bạn biết ai phải hành động — bạn, nếu bạn sở hữu ứng dụng; nhà vận hành đường hầm, nếu không.

Cuối cùng, hãy ưu tiên tên máy chủ dịch vụ đầy đủ trong dấu trang và cấu hình máy khách ở bất cứ đâu tính di động quan trọng. Nó sống sót qua việc đổi mạng, nó không phụ thuộc vào ánh xạ mà giao diện di động có thể không triển khai, và nó khớp với tên mà một chứng chỉ đã được cấp.

Bài viết liên quan