Kiểm tra luồng IP của Azure báo được phép, nhưng VPN vẫn thất bại

Đường hầm site-to-site đã kết nối, VM khỏe mạnh, nhưng máy khách tại chỗ không nhận được gì. Bạn mở Network Watcher, chạy kiểm tra luồng IP và nó báo Access allowed, thế là phiếu được đóng như một sự cố VPN. Kết quả đó không mang nghĩa như vẻ ngoài, vì kiểm tra luồng IP đánh giá các quy tắc bảo mật cho luồng bạn mô tả và không bao giờ kiểm tra xem Azure có tuyến tới tiền tố tại chỗ của bạn hay không.

Câu hỏi lọc gói và câu hỏi định tuyến là tách biệt, và Network Watcher trả lời chúng bằng công cụ khác nhau. Biết mình đã hỏi câu nào là phần lớn của chẩn đoán.

Kiểm tra luồng IP thực sự quyết định điều gì

Kiểm tra luồng IP nhận một VM, một giao diện mạng, một hướng, các giá trị bộ năm và một giao thức, rồi báo cáo quyết định của quy tắc NSG và quản trị bảo mật cho luồng đó. Nó chạy trên TCP và UDP, nên không phải công cụ kiểm tra quy tắc ICMP và một ping bị chặn không chứng minh gì về dịch vụ của bạn. Hãy cấp cho nó luồng thật thay vì phỏng đoán. Kết nối vào từ môi trường tại chỗ tới một cổng cơ sở dữ liệu là mô tả khác với kết nối ra do VM khởi tạo.

Nếu cổng mạng dịch địa chỉ, hãy dùng địa chỉ nguồn tới được ranh giới bạn đang đánh giá, không phải địa chỉ trong cấu hình máy khách. Cũng hãy đọc kết quả đúng như nó là. Access allowed nghĩa là lớp lọc sẽ cho gói đi nếu nó tới, và không hơn thế.

Điều nó không thể nói là tuyến Azure đã chọn, liệu tường lửa của khách có cho phép cổng hay có gì đang lắng nghe. Những thứ đó sống ở tầng khác.

Bước nhảy tiếp theo và tuyến hiệu lực thêm gì

Bước nhảy tiếp theo trả lời câu hỏi chuyển tiếp: với đích này, Azure chọn loại bước nhảy tiếp theo nào, tại địa chỉ nào, từ bảng tuyến nào. Tuyến hiệu lực liệt kê những gì NIC thực sự có. Chạy cả hai và bạn nhận được đường đi phía Azure mà một kiểm tra luồng IP xanh để trống.

Tổng quan kiểm tra luồng IP của Microsoft nêu trực tiếp phạm vi lọc, còn các trang về bước nhảy tiếp theo và chẩn đoán tuyến bao quát phía chuyển tiếp. Hãy trích đúng trang khi viết kết luận.

Các lệnh đủ ngắn để chạy từ shell. az network nic show-effective-route-table liệt kê các tuyến áp dụng cho giao diện. az network watcher show-next-hop với nguồn và đích trả về bước nhảy được chọn. So sánh tiền tố bạn quan tâm với bảng đó, rồi xác nhận mục nào thắng.

Đi theo đường về từ NIC của VM

Hãy làm điều này từ NIC của VM đích, cho tiền tố máy khách tại chỗ, không phải cho internet. Đường về là nơi các sự cố site-to-site ẩn náu, vì kiểm tra trạng thái đường hầm chỉ báo rằng các hiệp hội bảo mật đang hoạt động.

Nếu thiếu tuyến mong đợi, hãy kiểm tra các tiền tố từ xa mà cấu hình cổng cung cấp, thiết kế kết nối VNet và mọi thiết lập lan truyền tuyến. Đối tượng cổng mạng tại chỗ mô tả phía tại chỗ; sự tồn tại của nó không chứng minh rằng mọi tiền tố cần thiết đều có mặt và được ưu tiên trên NIC. Đó là những sự thật khác nhau, và chỉ một trong số đó xuất hiện trong bản tóm tắt cổng thông tin.

Đọc loại bước nhảy tiếp theo thay vì sao chép ví dụ

Một đường qua cổng VPN được quản lý thường hiển thị VirtualNetworkGateway là loại bước nhảy tiếp theo. VirtualAppliance mô tả một thiết kế chuyển tiếp khác, thường là tường lửa hoặc thiết bị mạng ảo.

Đừng tạo tuyến thiết bị trỏ tới điểm cuối VPN phỏng đoán chỉ vì một câu trả lời diễn đàn cũ dùng loại đó. Nếu tuyến do người dùng định nghĩa ghi đè đường dự định, hãy tìm chủ sở hữu và mục đích của nó trước khi thay đổi. NIC thứ hai cũng có thể đổi giao diện mà khách dùng, và gỡ nó có thể làm hỏng dịch vụ khác thay vì sửa tuyến này.

Chuyển tới ranh giới vẫn còn thất bại

Khi lọc và định tuyến đều khớp thiết kế, lỗi nằm ở nơi khác. Kiểm tra bảng tuyến của chính khách, tường lửa của nó và việc trình lắng nghe có gắn với địa chỉ mong đợi không. Rồi kiểm tra bộ chọn lưu lượng được bảo vệ của VPN và đường phản hồi tại chỗ. Mỗi thứ là một phép thử riêng với kết quả riêng.

Kết thúc bằng một yêu cầu ứng dụng được phép và quan sát từ hai đầu. Kết quả allow và một bước nhảy tiếp theo đúng là hai mảnh bằng chứng, không phải bằng chứng rằng kết nối đã thành công.