Azure VNet được peering có cần cổng VPN riêng không?
VNet được peering có thể dùng cổng VPN của hub với SKU được hỗ trợ và một thiết lập ở mỗi hướng peering. Hãy kiểm tra tuyến hiệu lực, không phải trạng thái peering.
Một VNet spoke mới xuất hiện, hub đã có cổng site-to-site đang hoạt động, và câu hỏi hiển nhiên là bạn có phải trả tiền cho cổng thứ hai hay không. Thường thì không: transit cổng cho phép spoke dùng cổng của hub qua peering. Ba điều kiện quyết định việc đó có hoạt động không, và không điều nào trong số đó hiển thị trên huy hiệu trạng thái peering. Kết nối peering và quyền dùng cổng của người khác là hai thiết lập riêng biệt, nên hai VM đã ping được nhau không chứng minh được gì về đường VPN.
Điều kiện thứ nhất: cổng, và việc spoke không có cổng
Azure hỗ trợ transit cổng cho các SKU VPN Gateway khác Basic, và cả peering khu vực lẫn toàn cầu đều có thể mang nó. Spoke tiêu thụ một cổng mà nó không sở hữu, nên nó không thể có cổng riêng: nếu đã có cổng trong spoke, hoặc tùy chọn cổng từ xa đã được chọn, thiết lập transit bạn muốn sẽ không khả dụng hoặc không hiệu quả. Kiểm tra điều đó trước khi gỡ lỗi bất cứ thứ gì, vì hộp kiểm bị vô hiệu hóa là triệu chứng, không phải lỗi. Đọc SKU và cổng hiện có trước, rồi xem các thiết lập peering.
Đừng xóa cổng spoke hiện có để tùy chọn xuất hiện cho đến khi bạn biết điều gì phụ thuộc vào nó. Thứ tự di trú quan trọng hơn hộp kiểm.
Điều kiện thứ hai: một thiết lập ở mỗi hướng peering
Peering là hai đối tượng, mỗi VNet một cái, và các thiết lập transit nằm ở hai phía khác nhau của cặp đó. Peering của hub về phía spoke phải cho phép cổng của hub phục vụ spoke; peering của spoke về phía hub phải chấp nhận cổng của hub. hướng dẫn transit cổng của Microsoft gọi tên chúng theo hướng, và đó là cách duy nhất để giữ chúng đúng:
| Peering direction | What to enable |
|---|---|
| Hub → spoke | Allow gateway transit on the hub's peering |
| Spoke → hub | Use remote gateways on the spoke's peering |
Một điều khiển có nhãn remote thay đổi ý nghĩa tùy theo peering của VNet nào bạn đang sửa, nên hãy đọc hướng, không phải từ ngữ. Đặt cả hai phía, lưu lại và xác nhận rằng peering báo cáo đã kết nối ở cả hai nơi.
Điều kiện thứ ba: không gian địa chỉ và ranh giới quyền
Transit không thể khiến cùng một tiền tố đích mang nghĩa hai mạng, nên dải của hub, spoke và mạng tại chỗ phải không trùng nhau trước khi bất kỳ điều gì trong số này hoạt động. Các VNet cũng có thể nằm trong đăng ký hoặc đối tượng thuê khác nhau; đó không phải là điều cấm, nhưng danh tính tạo hoặc cập nhật mỗi peering cần các quyền cần thiết trên mạng đó. Các thay đổi giữa các đăng ký thường thất bại vì quyền, và lỗi này dễ bị đọc sai thành vấn đề topo.
Ghi lại các dải và chủ sở hữu trước khi thay đổi. Đoán bất kỳ điều nào trong số đó tạo ra một peering kết nối mà không định tuyến gì.
Xác minh bằng tuyến hiệu lực, không bằng trạng thái peering
Xem các tuyến hiệu lực trên giao diện mạng của một khối lượng công việc spoke và tìm tiền tố tại chỗ thực tế. Kiểm tra bảng tuyến của mạng con và việc lan truyền tuyến cổng có bị tắt không, vì một tuyến do người dùng xác định hoặc thiết bị kiểm tra có thể ghi đè đường mà các cờ peering gợi ý. Sau đó xác nhận hướng ngược lại: mạng tại chỗ phải biết cách đến tiền tố của spoke qua kết nối site-to-site, dù bằng quảng cáo đã học hay bằng một tuyến rõ ràng và mục mạng được bảo vệ tương ứng trên thiết bị của khách hàng. Nếu thiếu tiền tố ở bất kỳ phía nào, cờ peering không phải là thứ cần thay đổi.
Kiểm thử một dịch vụ từ khối lượng công việc spoke và theo dõi phản hồi. Kiểm thử từ cổng VPN hoặc từ VM của hub dùng tiền tố nguồn và đường đi khác.
Nếu topo cũng phục vụ máy khách point-to-site, hãy xác thực riêng các tuyến đã cài của chúng. Các gói máy khách Windows có thể cần được tạo lại sau khi thay đổi topo, và đó là việc định tuyến phía máy khách, không phải bằng chứng rằng chia sẻ cổng đã thất bại.
Điều mà chia sẻ cổng không cấp
Transit cổng là tiện ích định tuyến, không phải cấp quyền. Các nhóm bảo mật mạng, bộ lọc tại chỗ và quy tắc cấp dịch vụ vẫn quyết định khối lượng công việc spoke có thể đến đâu, nên hãy bật dịch vụ cụ thể từ nguồn đến đích thay vì giả định đường hầm chia sẻ cho phép mọi thứ phía sau nó.
Peering cũng không có tính bắc cầu như người ta hy vọng. Việc thêm một spoke khác, hoặc một điểm cuối riêng, mang theo các yêu cầu định tuyến và truy cập riêng mà thiết lập transit hiện có không bao quát.