FortiClient kẹt ở 98%: tắt IPv6 trên bộ điều hợp đó

Thanh chạy đến 98%, ứng dụng khách đứng yên ở đó, và gõ lại mật khẩu không thay đổi gì. Đó là manh mối hữu ích: ứng dụng khách đã chấp nhận chứng chỉ cổng, gửi thông tin đăng nhập và nhận cấu hình đường hầm. Phần còn lại là dựng bộ điều hợp ảo lên và xác nhận đường hầm truyền tải lưu lượng. Khi bước cuối cùng đó không bao giờ hoàn tất, lỗi nằm ở máy cục bộ, và gõ lại thông tin đăng nhập bao nhiêu lần cũng không chạm tới được.

Bốn bước, và bước đầu tiên là đọc nhật ký chứ không phải thanh chạy.

Bộ đếm 98% thực sự báo cáo điều gì

Phần trăm là bộ đếm giai đoạn của chính ứng dụng khách, không phải thước đo thông lượng. Kẹt ở cùng một con số trong mọi lần thử nghĩa là ứng dụng khách đạt tới một giai đoạn cụ thể và chờ; đó là lý do một kết nối chậm và một ứng dụng khách bị kẹt trông khác nhau trong nhật ký. Vấn đề thông tin đăng nhập sẽ in ra lỗi thông tin đăng nhập thay vì một khoảng dừng im lặng.

Fortinet đã ghi nhận triệu chứng này với một nguyên nhân phía ứng dụng khách: IPv6 được bật trên bộ điều hợp mà ứng dụng khách dùng. Điều đó khiến cài đặt bộ điều hợp thành thứ đầu tiên cần thử, không phải lời giải thích phổ quát cho mọi SSL-VPN lần kẹt.

Bước 1: đọc nhật ký trước thanh chạy

Trước khi thay đổi bất cứ điều gì, hãy chụp các dòng ngay trước lúc kẹt. Bạn đang tìm xem bộ điều hợp đường hầm có được tạo không, có địa chỉ nào được gán không, và ứng dụng khách có bỏ chờ một họ địa chỉ không. Kẹt ở một phần trăm khác là một giai đoạn khác với chẩn đoán riêng, và cảnh báo chứng chỉ hay địa chỉ cổng sai tạo ra thông báo riêng thay vì chờ im lặng. Ghi lại dấu thời gian, vì lần thử tiếp theo sẽ thêm một khối nữa vào cùng tệp đó.

Nếu nhật ký cho thấy đăng nhập hoàn tất rồi không có gì, bạn đang ở cấu hình cục bộ và bộ điều hợp là nghi phạm hợp lý.

Bước 2: giới hạn thay đổi IPv6 trong một bộ điều hợp

Thay đổi thuộc về bộ điều hợp, không phải máy. Trong thuộc tính bộ điều hợp của Windows, điều đó nghĩa là bỏ chọn Internet Protocol Version 6 (TCP/IPv6) trên giao diện cụ thể, và từ một shell thì đó là Disable-NetAdapterBinding -Name "Ethernet 2" -ComponentID ms_tcpip6. Xác nhận trạng thái bằng Get-NetAdapterBinding -ComponentID ms_tcpip6 trước khi kết nối lại. Sau đó kết nối lại và xem thanh chạy có vượt qua 98% thay vì dừng ở đó không.

Trước hết hãy giới hạn phạm vi, rồi mới thử. Tắt IPv6 trên toàn cục là thay đổi lớn hơn câu hỏi đòi hỏi và nó ảnh hưởng tới những dịch vụ bạn không định chạm vào.

Bước 3: xác minh điều mà việc kẹt đã che giấu

Một đường hầm kết nối được không phải là đường hầm hoạt động. Kiểm tra địa chỉ mà ứng dụng khách gán, các tuyến mà hồ sơ cài đặt, và phân giải tên cho một máy chủ nội bộ: Resolve-DnsName files.corp.example. Ứng dụng khách kết nối mà không phân giải được gì có vấn đề DNS, và rất dễ đọc sai đó là cùng lỗi cũ quay lại.

Thử một tài nguyên nội bộ theo tên và một điểm đến công cộng, để đường hầm chia tách bị hỏng không bị nhầm là ứng dụng khách đã được sửa.

Bước 4: làm cho bản sửa có thể lặp lại

Nếu cài đặt phải đến toàn bộ đội máy, hãy đưa nó vào gói triển khai hoặc cấu hình bộ điều hợp thay vì một bước thủ công lặp lại trên từng máy tính xách tay. Ghi vào phiếu rằng việc kẹt ở 98% gắn với IPv6 trên giao diện mạng, và ghi chú thứ gì khác trên máy chủ phụ thuộc vào IPv6 trước khi ai đó bật lại nó để sửa một việc không liên quan.

Một bản sửa chỉ tồn tại trong trí nhớ của một kỹ sư là bản sửa sẽ quay lại vào quý sau.

Nếu thanh chạy vẫn dừng ở 98% khi đã tắt IPv6, ghi chú của nhà cung cấp không còn giải thích được nữa và nhật ký là bằng chứng tiếp theo của bạn. Đừng chữa triệu chứng nữa và quay lại bộ đếm giai đoạn.