Một người dùng không thể đăng nhập VPN: chẩn đoán theo thứ tự
Thực hiện các kiểm tra theo thứ tự: giai đoạn hỏng chính xác, sự kiện danh tính, một lần hoán đổi được phép, rồi đến chính sách. Dừng ở bước đầu tiên không đứng vững.
Khi một người không kết nối được trong khi phần còn lại của nhóm vẫn làm việc, câu hỏi hữu ích không phải là cái gì hỏng, mà là lớp nào đã không đồng ý. Đăng nhập là một chuỗi: ứng dụng khách khởi động, cổng vào trả lời, một danh tính được khẳng định, yếu tố thứ hai được thỏa mãn, chính sách được đánh giá, và chỉ khi đó lưu lượng mới chảy. Bất kỳ đứt gãy nào trong chuỗi đó đều đến với bạn như cùng một câu từ người dùng, vì vậy công việc đầu tiên là tìm ra mắt xích thực sự đã hỏng.
Hãy coi báo cáo là điểm khởi đầu chứ không phải chẩn đoán. Các kiểm tra bên dưới đi từ rẻ nhất trước, và mỗi kiểm tra được viết để kết thúc cuộc điều tra khi nó thất bại.
Xác định giai đoạn và dấu thời gian
Ghi lại bốn điều trước khi chạm vào bất kỳ cấu hình nào: ứng dụng khách và phiên bản của nó, câu chữ chính xác trên màn hình, phút của lần thử, và mạng mà người đó đang ở. Câu chữ mang thông tin thật, vì thông tin đăng nhập bị từ chối, một cổng vào không trả lời và một lần đăng nhập đã hoàn tất nhưng vẫn không mở được trang nội bộ là ba vấn đề khác nhau với ba người phụ trách khác nhau. Để ý xem ứng dụng khách có tạo ra dòng nhật ký cục bộ hay không, vì một ứng dụng khách chưa từng gửi gói nào thì không có gì để thêm vào một cuộc tìm kiếm phía máy chủ. Khi dấu thời gian đã được ghi lại, mọi truy vấn sau đó trở thành một cuộc tra cứu chứ không phải một cuộc săn lùng.
Dừng việc đoán mật khẩu tại điểm này. Nơi tài khoản có giới hạn số lần thử lại, một loạt lần thử nhanh có thể khóa nó và thêm một lỗi thứ hai, nhân tạo lên trên lỗi thật. Ghi lại số lần đã thử, để việc khóa tài khoản sau này không bị nhầm là triệu chứng mới. Một tài khoản bị khóa cũng lấy đi khả năng phân biệt mật khẩu sai với chính sách bị từ chối, vì cả hai đều đến như một lời từ chối.
Đọc sự kiện danh tính cho lần thử duy nhất đó
Yêu cầu quản trị viên lấy bản ghi xác thực khớp với phút bạn đã ghi. Trong một triển khai Windows NPS, hướng dẫn khắc phục sự cố NPS của Microsoft ghi lại sự kiện từ chối 6273 cùng với mã lý do đi kèm, và điều đó thường tách một người dùng không xác định, thông tin đăng nhập kém, sự không khớp chính sách và một cuộc gọi bị rơi vì lý do không liên quan.
Một kết quả trống cũng là thông tin. Nếu không có gì đến được dịch vụ danh tính, lần thử đã chết sớm hơn: một địa chỉ cổng vào cũ trong hồ sơ, một bộ lắng nghe mà ứng dụng khách không tới được, hoặc một máy chủ bị ngừng sử dụng trong khi hồ sơ vẫn còn sống. Nếu bản ghi tồn tại và báo cáo thành công, thông tin đăng nhập không phải vấn đề và cuộc tranh luận chuyển sang phân quyền hoặc sang định tuyến phía sau cổng vào. Hai kết quả này chỉ về hai hướng ngược nhau, vì vậy việc tìm kiếm nhật ký phải diễn ra trước khi ai đó cài lại ứng dụng khách.
Giữ mã lý do trong phiếu. Chỉ một trường đó biến lần xuất hiện tiếp theo thành một cuộc tra cứu năm phút thay vì một cuộc điều tra lặp lại. Ghép nó với phiên bản ứng dụng khách, vì một mã xuất hiện trên một bản dựng là cuộc trò chuyện khác với một mã xuất hiện trên mọi bản dựng.
Thay đổi một điều kiện mỗi lần, trong khuôn khổ chính sách
Cám dỗ là cài lại ứng dụng khách, đặt lại mật khẩu và chuyển máy tính xách tay sang mạng khác trong một lượt. Điều đó đôi khi sửa được triệu chứng và luôn phá hủy bằng chứng. Hãy chọn thay vào đó một lần hoán đổi được phép: cùng một người trên thiết bị đã đăng ký thứ hai, hoặc một danh tính thử nghiệm đã được phê duyệt trên cùng thiết bị đó. Mỗi lần hoán đổi trả lời đúng một câu hỏi, vì vậy một thành công thu hẹp lỗi về phía bạn đã thay đổi thay vì đổ lỗi cho toàn bộ VPN.
Đừng mượn thông tin đăng nhập của đồng nghiệp cho phép so sánh này. Hãy dùng một danh tính thử nghiệm thông qua quy trình được hỗ trợ, và đừng bao giờ sao chép khóa thiết bị hay bỏ qua đăng ký vì như vậy sẽ nhanh hơn. Nơi chính sách cấm hoàn toàn việc hoán đổi, hạn chế đó là một phần của hệ thống đang được kiểm tra và thuộc về bản ghi, không phải một cách lách.
Xác nhận sửa chữa trên đường đi ban đầu
Khi mắt xích hỏng được xác định, chỉ sửa mắt xích đó và lặp lại lần thử ban đầu: cùng một người, cùng thiết bị, cùng mạng, cùng ứng dụng. Một tài khoản thử nghiệm kết nối từ VLAN quản trị chứng minh cổng vào còn sống, và nó không chứng minh gì về buổi sáng thứ Ba của người dùng. Yêu cầu người dùng thực hiện chính hành động đã thất bại chứ không phải một hành động đơn giản hơn, vì một ping thành công nói rất ít về một chia sẻ tệp bị từ chối.
Đóng phiếu với những gì đã bị loại trừ và những gì đã thay đổi. Ghi chú đó là sự khác biệt giữa một lần cứu vài phút và một thứ mà kỹ sư trực tiếp theo có thể dùng lại.