Lưu lượng trả về của Azure P2S VPN chỉ hoạt động một chiều

Biểu tượng đường hầm màu xanh, NSG có vẻ cho phép, các tuyến hiệu lực trông đúng, vậy mà VM vẫn không thể mở kết nối trở lại máy khách đã kết nối. Giả định thông thường là một đường hầm point-to-site hoạt động được thì đối xứng: nếu máy khách đến được VM thì VM cũng đến được máy khách. Giả định đó chính là lỗi trong lập luận, không phải trong cấu hình. Một đường hầm có thể mang một chiều của luồng không được yêu cầu và bỏ chiều còn lại, và cách khắc phục phụ thuộc vào việc lớp nào đang bỏ nó.

Ngộ nhận: đường hầm đã kết nối là đường hầm hai chiều

Đường hầm VPN là một đường chính sách, không phải sợi dây. Mỗi chiều được đối chiếu với bộ chọn, tuyến và bộ lọc, và bất kỳ cái nào trong số đó đều có thể cho phép một chiều trong khi chặn chiều kia.

Trên thực tế, sự bất đối xứng phổ biến đến mức hướng phải nằm trong bài kiểm tra đầu tiên, không phải bài cuối cùng. Máy khách khởi tạo, cổng theo dõi luồng, và phản hồi đi theo trạng thái đã được tạo. Một VM khởi tạo luồng mới không có trạng thái đó, nên nó phụ thuộc vào việc đường quay về có thể định tuyến rõ ràng và được cho phép. Khi thiếu đường đó, nỗ lực kết nối chết trước khi bất kỳ ứng dụng nào nhìn thấy.

Kiểm tra hướng trước khi kiểm tra khả năng tiếp cận

Chọn một địa chỉ máy khách, một địa chỉ VM và một giao thức. Kết nối từ máy khách và ghi lại kết quả; sau đó bắt đầu cùng bài kiểm tra từ VM và cũng ghi lại. Nếu lần đầu thành công và lần thứ hai thất bại, thì nhóm máy khách, liên kết cổng và đường từ máy khách đến VNet đều hoạt động.

Bước tiếp theo là bằng chứng, không phải thêm quy tắc. Kiểm tra NSG trên mạng con của VM theo cả hai chiều, đọc các tuyến hiệu lực trên NIC của VM, và bắt gói trên VM trong khi máy khách gửi lưu lượng. Một yêu cầu đến mà không có phản hồi là vấn đề bộ lọc hoặc tuyến quay về; một yêu cầu không bao giờ đến là vấn đề đường đi. Đừng coi ping thất bại là bằng chứng VM không thể tiếp cận, vì chính sách ICMP có thể bỏ phản hồi trong khi TCP vẫn hoạt động.

Đường quay về của IKEv2 point-to-site là nghi phạm thường gặp

Trong báo cáo Azure đằng sau bài viết này, máy khách có thể đến VM qua IKEv2, nhưng ICMP vào từ VM đến máy khách thất bại cho đến khi loại đường hầm của cổng được chuyển sang OpenVPN. Người báo cáo nói rằng Microsoft đã xác nhận một hạn chế trong đường IKEv2 point-to-site, nơi lưu lượng trả về từ VM đến máy khách không được định tuyến đối xứng trừ khi máy khách đã bắt đầu phiên. IKEv2 dựa vào bộ chọn lưu lượng, và cổng đã không tôn trọng hướng quay về trong trường hợp đó.

Điều đó không làm OpenVPN trở thành loại đường hầm tốt hơn nói chung. Nó làm loại đường hầm trở thành một biến trong ma trận kiểm tra cho khối lượng công việc này.

Chuyển loại đường hầm là thay đổi dịch vụ, không phải công tắc. Mọi máy khách cần một hồ sơ tương thích, và cổng có thể cần chứng chỉ hoặc thiết lập xác thực khác. Tái tạo hành vi một chiều với một máy khách thử nghiệm và một VM thử nghiệm, thay đổi loại theo lịch đã được phê duyệt, rồi lặp lại các bài kiểm tra hướng tương tự. Nếu hành vi vẫn tồn tại sau khi chuyển, thì loại đường hầm không phải nguyên nhân và bạn đã thu hẹp vấn đề mà không chạm vào môi trường sản xuất.

Ngộ nhận: khám phá qua broadcast vượt qua ranh giới VNet

Một giả định thứ hai thất bại vì lý do không liên quan. Mạng ảo Azure không mang lưu lượng broadcast, nên VM không thể nhận khung broadcast từ mạng tại chỗ qua kết nối site-to-site hoặc point-to-site. Các ứng dụng tìm bạn ngang hàng qua broadcast, như duyệt tệp kiểu cũ hoặc một số giao thức khám phá thiết bị, sẽ không bao giờ thấy phía từ xa, bất kể các tuyến được viết thế nào.

Thay khám phá qua broadcast bằng tên DNS, dịch vụ thư mục hoặc danh sách bạn ngang hàng rõ ràng. Nếu ứng dụng không có lựa chọn thay thế unicast, thiết kế cần một cơ chế khám phá khác, không phải một đường hầm rộng hơn.

Cần thay đổi gì và chứng minh thế nào

Nếu bài kiểm tra hướng chỉ thất bại trên IKEv2, hãy ghi lại loại đường hầm của cổng, nhóm địa chỉ máy khách và bài kiểm tra ICMP hoặc TCP chính xác, rồi đánh giá một hồ sơ OpenVPN đã được phê duyệt cho các máy khách bị ảnh hưởng. Nếu nó thất bại trên mọi loại đường hầm, hãy xử lý đường quay về: địa chỉ máy khách phải định tuyến được từ mạng con của VM, mọi tuyến do người dùng xác định phải trỏ đến bước nhảy tiếp theo hợp lệ, và tường lửa của máy khách phải chấp nhận luồng vào. Đính kèm bằng chứng NSG và tuyến vào phiếu.

Xác minh bằng ứng dụng, không phải bằng ping. Một lần trao đổi ICMP thành công sau thay đổi không nói gì về cổng dịch vụ, xác thực của nó hay phân giải tên. Lặp lại bài kiểm tra sau khi kết nối lại, vì máy khách nhận địa chỉ khác từ nhóm có thể thay đổi kết quả. Sau đó lặp lại một lần nữa sau khi máy khách ngủ và thức dậy, vì trong phiên được tiếp tục, hành vi một chiều thường xuất hiện trở lại.