Azure P2S: một máy khách Windows mất tuyến sau khi VNet thay đổi

Hai máy tính xách tay xác thực vào cùng một gateway Azure point-to-site, và chỉ một máy tới được VNet vừa kết nối. Cả hai đều hiển thị Connected, nên xác thực không phải điểm khác biệt; các tuyến đích mà chúng giữ mới là khác biệt. Hãy bắt đầu từ máy khách bị lỗi, so sánh một đích duy nhất, và chỉ sau đó quyết định xem khoảng trống thuộc về gói gateway hay bảng tuyến cục bộ.

Bắt đầu từ máy khách bị lỗi, không phải từ gateway

Xác nhận topology trước khi đổ lỗi cho máy tính xách tay. Kiểm tra VNet nào được kết nối với VNet của gateway và mạng mới được peer trực tiếp hay truy cập qua một đường hầm site-to-site riêng. Nếu VNet mới hoàn toàn không kết nối với VNet của gateway, không gói máy khách nào có thể định tuyến tới đó, và chiếc máy tính đang hoạt động chính là điểm bất thường cần giải thích. Hãy ghi lại câu trả lời, vì nó quyết định bạn đang gỡ lỗi máy khách hay gateway.

Khi topology đúng, đặt hai máy tính cạnh nhau. Cùng gateway, cùng pool địa chỉ, cùng giao thức và cùng bản dựng máy khách là phép so sánh bạn muốn; mọi thứ khác là biến thứ hai mà bạn sẽ phải loại bỏ sau này.

So sánh một đích bằng route print

Chọn một IP tài nguyên được phép và so sánh cả hai máy hai lần: khi ngắt kết nối, rồi khi kết nối. Trên Windows, route print -4 liệt kê các tuyến IPv4 với tiền tố đích, giao diện, chặng kế tiếp và metric. Ghi lại dòng thực sự sẽ thắng cho đích đó thay vì đếm các mục có chứa từ VPN.

Việc chọn lựa ưu tiên tiền tố dài nhất trước, rồi đến metric, nên một tuyến cục bộ cụ thể hơn có thể thắng tuyến đường hầm mà không trông sai. Nếu đích dự định nằm trong 10.24.0.0/16, một máy khách khỏe mạnh hiển thị tuyến khớp trên giao diện VPN, trong khi máy khách bị lỗi gửi cùng địa chỉ đó tới gateway mặc định của nó.

Một tiền tố cục bộ xung đột có thể tạo ra triệu chứng tương tự. Trước khi thêm bất cứ thứ gì, hãy xác định bạn thuộc trường hợp nào trong hai trường hợp: hoàn toàn không có tuyến đường hầm, hay có tuyến đường hầm nhưng thua một tuyến cụ thể hơn.

TTL expired không phải lỗi phân phối tuyến

Một ping trả về TTL expired in transit cho biết gói đã dùng hết hạn mức chặng, điều này thường nghĩa là vòng lặp chuyển tiếp chứ không phải trình điều khiển VPN hỏng. Ping của Windows chấp nhận TTL tới 255, và tăng giá trị không sửa được vòng lặp; nó chỉ trì hoãn cùng lỗi đó. Hãy coi thông báo là triệu chứng của đường đi, không phải bằng chứng về phân phối tuyến.

Dùng tracert -4 10.24.1.10 để xem đường đi lặp lại ở đâu. Nếu cùng hai chặng xuất hiện lặp đi lặp lại, hãy tìm một tuyến gửi lưu lượng hướng vào đường hầm trở lại đường hầm hoặc tới một router cục bộ chuyển nó ngược lại.

Tạo lại gói trên gateway sở hữu nó

Microsoft ghi nhận rằng gói máy khách Windows phải được tải xuống và cài đặt lại sau các thay đổi topology liên quan. Lấy gói hiện tại từ gateway Azure phục vụ hồ sơ này, rồi áp dụng nó bằng quy trình được hỗ trợ cho máy khách đó. Thay thế tệp thực thi của một ứng dụng VPN không liên quan không phải cùng thao tác với việc tạo lại cài đặt dành riêng cho gateway. Tải lại gói thì rẻ; đoán tuyến cục bộ thì không.

Kết nối lại và đọc lại tuyến cho đích ban đầu. Giữ các dòng trước và sau cùng với bản ghi thay đổi để kết quả chính xác hơn tôi đã cài lại máy khách.

Các kịch bản định tuyến Azure P2S tách VNet được peer trực tiếp khỏi các mạng truy cập qua đường hầm khác, và một gói mới không thể làm peering trở nên bắc cầu. Một số kịch bản Windows site-to-site hoặc BGP cũng cần tuyến từ xa được cấu hình thủ công, nên việc làm mới gói không phải cơ chế phân phối tuyến phổ quát.

Giữ một tuyến tạm thời là tạm thời

Một tuyến thủ công có thể cô lập tuyến máy khách bị thiếu, nhưng hãy xây nó từ thiết kế thực tế: route add 10.24.0.0 mask 255.255.0.0 172.16.0.1 if 42, không có cờ thường trú, để nó biến mất khi khởi động lại. Chọn chỉ số giao diện và chặng kế tiếp từ adapter VPN đang kết nối, không phải từ phỏng đoán.

Đừng để một tuyến thử nghiệm thành chủ sở hữu cạnh tranh vĩnh viễn. Các bản cập nhật hồ sơ sau này có thể thêm cùng tiền tố với metric khác, và khi đó mục thủ công âm thầm quyết định đường nào thắng. Ghi lại bước gỡ bỏ trong bản ghi thay đổi.

Khi tuyến đúng đã hoạt động, hãy kiểm tra ứng dụng đích thay vì ping. Nếu gói tới được Azure nhưng dịch vụ vẫn lỗi, hãy kiểm tra nhóm bảo mật mạng và đường quay về, vì chúng tách biệt với việc máy tính đã học tiền tố hay chưa.