GVC kẹt ở Acquiring IP: đây không phải vấn đề mật khẩu

Global VPN Client dừng ở Acquiring IP, và phản xạ đầu tiên là gõ lại mật khẩu hoặc cài lại máy khách. Cả hai đều không chạm vào giai đoạn đã thất bại. Xác thực đã xong trước khi máy khách yêu cầu địa chỉ, nên không phải thông tin đăng nhập giữ bạn ở dòng đó. Thứ giữ bạn ở đó là một cuộc trao đổi DHCP chưa xong, và nó có thể kẹt ở ba nơi khác nhau.

Xác thực và gán địa chỉ là hai giai đoạn riêng

GVC trước tiên chứng minh bạn là ai, sau đó yêu cầu cài đặt cho card mạng ảo của nó theo chính sách được gán cho kết nối của bạn. Đây là các bước tuần tự với dấu hiệu lỗi khác nhau. Thông tin đăng nhập sai thường lỗi sớm hơn, bằng thông báo xác thực hoặc thương lượng thay vì dòng địa chỉ.

Thứ tự đó giải thích vì sao đặt lại mật khẩu, tạo người dùng cục bộ mới hay cài lại không thay đổi gì ở đây. Máy khách đã được cấp quyền; giờ nó chờ một hợp đồng thuê mà cổng hoặc đối tác DHCP của nó phải cung cấp. Ngay cả chính sách cho phép người dùng nhưng không gán dải địa chỉ cũng tạo ra đúng màn hình này.

Vì vậy câu hỏi hữu ích đầu tiên không phải là thông tin đăng nhập có đúng không, mà là chính sách nào đã được gán và chính sách đó nói gì về việc đánh địa chỉ cho card mạng ảo. Hãy đọc cấu hình thực tế của kết nối đó thay vì ảnh chụp màn hình đang chạy của đồng nghiệp.

Hợp đồng thuê thực sự đến từ đâu

Hai mô hình là phổ biến. Tường lửa có thể tự chạy một phạm vi DHCP cho máy khách VPN, hoặc chuyển tiếp yêu cầu tới máy chủ DHCP bên ngoài trong mạng nội bộ. Mô hình quyết định nhật ký nào quan trọng và cần gọi ai.

Ở mô hình nội bộ, hãy kiểm tra phạm vi còn tồn tại, thuộc đúng giao diện và có hợp đồng thuê trống. Phạm vi cạn kiệt tạo ra máy khách xác thực hoàn hảo mà không bao giờ nhận địa chỉ, và nhật ký cổng có thể chỉ hiển thị yêu cầu. Ở mô hình chuyển tiếp, đích chuyển tiếp, tuyến quay lại dải máy khách VPN và mọi ủy quyền DHCP nội bộ đều phải khớp.

Hãy ghi lại mô hình mà triển khai của bạn dùng trước khi thử bất cứ điều gì. Một nửa lời khuyên mâu thuẫn trên mạng giả định mô hình còn lại.

Đường hầm có thể hoạt động mà vẫn mất hợp đồng thuê

Một kết nối điều khiển đã thiết lập chứng minh thương lượng đã thành công, không chứng minh dữ liệu đường hầm đi cả hai chiều. Trao đổi DHCP cần yêu cầu và trả lời để vượt qua đường dữ liệu, và đó là nơi cài đặt mã hóa, chính sách vùng VPN và vấn đề MTU nằm.

Lời khuyên về NAT traversal là ví dụ rõ nhất rằng bối cảnh quan trọng. Một số đường cần bật nó, số khác chỉ hoạt động khi tắt, và NAT ở giữa cùng kết nối đã thương lượng quyết định cái nào. Thay đổi nó một cách mù quáng trong khi cũng đổi cài đặt máy khách nghĩa là bạn sẽ không biết thay đổi nào tạo ra kết quả. Hãy ghi lại đường đã thương lượng và bằng chứng trước khi đổi đóng gói.

Khởi động lại router ở nhà thuộc cùng loại. Đôi khi nó xóa triệu chứng, nhưng không xác định vì sao hợp đồng thuê thất bại, và vấn đề quay lại ở kết nối tiếp theo.

Đi theo đường thuê địa chỉ theo thứ tự

Bắt đầu từ card mạng và đi ra ngoài, để mỗi bước chỉ có thể thất bại vì một lý do:

> Get-NetAdapter | Where-Object Name -like "*GVC*"
> ipconfig /all | findstr /i /c:"GVC" /c:"IPv4" /c:"DHCP"
> Test-NetConnection 10.60.0.1 -Port 443

Địa chỉ như 169.254.x.x nghĩa là card mạng tồn tại và không nhận được trả lời nào, điều này chỉ vào nguồn cấp hợp đồng thuê hoặc đường dữ liệu. Địa chỉ đúng trong dải VPN nhưng mục DNS sai là lỗi khác: hợp đồng thuê đã chạy và chính sách cung cấp cài đặt chưa đầy đủ. Card mạng không bao giờ xuất hiện nghĩa là máy khách chưa tới mức tạo ra nó.

Khi hợp đồng thuê xuất hiện, hãy thử tài nguyên thật thay vì tuyên bố thắng lợi ở dòng địa chỉ. Nếu truy cập tệp hoặc mạng nội bộ vẫn lỗi, hãy giữ hợp đồng thuê thành công làm bằng chứng và chuyển sang phân giải tên hoặc chính sách, vì bạn đã bỏ lại lỗi ban đầu phía sau.

Ghi chú của SonicWall về card mạng ảo liệt kê một số nhánh riêng biệt, và ảnh chụp màn hình cũ của nó không nên được đọc như bản đồ menu hiện tại. Dùng nó để xác nhận giai đoạn bạn đã đạt, không phải như danh sách kiểm tra để áp dụng toàn bộ.