Hai địa chỉ VPN tại chỗ: hai peer Azure, không phải một

Sơ đồ có hai liên kết internet tại chi nhánh và một cổng VPN Azure, vì vậy cổng mạng nội bộ nhận cả hai địa chỉ công khai. Nó trông gọn gàng và không hoạt động như sơ đồ ngụ ý. Mỗi thiết bị VPN tại chỗ là một quan hệ peer riêng, và thiết kế nhiều thiết bị của Microsoft cung cấp cho mỗi thiết bị tài nguyên cổng mạng nội bộ và kết nối riêng. Thêm địa chỉ thứ hai vào một tài nguyên không tạo ra peer thứ hai. Nó tạo ra một tài nguyên không mô tả đúng cả hai thiết bị.

Lầm tưởng: một cổng, hai địa chỉ

Cổng mạng nội bộ là mô tả của một peer từ xa: một điểm cuối công khai và các tiền tố riêng phía sau. Không có cách được hỗ trợ nào để tài nguyên đó có nghĩa là «một trong hai thiết bị này».

Sự nhầm lẫn tương tự cũng diễn ra theo hướng ngược lại, nơi hai IP công khai của Azure được đọc như bằng chứng rằng có hai cổng Azure.

Đếm các đối tượng, sau đó đếm các đường hầm

Lấy hai thiết bị tại chỗ được vận hành độc lập, mỗi thiết bị có địa chỉ công khai riêng và quyền truy cập vào cùng các mạng riêng, cộng với một cổng Azure dựa trên định tuyến ở chế độ chủ động-chủ động. Cổng Azure có hai phiên bản chủ động với IP công khai riêng. Mỗi thiết bị tại chỗ kết nối với cả hai phiên bản. Đó là lưới đầy đủ, và số lượng đối tượng xuất phát từ đó, không phải từ sơ đồ.

Phép tính đủ ngắn để dán vào tài liệu thiết kế:

2 on-premises VPN devices
2 local network gateway resources
2 connection resources
4 IPsec tunnels in the complete 2 x 2 mesh

Một tài nguyên kết nối có thể mang nhiều hơn một đường hầm cơ bản, vì vậy bốn đường hầm không có nghĩa là bốn cổng mạng ảo. Hai IP công khai của Azure cũng không phải là cùng các đối tượng như hai cổng mạng nội bộ mô tả site từ xa.

Chế độ chủ động-chủ động thêm gì ở phía Azure

Chế độ chủ động-chủ động thay đổi cổng Azure từ một phiên bản chủ động thành hai, mỗi phiên bản có IP công khai riêng, và đó là điều làm cho một lưới đầy đủ trở nên khả thi. Nó không nhân đôi thông lượng của một luồng. Nó cũng không loại bỏ nhu cầu phía tại chỗ phải hỗ trợ đa đường dẫn với chi phí bằng nhau nếu cả hai thiết bị chuyển tiếp cùng lúc. Xác nhận chế độ cổng, SKU và khả năng của thiết bị từ xa trước khi cung cấp bất cứ thứ gì.

Một cổng ở chế độ chờ thụ động là thiết kế hoàn toàn hợp lệ; nó chỉ tạo ra số đường hầm khác.

BGP làm cho cả hai đường đều sử dụng được

Đối với thiết kế nhiều thiết bị, cả hai thiết bị tại chỗ đều chạy BGP. Cung cấp cho mỗi thiết bị một địa chỉ peer BGP duy nhất và quảng bá các tiền tố riêng dự định giống nhau qua các đường liên quan. Các tiền tố riêng xác định các mạng được bảo vệ, trong khi địa chỉ công khai xác định nơi các kết nối nhà mạng được mã hóa kết thúc. Nhầm lẫn hai điều này tạo ra thiết kế trong đó mọi đường hầm đều hoạt động nhưng các tuyến lại sai.

Lập kế hoạch định tuyến trả về và mọi kiểm tra trạng thái phải chịu được một trong hai đường. Một phiên IKE khỏe mạnh trên mỗi điểm cuối không chứng minh rằng một khối lượng công việc có thể sử dụng mọi tuyến được quảng bá.

Lựa chọn dựa trên luồng không phải là gộp băng thông

Azure chọn một đường cho mỗi luồng bằng cách sử dụng hàm băm trên địa chỉ và cổng của luồng. Ở trạng thái ổn định, các gói của một luồng TCP hoặc UDP nhất định thường đi cùng một đường hầm, và phía tại chỗ có thể chọn đường hầm khác cho hướng trả về. Vì vậy hai thiết bị và bốn đường hầm cải thiện tính sẵn sàng, không phải tốc độ của một lần truyền. Khi một slide của nhà cung cấp hứa hẹn tổng hợp, nó đang mô tả một tính năng khác hoặc một hiểu lầm.

Hãy thử với các luồng song song nếu bạn muốn thấy các đường lan tỏa, và với một luồng nếu bạn muốn thấy giới hạn.

Bạn thực sự đã loại bỏ dự phòng nào

Hai địa chỉ WAN trên một thiết bị cải thiện các tùy chọn liên kết truy cập trong khi chia sẻ nguồn điện, phần mềm và trạng thái lỗi của thiết bị đó. Chúng không giống như hai thiết bị, và không cấu hình nào ở phía Azure thay đổi điều đó. Hãy làm theo thiết kế WAN kép hoặc cụm được nhà cung cấp hỗ trợ thay vì suy ra dự phòng từ số lượng địa chỉ. Sau đó kiểm tra: loại bỏ từng đường một và xác nhận các tuyến còn lại cùng trao đổi ứng dụng thực tế theo cả hai hướng.

Hãy mong đợi độ trễ phát hiện và hội tụ, và mong đợi một số phiên hiện có sẽ kết thúc.