Một luồng từ chi nhánh đến Azure có thể được định tuyến đúng theo cả hai chiều mà vẫn thất bại, vì hai chiều đi qua các thiết bị khác nhau. Yêu cầu rời chi nhánh qua VPN, hạ cánh trên NVA A và đến khối lượng công việc. Gói trả lời rời khối lượng công việc, khớp với tuyến trỏ đến NVA B và chết ở đó. Mọi tuyến trong bức tranh đó đều hợp lệ, và phiên TCP vẫn bị hỏng.

Request: branch -> VPN gateway -> NVA A -> workload
Reply:   workload -> NVA B -> VPN gateway -> branch

Khoảng trống đó là toàn bộ chủ đề ở đây: hội tụ định tuyến và quyền sở hữu trạng thái phiên là hai vấn đề khác nhau trông giống hệt nhau trên sơ đồ.

Route Server thực sự lập trình gì

Azure Route Server thiết lập peering với các diễn giả BGP được hỗ trợ, học các tuyến của họ và lập trình chúng vào các tuyến hiệu lực của mạng ảo. Đó là công việc của mặt phẳng điều khiển. Nó không đọc bảng phiên của tường lửa nhà cung cấp và không biết thiết bị nào đã chấp nhận một kết nối cụ thể. Hai bước nhảy tiếp theo có chi phí bằng nhau, với kết cấu này, chỉ là hai cách để đến cùng một tiền tố, và nó sẽ dùng bất kỳ cách nào.

Vì vậy, học một tuyến chứng minh khả năng đến được. Nó không chứng minh gì về việc thiết bị ở đầu kia đã từng thấy luồng này chưa.

Đọc cả hai chiều trước khi thiết kế

Bắt đầu bằng việc ghi lại điều hướng bạn thực sự có trong mỗi chiều, không phải điều bạn dự định. Các tuyến BGP cụ thể hơn, tuyến do người dùng xác định và hành vi cổng đều cạnh tranh, và người thắng được quyết định theo đích đến, không phải theo phiên. Tuyến mặc định trên NVA không có nghĩa là mọi tiền tố riêng đều đi qua nó.

Một kiểm tra hữu ích là hỏi, với một IP khối lượng công việc cụ thể, mỗi chiều phân giải đến bước nhảy tiếp theo nào. Nếu câu trả lời là hai thiết bị khác nhau, bạn có vấn đề bất đối xứng dù nó đã lộ ra hay chưa.

Trạng thái sống ở đâu

Tường lửa có trạng thái chấp nhận một kết nối và giữ một mục bảng được khóa theo bộ năm. Gói trả lời phải đến được thiết bị giữ mục đó, hoặc thiết bị đó phải lấy trạng thái bằng cách khác. Không gì trong mặt phẳng dữ liệu Azure chuyển mục đó giữa các thiết bị. Hoặc lưu lượng được điều hướng trở lại chủ sở hữu, hoặc các thiết bị chia sẻ trạng thái qua cơ chế của nhà cung cấp, hoặc thiết kế không hoạt động.

Đó là lý do hai NVA khỏe mạnh không phải là kiểm tra sức khỏe cho việc kiểm tra. Sức khỏe là về khả năng đến được; kiểm tra là về việc phiên bản nào giữ phiên.

Các mô hình HA được hỗ trợ và mỗi mô hình hứa gì

Microsoft's guidance on ý định định tuyến của Virtual WAN mô tả hành vi giới hạn cho kết nối hai vai trò và NVA tường lửa, nơi định tuyến trực tiếp có thể bỏ qua việc thực thi đối xứng bình thường của hub. Hãy đọc những ghi chú đó như các ràng buộc đối với cấu trúc liên kết bạn đã chọn, không phải lệnh cấm các thiết kế chủ động-chủ động. Một cặp nhà cung cấp đồng bộ trạng thái, hoặc điều hướng theo từng luồng, có thể được hỗ trợ. Một cặp chi phí bằng nhau không làm cả hai thì không.

Sau đó xác định điều gì xảy ra với các phiên hiện có khi một nút hỏng. Hội tụ tuyến khôi phục khả năng đến được cho các luồng mới trong vài giây, trong khi trạng thái tường lửa cũ đơn giản là mất đi. Việc khách hàng kết nối lại có thể là kết quả được ghi nhận, và đó là quyết định đưa ra trước sự cố, không phải trong khi xảy ra.

Cần kiểm tra gì trước khi tin tưởng

Test with inspection enabled and chính sách truy cập của khối lượng công việc tại chỗ, vì một trong hai có thể che giấu sự bất đối xứng. Gửi một luồng được cấp phép mới theo cả hai chiều và xác nhận cùng một thiết bị đã thấy cả hai nửa. Sau đó chạy lưu lượng liên tục và kích hoạt chuyển đổi dự phòng đã được phê duyệt, quan sát xem các phiên đã thiết lập có sống sót hay kết nối lại.

Tương quan từng luồng với thiết bị đã xử lý nó. Bắt gói trên một NVA hầu như không cho bạn biết gì nếu gói trả lời không bao giờ quay lại đó.

Cuối cùng, viết kế hoạch thành ba dòng riêng biệt: quyền sở hữu tuyến, điều hướng lưu lượng và quyền sở hữu trạng thái phiên. Các thiết kế vỡ khi hai điều đầu được giải quyết và điều thứ ba được giả định.

Bài viết liên quan