VPN IP riêng của Azure trên ExpressRoute không cần NVA

Niềm tin sai lầm là việc mã hóa lưu lượng qua peering riêng của ExpressRoute đòi hỏi một thiết bị mạng ảo. Không cần. Azure hỗ trợ Site-to-Site VPN Gateway có điểm cuối đường hầm là địa chỉ RFC1918 riêng được vận chuyển qua mạch, và thiết bị là tùy chọn chứ không phải bắt buộc về cấu trúc. Điều mà niềm tin về thiết bị che giấu là phần thực sự gây đau: bật điểm cuối riêng trên một đối tượng thay vì hai, và để một tuyến peering trực tiếp lặng lẽ thắng đường đã mã hóa.

Niềm tin này đến từ đâu

Khẳng định này có nguồn gốc đáng kính. Trong nhiều năm, công thức thực tế cho IPsec qua peering riêng là một NVA, vì cổng được quản lý chỉ phơi bày các điểm cuối công khai. Điều đó đã thay đổi, và những câu trả lời viết trước thay đổi vẫn được trích dẫn trong các luồng mà không ai kiểm tra ngày. Sự sửa chữa hẹp: tồn tại cổng VPN có địa chỉ riêng, và nó thay đổi điểm cuối, không thay đổi logic định tuyến xung quanh.

Không điều nào trong số này cho NVA nghỉ hưu. Nó cho nghỉ hưu giả định rằng thiết bị là con đường duy nhất đến yêu cầu.

Bật điểm cuối riêng ở cả hai cấp

Hãy bắt đầu từ một kết nối peering riêng ExpressRoute đang hoạt động và được liên kết với VNet chứa cổng VPN. Phía tại chỗ phải đã tiếp cận các địa chỉ riêng liên quan qua mạch đó, vì đường hầm sẽ dùng những địa chỉ ấy làm vận chuyển. Sau đó là điều kiện tiên quyết của cổng: quy trình của Microsoft cho VPN IP riêng yêu cầu một cổng được xây trên tài nguyên IP công khai Standard. Địa chỉ hóa đường hầm riêng không xóa bỏ yêu cầu đó, điều khiến những người cho rằng «riêng» nghĩa là «không có IP công khai ở đâu cả» ngạc nhiên.

Bây giờ bật cờ ở cả hai nơi. Cấu hình cổng có công tắc riêng cho IP riêng, và kết nối Site-to-Site riêng lẻ có công tắc thứ hai buộc kết nối đó dùng địa chỉ riêng. Đặt một mà không đặt cái kia là cấu hình thiếu sót phổ biến nhất; đường hầm hoặc không thiết lập được hoặc thiết lập đến sai điểm cuối.

az network vnet-gateway update -g rg-net -n vpngw-prod --set enablePrivateIpAddress=true
az network vpn-connection update -g rg-net -n conn-onprem --set enablePrivateIpAddress=true
az network vnet-gateway show -g rg-net -n vpngw-prod \
  --query '{sku:sku,priv:enablePrivateIpAddress,active:activeActive}'

Hãy xác nhận tên thuộc tính với phiên bản CLI đã cài, vì nhãn trên cổng thông tin và thuộc tính CLI không phải lúc nào cũng dùng cùng cách diễn đạt. Cổng hoạt động-hoạt động phơi bày hai địa chỉ đường hầm riêng, và thiết bị tại chỗ cần cấu hình cả hai đối tác nếu muốn sự dư thừa đó có ý nghĩa. BGP không bắt buộc chỉ để dựng đường hầm có địa chỉ riêng này, dù nó thường là một phần của cách bạn phân phối tiền tố.

Niềm tin thứ hai: đường hầm đã thiết lập là mã hóa lưu lượng của bạn

Hai đường giờ đây đến mạng ứng dụng: đường peering riêng trực tiếp và đường qua VPN. Cả hai đều hoạt động. Chỉ một đường áp dụng lớp IPsec này. Microsoft ghi nhận rằng khi các tiền tố giống nhau được quảng bá qua ExpressRoute và qua VPN, Azure ưu tiên đường ExpressRoute trực tiếp, nên một đường hầm khỏe với bộ đếm khỏe không chứng minh được gì về nơi các gói ứng dụng đã đi.

Các phương pháp điều hướng được ghi nhận là một dải bao phủ trên ExpressRoute với một dải được bảo vệ cụ thể hơn trên VPN, hoặc các tiền tố rời nhau trên hai đường. Ví dụ, peering riêng có thể mang 10.40.0.0/16 trong khi VPN quảng bá 10.40.12.0/24. Tiền tố cụ thể hơn thắng và phần còn lại của dải vẫn trực tiếp.

az network vnet-gateway list-advertised-routes -g rg-net -n vpngw-prod
az network vnet-gateway list-learned-routes -g rg-net -n vpngw-prod
az network vpn-connection show -g rg-net -n conn-onprem --query connectionStatus

Hãy kiểm tra tương tự theo hướng tại chỗ, vì tùy chọn của bộ định tuyến quyết định lưu lượng đi ra theo hướng nào. Và giữ vận chuyển của chính đường hầm trên đường ExpressRoute; một tuyến kéo điểm cuối riêng của cổng vào trong đường hầm khiến đường hầm phụ thuộc vào chính nó.

Quyết định điều gì xảy ra khi đường hầm sập

Tuyến VPN cụ thể hơn biến mất khi đường hầm sập, trong khi tuyến trực tiếp rộng hơn vẫn còn. Lưu lượng khi đó chảy không mã hóa và mọi thứ trông khỏe mạnh, đây là chế độ hỏng tệ nhất cho một yêu cầu tồn tại để bảo đảm mã hóa. Nếu yêu cầu cấm việc quay lui đó, định tuyến và chính sách truy cập phải nói rõ điều đó thay vì dựa vào tính sẵn sàng của đường hầm.

Ghi lại tiền tố nào được phép tiếp tục tiếp cận trực tiếp và tiền tố nào phải dừng khi không có đường mã hóa. Sau đó kiểm thử trường hợp được phép bằng lưu lượng thật và so sánh bộ đếm kết nối, vì chỉ bảng tuyến không cho bạn biết yêu cầu mã hóa còn hiệu lực hay không.

Khung đó cũng cho phép bạn đánh giá một NVA theo các tính năng thực của nó, như nhiều đường hầm, thông lượng hay kiểm tra của nhà cung cấp, thay vì mua một cái vì điểm cuối là riêng.