Azure cung cấp ít nhất hai cách để kết nối hai mạng ảo, và chúng không phải là những thiết lập thay thế được cho nhau trên cùng một đối tượng. Peering nối các VNet trên xương sống của Microsoft mà không cần cổng; VPN từ VNet đến VNet đặt một quan hệ IPsec giữa hai cổng mà bạn triển khai, định cỡ và giám sát. Quyết định quy về ba điều kiện, và nếu bạn không trả lời được cả ba trước khi thêm một tuyến, bạn sắp dựng một đường vòng cho một mô hình mà bạn chưa bao giờ chọn.

Ba điều kiện quyết định mô hình

Điều thứ nhất là liệu có gì trong yêu cầu cần một ranh giới IPsec thuộc về bạn và bạn có thể chỉ ra. Điều thứ hai là liệu các không gian địa chỉ có sạch không và hai VNet chỉ cần nói chuyện với nhau. Điều thứ ba là ai sở hữu bất kỳ đường trung chuyển nào và hóa đơn cổng. Hãy trả lời theo thứ tự đó, vì điều thứ nhất có thể loại bỏ peering dù điều thứ hai trông hấp dẫn đến đâu.

Điều chung của cả hai mô hình là một quy tắc địa chỉ cứng: các không gian địa chỉ của VNet không được chồng lấn. Cả peering lẫn VPN từ VNet đến VNet đều không phải cách được hỗ trợ để làm cho hai dải giống nhau trở nên rõ ràng, và chồng lấn cần một thiết kế ánh xạ hoặc thiết kế lại, không phải một loại kết nối khác.

Điều kiện 1: bạn có cần một ranh giới IPsec thuộc về mình không?

Peering mang lưu lượng trên xương sống riêng của Azure và không yêu cầu một cổng VPN cho chính kết nối peered. Đó là một phát biểu về vận chuyển, không phải phát biểu về mã hóa mà bạn có thể đưa cho kiểm toán viên như «chúng tôi chạy IPsec». Nếu yêu cầu nêu tên một đường hầm do khách hàng cấu hình, một chính sách IKE cụ thể hoặc một ranh giới kết thúc trên thiết bị bạn kiểm soát, peering không đáp ứng được, dù xương sống có riêng tư đến đâu.

VPN từ VNet đến VNet cung cấp ranh giới đó: hai cổng, một quan hệ IPsec/IKE, khóa chia sẻ và toàn bộ bề mặt vận hành đi kèm. Bạn thừa hưởng trạng thái đường hầm, dung lượng cổng, giới hạn SKU và việc giám sát chứng minh đường hầm đang hoạt động. Đó là câu trả lời đúng khi yêu cầu nói riêng về ranh giới đó, được mô tả trong tổng quan về peering như một loại kết nối khác với peering.

Hãy cẩn thận tương tự ở chiều ngược lại. «Chúng tôi cần mã hóa giữa các VNet» thường được đáp ứng bằng TLS của chính khối lượng công việc, và khi đó cổng là một chi phí không có yêu cầu phía sau. Hãy viết câu mà kiểm toán viên sẽ đọc trước khi chọn cơ chế.

Điều kiện 2: cấu trúc liên kết là trực tiếp hay có gì đó cần trung chuyển?

Peering không có tính bắc cầu. Hai VNet được peered vào một hub không vì thế mà được nối với nhau, và một tuyến có vẻ hoạt động theo một hướng thường là peering chỉ đạt Connected ở một phía. Cả hai phía phải tồn tại và cả hai phải hiển thị Connected, và đó là điều đầu tiên bạn kiểm tra khi lưu lượng biến mất một cách lặng lẽ.

Nếu yêu cầu là khả năng tiếp cận mạng tại chỗ qua một hub, trung chuyển cổng là một thiết kế riêng với các vai trò cụ thể: hub sở hữu cổng, peering của spoke cho phép trung chuyển cổng, và spoke phải cho phép lưu lượng được chuyển tiếp. Đó là các thuộc tính trên peering, không phải hệ quả tự động của việc nối các VNet:

az network vnet peering create -g hub-rg -n hub-to-spoke1   --vnet-name hub-vnet --remote-vnet /subscriptions/SUB/resourceGroups/spoke-rg/providers/Microsoft.Network/virtualNetworks/spoke1-vnet   --allow-vnet-access --allow-gateway-transit --allow-forwarded-traffic

az network vnet peering list -g hub-rg --vnet-name hub-vnet -o table
az network nic show-effective-route-table -g spoke-rg -n app-nic -o table

Bảng tuyến hiệu lực là câu trả lời trung thực cho «đường đi có tồn tại không?». Nó cho thấy loại chặng kế tiếp mà nền tảng sẽ thực sự dùng, nên một peering trông như đã cấu hình nhưng chưa kết nối sẽ hiện ra như một tuyến thiếu hoặc sai chứ không phải như một điều bí ẩn.

Điều kiện 3: ai sở hữu đường trung chuyển và hóa đơn?

Mỗi chặng thêm đều có chủ. Với peering, một VNet mới nghĩa là một cặp peering mới ở cả hai phía và, để trung chuyển, một hub tiếp tục chuyển tiếp lưu lượng cùng một bảng tuyến tiếp tục trỏ tới nó. Với VPN, một VNet mới nghĩa là một cổng khác hoặc một kết nối khác trên cổng sẵn có, với mức trần dung lượng riêng phải theo dõi.

Chi phí theo cùng hình dạng nhưng không cùng hạng mục: phí peering là kết nối và truyền dữ liệu, còn VPN thêm giờ cổng và phí truyền riêng. Hãy so tổng cho cấu trúc liên kết bạn thực sự vận hành trong một năm, gồm cả đường hầm thứ hai và việc giám sát, không phải giá của một kết nối hôm nay. Hãy tính cả công việc không ai xuất hóa đơn: ai đó phải luân chuyển khóa, theo dõi trạng thái đường hầm và trả lời cảnh báo lúc ba giờ sáng khi một cổng khởi động lại. Thường chính hạng mục đó quyết định cuộc tranh luận, vì nó là hạng mục duy nhất không bao giờ xuất hiện trong báo giá.

Dù bạn chọn gì, hãy thử ba luồng: luồng dự định, luồng bị từ chối phải tiếp tục bị từ chối, và trường hợp phục hồi khi cổng của hub hoặc một peering bị hỏng. Một mô hình chỉ giải thích con đường hạnh phúc thì chưa được kiểm chứng, mà mới chỉ được trình diễn.

Hãy kiểm chứng lựa chọn với chính tuyên bố của nó

Viết một câu nêu tên mô hình, ranh giới và chủ sở hữu, rồi kiểm tra rằng trạng thái đã triển khai khớp với câu đó. Với peering, điều đó nghĩa là cả hai trạng thái peering đều Connected, tuyến hiệu lực hiển thị chặng kế tiếp của peering cho tiền tố đích, và không có cổng trên đường đi. Với VPN từ VNet đến VNet, nghĩa là cả hai kết nối đều Connected, khóa và chính sách khớp trên cả hai cổng, và một tuyến có chặng kế tiếp là cổng mạng ảo.

Nếu các kiểm tra mâu thuẫn với câu đó, hãy sửa câu trước. Phần lớn sự nhầm lẫn trong các thiết kế này đến từ một mô hình lai mà không ai mô tả: một peering cho mạng con của khối lượng công việc, một VPN cho một dịch vụ cũ, và một bảng tuyến lặng lẽ ưu tiên một trong hai.

Bài viết liên quan