Azure privátní IP VPN přes ExpressRoute bez NVA

Mýtus říká, že šifrování provozu přes privátní peering ExpressRoute vyžaduje virtuální síťové zařízení. Nevyžaduje. Azure podporuje Site-to-Site VPN Gateway, jejíž koncový bod tunelu je privátní adresa RFC1918 nesená přes okruh, a zařízení je volitelné, nikoli strukturální. Co mýtus o zařízení skrývá, je část, která skutečně bolí: zapnutí privátního koncového bodu na jednom objektu místo dvou a to, že přímá peering trasa tiše vyhraje nad šifrovanou cestou.

Odkud mýtus přišel

Tvrzení má úctyhodný původ. Po léta byl praktickým receptem pro IPsec přes privátní peering NVA, protože spravovaná brána vystavovala jen veřejné koncové body. To se změnilo a odpovědi napsané před změnou se stále citují ve vláknech, kde nikdo nekontroluje datum. Oprava je úzká: brána VPN s privátní adresou existuje a mění koncový bod, ne logiku směrování kolem něj.

Nic z toho NVA neposílá do důchodu. Do důchodu posílá předpoklad, že zařízení je jediná cesta ke splnění požadavku.

Zapněte privátní koncový bod na obou úrovních

Začněte funkčním připojením privátního peeringu ExpressRoute propojeným s VNet, ve které je brána VPN. Na místní straně už musí být přes tento okruh dostupné příslušné privátní adresy, protože tunel je bude používat jako transport. Pak předpoklad brány: postup Microsoftu pro VPN s privátní IP vyžaduje bránu postavenou na veřejném IP prostředku Standard. Privátní adresace tunelu tento požadavek neruší, což překvapuje lidi, kteří předpokládají, že „privátní“ znamená „nikde žádná veřejná IP“.

Nyní zapněte příznak na obou místech. Konfigurace brány má vlastní přepínač pro privátní IP a jednotlivé připojení Site-to-Site má druhý, který tomuto připojení říká, aby privátní adresu použilo. Nastavit jedno a ne druhé je nejčastější neúplná konfigurace; tunel se buď neustaví, nebo se ustaví na špatný koncový bod.

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}'

Ověřte názvy vlastností proti nainstalované verzi CLI, protože popisky portálu a vlastnosti CLI nemají vždy stejnou formulaci. Aktivně-aktivní brána vystavuje dvě privátní adresy tunelu a místní zařízení potřebuje nakonfigurované oba protějšky, pokud má tato redundance něco znamenat. BGP není potřeba jen k tomu, aby se tento tunel s privátní adresou zvedl, i když bývá součástí způsobu, jak rozdělujete prefixy.

Druhý mýtus: ustanovený tunel šifruje váš provoz

Ke síti aplikace nyní vedou dvě cesty: přímá cesta privátního peeringu a cesta přes VPN. Obě fungují. Jen jedna aplikuje tuto vrstvu IPsec. Microsoft dokumentuje, že když se identické prefixy inzerují přes ExpressRoute i přes VPN, Azure upřednostní přímou cestu ExpressRoute, takže zdravý tunel se zdravými čítači nic nedokazuje o tom, kam aplikační pakety odešly.

Zdokumentované metody řízení jsou pokrývající rozsah na ExpressRoute s konkrétnějším chráněným rozsahem na VPN, nebo disjunktní prefixy na obou cestách. Pro ilustraci může privátní peering nést 10.40.0.0/16, zatímco VPN inzeruje 10.40.12.0/24. Konkrétnější prefix vyhraje a zbytek rozsahu zůstane přímý.

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

Stejnou kontrolu proveďte v místním směru, protože preference vašeho routeru rozhoduje o tom, kudy odchozí provoz odejde. A vlastní transport tunelu držte na cestě ExpressRoute; trasa, která vtáhne privátní koncový bod brány do tunelu, udělá tunel závislým na sobě samém.

Rozhodněte, co se stane, když tunel spadne

Konkrétnější trasa VPN zmizí, když tunel spadne, zatímco širší přímá trasa zůstane. Provoz pak teče nešifrovaně a všechno vypadá zdravě, což je nejhorší režim selhání pro požadavek, který existuje proto, aby šifrování zaručil. Pokud požadavek tento návrat zakazuje, směrování a přístupová politika to musí říct výslovně, místo aby se spoléhaly na dostupnost tunelu.

Zapište, které prefixy smějí zůstat přímo dostupné a které musí přestat, když šifrovaná cesta chybí. Pak otestujte povolený případ skutečným provozem a porovnejte čítače připojení, protože samotná routovací tabulka vám neřekne, zda požadavek na šifrování stále platí.

Tento rámec vám také umožní hodnotit NVA podle jeho skutečných funkcí, jako jsou více tunelů, propustnost nebo inspekce dodavatele, místo abyste ho kupovali proto, že koncový bod je privátní.