UDR của Azure tới cổng VPN: một đích đến, không phải toàn bộ lưu lượng ra

Bạn thêm một tuyến do người dùng xác định cho một tiền tố bên ngoài, trỏ nó tới cổng VPN, và lưu lượng vẫn đi ra theo đường internet của Azure. Hoặc nó đi ra đúng và phản hồi không bao giờ quay lại. Cả hai kết quả đều đến từ cùng một sai lầm: coi bước nhảy tiếp theo của Azure là toàn bộ thiết kế. Bảng tuyến chỉ quyết định gói tin đi ra cửa nào bên trong Azure. Điều gì xảy ra với nó sau đường hầm, và phản hồi quay lại thế nào, là nửa còn lại bạn phải xây dựng.

Bước nhảy tiếp theo là một cổng, không phải IP của thiết bị

Một UDR gửi tiền tố khớp tới một loại bước nhảy tiếp theo, và VirtualNetworkGateway là một loại, không phải địa chỉ. Người ta dán IP riêng của cổng vào tuyến VirtualAppliance rồi tự hỏi tại sao không khớp gì cả, vì loại đó lại mong đợi một NIC hoặc bộ cân bằng tải nội bộ. Tài liệu định tuyến của Microsoft cũng giới hạn bước nhảy tiếp theo của cổng vào một mạng ảo có cổng là cổng VPN. ExpressRoute, Route Server và một hub Virtual WAN không được định địa chỉ bằng tùy chọn đó.

Hãy kiểm tra mạng ảo thực sự có gì trước khi viết tuyến. Nếu thiết kế định tuyến qua một hub, tuyến thuộc về người sở hữu định tuyến của hub chứ không phải spoke bạn đang sửa.

Hãy đọc tuyến hiệu lực trước khi thay đổi bất cứ điều gì

Azure kết hợp tuyến hệ thống, tiền tố học qua BGP và UDR vào một bảng tuyến hiệu lực cho mỗi NIC, và tiền tố khớp dài nhất thắng bất kể nó đến từ đâu. Với cùng một tiền tố, UDR thắng tuyến BGP. Chính thứ tự đó là lý do một UDR cũ từ thử nghiệm trước có thể lặng lẽ ghi đè tiền tố bạn vừa học được qua đường hầm.

Hãy xem bảng hiệu lực trước, rồi quyết định bạn đang thêm hay thay một tuyến:

az network nic show-effective-route-table \
  --resource-group rg-net --name vm-web-nic -o table

Cũng hãy đọc cột nguồn, không chỉ tiền tố. Một tuyến có tiền tố đúng và nguồn sai cho bạn biết nên sửa đối tượng nào, và cứu bạn khỏi việc thêm tuyến thứ hai thua tuyến thứ nhất.

Viết tuyến theo tiền tố và mạng con thực

Dùng tiền tố thực của đích, lấy từ dịch vụ bạn thực sự chạm tới, thay vì một dải công cộng sao chép từ bài đăng diễn đàn. Hãy bắt đầu bằng một dịch vụ đã được phê duyệt trước khi cân nhắc tuyến mặc định dịch chuyển toàn bộ lưu lượng ra. Sau đó gắn bảng tuyến vào mạng con của khối lượng công việc. Mạng con của cổng có yêu cầu riêng, và gắn bảng của bạn vào đó sẽ làm hỏng cổng thay vì dẫn hướng khối lượng công việc.

Tạo tuyến, rồi liên kết bảng với mạng con chứa khối lượng công việc:

az network route-table route create --resource-group rg-net --route-table-name rt-egress \
  --name to-partner --address-prefix 203.0.113.0/24 --next-hop-type VirtualNetworkGateway
az network vnet subnet update --resource-group rg-net --vnet-name vnet-app \
  --name snet-web --route-table rt-egress

Việc lan truyền cũng quan trọng. Khi bật lan truyền BGP trên bảng đó, các tiền tố đã học xuất hiện bên cạnh những tiền tố bạn viết, và một tiền tố đã học cụ thể hơn có thể thắng một UDR rộng hơn. Chỉ tắt lan truyền khi bạn muốn tập UDR là nguồn có thẩm quyền cho mạng con đó.

Hoàn tất nửa phía tại chỗ, nếu không luồng sẽ chết ở đó

Cổng tại chỗ phải chấp nhận nguồn từ Azure, chuyển tiếp tới đích và cho phép ứng dụng. Đường đi tiếp theo có thể là lối ra internet hoặc một bước nhảy riêng khác, nhưng quyết định đó thuộc về kế hoạch chứ không phải bảng tuyến của Azure. Lỗi thường gặp là đường về. Một đích trên internet sẽ không định tuyến nguồn Azure riêng trở lại bạn, nên phản hồi đi tới cổng mặc định của chính nó và chết, hoặc không bao giờ ra ngoài.

Hai thiết kế giải quyết điều này và chúng không thể thay thế cho nhau. Dịch nguồn tại lối ra, để đích trả lời một địa chỉ công cộng mà mạng tại chỗ sở hữu. Hoặc giữ nguyên nguồn và xây một quan hệ trả về có định tuyến để phản hồi quay lại qua đường hầm. Chọn một và ghi lại địa chỉ mà ứng dụng sẽ thấy.

Bộ chọn và danh sách cho phép tách biệt khỏi tất cả những điều này. Chọn bước nhảy tiếp theo của Azure không mở rộng bộ chọn lưu lượng VPN và không thay đổi danh sách nguồn được phép của một dịch vụ bên ngoài.

Xác minh bằng nguồn mà đích quan sát

Gửi yêu cầu từ khối lượng công việc thực thay vì từ máy nhảy ở mạng con khác, rồi đọc địa chỉ nguồn mà đích đã quan sát. Giá trị duy nhất đó cho bạn biết thiết kế trả về nào đang được áp dụng. Tiếp theo hãy kiểm tra đường phản hồi, và xác nhận lưu lượng quản trị thông thường tới VM vẫn hoạt động, vì một tuyến mặc định được thêm nhầm sẽ hiện ra như một phiên SSH đứt trước khi hiện ra như một ứng dụng hỏng rất lâu.

Đi qua một tiền tố được chọn là thay đổi hẹp hơn nhiều so với đường hầm cưỡng bức. Giữ nó hẹp và việc hoàn tác là xóa một tuyến.