Lỗi 868 với địa chỉ IP? Windows phân giải gì trước
Hộp thoại báo lỗi tra cứu trong khi hồ sơ trông như số. Hãy đọc trường thật của hồ sơ, rồi tách vấn đề tên khỏi lỗi kết nối lại cũ.
Hộp thoại báo rằng không thể phân giải tên máy chủ, còn trường hồ sơ bạn đang nhìn là một địa chỉ. Sự kết hợp đó không mâu thuẫn: ứng dụng khách đang phân giải thứ khác với giá trị mà bạn tưởng nó đọc. Hãy xác định nó thực sự gọi tới đâu trước khi kết luận DNS bị hỏng. Thứ tự các bước của chính ứng dụng khách cho bạn biết nên xem ở đâu.
Ứng dụng khách phân giải tên trước khi gọi
Kết nối VPN gốc của Windows đọc hồ sơ, phân giải địa chỉ máy chủ, khởi động đường hầm và chỉ sau đó mới xác thực. Lỗi 868 thuộc bước thứ hai. Vì các bước sau không bao giờ chạy, hộp thoại có thể trông như vấn đề thông tin đăng nhập khi bước tra cứu hỏng trước.
Thứ tự đó hữu ích vì thu hẹp lớp cần kiểm tra. Khi cùng một hồ sơ chạy được từ mạng này và hỏng từ mạng khác, khác biệt thường là phân giải tên chứ không phải loại đường hầm hay tài khoản. Hãy kiểm tra tra cứu tại nơi lỗi xảy ra, không phải nơi hồ sơ được tạo.
Tên nào, khi trường hiển thị địa chỉ
Đọc giá trị đã lưu thay vì tên hiển thị. Nhãn của một kết nối không phải địa chỉ máy chủ của nó, và hai mục có nhãn giống nhau sẽ khiến bạn đi theo mục sai:
Get-VpnConnection -Name "Work VPN" |
Select-Object Name, ServerAddress, TunnelTypeNếu hồ sơ được cấp cho mọi người dùng, hãy truy vấn cả phạm vi đó bằng -AllUserConnection. Sau đó phân giải chính xác giá trị mà lệnh đã in ra, từ mạng nơi lỗi xảy ra. Dùng cổng được nhà cung cấp ghi trong tài liệu, không dùng tên nội bộ của ứng dụng chỉ phân giải được sau khi đường hầm hoạt động. Truy vấn thứ hai đó hỏng vì lý do đã dự kiến và không cho bạn biết gì về việc gọi:
Resolve-DnsName vpn.example.comKhi giá trị đã lưu thực sự là số, hãy tìm chỗ thứ hai mà ứng dụng khách đọc tên. Cấu hình EAP có thể tham chiếu một máy chủ, hồ sơ nhập từ công cụ khác có thể mang giá trị riêng, và trình cài đặt trước đó có thể để lại một mục trùng. Trường trong hộp thoại không phải lúc nào cũng là đầu vào duy nhất.
Mẫu kết nối lại của Windows 7
Luồng thảo luận đằng sau lỗi này mô tả những máy đã kết nối một lần rồi hỏng ở lần thử sau với 868, mà không có gì thay đổi trong hồ sơ. Những người đóng góp báo cáo rằng khởi động lại dịch vụ Remote Access Connection Manager hoặc đăng xuất rồi đăng nhập lại đã tạm thời khôi phục kết nối. Đó là cách lách, không phải nguyên nhân gốc đã được chứng minh.
Coi mẫu đó là một giả thuyết riêng. Khởi động lại đặt lại trạng thái ứng dụng khách, nên thành công tạm thời sau đó không chứng minh bản ghi DNS sai:
| Observation | Points toward | What to do next |
|---|---|---|
| Fails from one network, works from another | Name resolution on that path | Resolve the stored name from both networks |
| Fails after a disconnect, works after service restart | Client state, not DNS | Record the sequence for the vendor |
| Fails only on a newly provisioned machine | Profile content or scope | Compare ServerAddress and TunnelType |
Đọc bảng như một tập hợp các quan sát phân biệt, không phải chẩn đoán. Hàng đầu là vấn đề tên, hàng thứ hai là trạng thái ứng dụng khách, hàng thứ ba là hồ sơ chưa bao giờ đúng. Mỗi hàng dẫn tới một người khác và một cách sửa khác.
Cần thu thập gì cho quản trị viên
Ghi lại tên hồ sơ, địa chỉ đã lưu, loại đường hầm, mạng mà ứng dụng khách đang dùng và liệu lỗi có xảy ra sau khi ngắt kết nối. Bản ghi đó tách lỗi tra cứu thật khỏi hành vi kết nối lại trong quá khứ mà không cần ai phải đoán. Cũng giữ nhật ký sự kiện của ứng dụng khách quanh lần thử.
Cách lách từ các bản dựng cũ là bằng chứng hành vi đó từng tồn tại, không phải lời hứa rằng việc khởi động lại dịch vụ sẽ sửa một máy hiện tại. Thay tên máy chủ đã ghi trong tài liệu bằng địa chỉ nguyên văn cũng không phải sửa chữa.
Một số hồ sơ mong đợi danh tính máy chủ khớp với tên đã cấu hình, nên cách lách bằng số có thể đổi lỗi này lấy lỗi khác. Nếu tên phải giữ, hãy sửa đường phân giải chứ không phải văn bản hồ sơ. Dù thế nào, hãy ghi lại bạn đã đổi gì và vì sao.