VPN kết nối, trình duyệt mở một trang công cộng, và máy tính xách tay vẫn không thể đăng nhập vào miền. Kết luận thường thấy là DNS ổn vì tên phân giải được. Không ổn, và lý do là bài kiểm tra trên trình duyệt chỉ thực hiện một truy vấn trong chuỗi mà máy khách đã tham gia miền cần. Việc khám phá miền hỏi bản ghi dịch vụ trước, sau đó hỏi địa chỉ của các bộ điều khiển mà những bản ghi đó nêu tên, và cuối cùng hỏi tuyến đến các cổng mà những bộ điều khiển đó lắng nghe. Câu trả lời công cộng không đáp ứng bước nào trong số đó.

Lầm tưởng: tên phân giải được nên DNS đã xong

Một trang công cộng phân giải được chỉ nói rằng một trình phân giải nào đó đã trả lời một truy vấn A hoặc AAAA cho tên trong vùng công cộng. Active Directory dùng cùng giao thức cho một câu hỏi khác: dịch vụ của miền ở đâu và máy khách này nên dùng bộ điều khiển nào. Câu hỏi được biểu diễn bằng bản ghi SRV dưới vùng mang tên miền, và trình phân giải công cộng đệ quy không có lý do lưu giữ chúng.

Khi thiếu bản ghi, trình phân giải trả về câu trả lời phủ định, đó là câu trả lời DNS hợp lệ chứ không phải sự cố. Máy khách sau đó quay về thông tin bộ điều khiển trong bộ nhớ đệm nếu có, và chính vì thế một máy để bàn có thể trông ổn hàng giờ rồi hỏng sau khi khởi động lại hoặc đổi mật khẩu.

Máy khách miền thực sự hỏi gì, theo thứ tự

Với một miền như corp.example, truy vấn định vị chung là _ldap._tcp.dc._msdcs.corp.example. Các câu trả lời SRV nêu tên bộ điều khiển ứng viên và cổng của chúng, sau đó máy khách cần bản ghi địa chỉ cho những tên máy chủ đó trước khi mở kết nối. Việc khám phá nhận biết vị trí thêm truy vấn dưới tên miền con của vị trí, và các câu trả lời quyết định bộ điều khiển nào được ưu tiên, không phải bộ nào là bắt buộc.

nltest /dsgetdc:corp.example
Resolve-DnsName -Type SRV _ldap._tcp.dc._msdcs.corp.example

Hãy đi theo chuỗi theo thứ tự đó, từ mạng nơi sự cố xảy ra. Tên máy chủ phân giải thành địa chỉ không tới được là lỗi định tuyến, không phải lỗi DNS. Bộ điều khiển tới được nhưng thiếu bản ghi định vị là lỗi DNS, không phải lỗi định tuyến. Cả hai tạo ra phàn nàn người dùng giống nhau và cách sửa hoàn toàn khác nhau.

Vì sao trình phân giải công cộng trả lời mà đăng nhập vẫn hỏng

Nếu bộ điều hợp cấp cho máy khách một trình phân giải công cộng, tên công cộng hoạt động còn không gian tên nội bộ thì không. Thêm trình phân giải công cộng thứ hai không giúp gì, vì cả hai đều không giữ vùng. Danh sách quen thuộc “nội bộ trước, công cộng sau” cũng không hành xử như quy tắc cho từng miền: câu trả lời phủ định từ máy chủ đầu tiên là câu trả lời hợp lệ, và máy khách không thử lại máy chủ thứ hai chỉ vì câu trả lời rỗng.

Cả hai trình phân giải nội bộ, nếu bạn chạy hai, phải giữ không gian tên AD và tới được từ mạng hiện tại của máy khách. Đó chính là phần mà các thiết kế đường hầm chia tách làm hỏng: VPN có thể chở mạng con của đường hầm trong khi trình phân giải nội bộ nằm trên tiền tố mà đường hầm không định tuyến, nên truy vấn đi ra tới một trình phân giải không thể trả lời nó.

Windows cũng áp dụng chính sách phân giải tên có thể hướng không gian tên cụ thể tới máy chủ cụ thể, và địa chỉ DNS mà bộ điều hợp hiển thị không phải toàn bộ câu chuyện. Thay đổi danh sách bộ điều hợp mà không đổi chính sách đó có thể để cấu hình hiệu lực nguyên vẹn, và đó là lý do một bản sửa trông như đã áp dụng lại không có tác dụng.

Giữ DNS của đường hầm và các tuyến của nó khớp nhau

Một hồ sơ VPN đẩy trình phân giải nhưng không đẩy tiền tố chứa nó tạo ra trình phân giải mà máy khách không tới được; hồ sơ đẩy tiền tố mà không đẩy trình phân giải để máy khách hỏi trình phân giải cục bộ. Hãy coi cặp này là một mục cấu hình và kiểm tra cả hai sau mỗi lần đổi hồ sơ, vì việc đẩy bị sắp xếp lại hoặc chính sách đường hầm chia tách mới có thể tách chúng ra.

Cũng cần kiểm tra xem máy khách làm gì với thiết lập được đẩy xuống. Một số máy khách chỉ áp dụng máy chủ DNS cho giao diện đường hầm và để trình phân giải của bộ điều hợp vật lý nguyên chỗ, nên bên nào thắng phụ thuộc vào số đo giao diện và tên được hỏi. Nếu câu trả lời nội bộ chỉ đến khi bộ điều hợp vật lý bị tắt, đó mới là cơ chế cần sửa, không phải các bản ghi của miền.

Chấp nhận bằng một lệnh gọi khám phá và một thao tác thực

Một bài kiểm tra chấp nhận hữu ích chạy truy vấn định vị rồi thực hiện một thao tác đã xác thực thật, như mở một chia sẻ dựa trên thư mục hoặc yêu cầu một phiếu. Hãy làm trước khi chuyển VPN và làm lại sau, trên cùng máy, không khởi động lại ở giữa. Thông tin đăng nhập trong bộ nhớ đệm và phiên đã mở sẽ vui lòng làm một con đường hỏng trông khỏe mạnh, nên đăng nhập thành công vào màn hình làm việc không phải là bài kiểm tra.

Khuyến nghị của Microsoft cho máy khách DNS vạch cùng ranh giới giữa việc phân giải không gian tên nội bộ và việc chuyển tiếp truy vấn công cộng lên trên, và đó là cách bố trí cần giữ khi đưa VPN vào.

Nếu hỏng chỉ là chậm chứ không thất bại, hãy tách độ trễ khỏi chẩn đoán. Hết thời gian trong lúc khám phá có thể đến từ bộ điều khiển không tới được, cổng bị chặn hoặc trình phân giải trả lời muộn, và không điều nào trong số đó được chứng minh chỉ bằng việc chờ. Hãy ghi lại truy vấn thực tế, câu trả lời và nỗ lực kết nối trước khi đổi thiết lập trình phân giải.

Bài viết liên quan