Azure privátne IP VPN cez ExpressRoute bez NVA

Mýtus tvrdí, že šifrovanie prevádzky cez privátny peering ExpressRoute vyžaduje virtuálne sieťové zariadenie. Nevyžaduje. Azure podporuje Site-to-Site VPN Gateway, ktorého koncový bod tunela je privátna adresa RFC1918 prenášaná cez okruh, a zariadenie je voliteľné, nie štrukturálne. Čo mýtus o zariadení skrýva, je časť, ktorá naozaj bolí: zapnutie privátneho koncového bodu na jednom objekte namiesto dvoch a to, že priama peering trasa ticho vyhrá nad šifrovanou cestou.

Odkiaľ mýtus prišiel

Tvrdenie má úctyhodný pôvod. Roky bol praktickým receptom na IPsec cez privátny peering NVA, pretože spravovaná brána vystavovala len verejné koncové body. To sa zmenilo a odpovede napísané pred zmenou sa stále citujú vo vláknach, kde nikto nekontroluje dátum. Oprava je úzka: brána VPN s privátnou adresou existuje a mení koncový bod, nie logiku smerovania okolo neho.

Nič z toho neposiela NVA do dôchodku. Do dôchodku posiela predpoklad, že zariadenie je jediná cesta k požiadavke.

Zapnite privátny koncový bod na oboch úrovniach

Začnite funkčným pripojením privátneho peeringu ExpressRoute prepojeným s VNet, v ktorej je brána VPN. Lokálna strana už musí dosiahnuť príslušné privátne adresy cez tento okruh, pretože tunel ich použije ako transport. Potom predpoklad brány: postup Microsoftu pre VPN s privátnou IP vyžaduje bránu postavenú na verejnom IP prostriedku Standard. Privátne adresovanie tunela tento predpoklad neruší, čo prekvapuje ľudí, ktorí si myslia, že „privátne“ znamená „nikde žiadna verejná IP“.

Teraz zapnite príznak na oboch miestach. Konfigurácia brány má vlastný prepínač pre privátne IP a jednotlivé pripojenie Site-to-Site má druhý, ktorý tomuto pripojeniu prikazuje použiť privátnu adresu. Nastaviť jedno a nie druhé je najčastejšia neúplná konfigurácia; tunel sa buď neustaví, alebo sa ustaví na nesprávny 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}'

Overte názvy vlastností voči nainštalovanej verzii CLI, pretože označenia portálu a vlastnosti CLI nemajú vždy rovnakú formuláciu. Aktívno-aktívna brána vystavuje dve privátne adresy tunela a lokálne zariadenie potrebuje nakonfigurované oba partnery, ak má táto redundancia niečo znamenať. BGP nie je potrebné len na zdvihnutie tohto tunela s privátnou adresou, hoci zvyčajne je súčasťou spôsobu distribúcie prefixov.

Druhý mýtus: ustanovený tunel šifruje vašu prevádzku

K sieti aplikácie teraz vedú dve cesty: priama cesta privátneho peeringu a cesta cez VPN. Obe fungujú. Iba jedna uplatňuje túto vrstvu IPsec. Microsoft dokumentuje, že keď sa identické prefixy inzerujú cez ExpressRoute aj cez VPN, Azure uprednostní priamu cestu ExpressRoute, takže zdravý tunel so zdravými počítadlami nič nedokazuje o tom, kam išli pakety aplikácie.

Zdokumentované metódy riadenia sú pokrývajúci rozsah na ExpressRoute a konkrétnejší chránený rozsah na VPN, alebo disjunktné prefixy na oboch cestách. Napríklad privátny peering môže niesť 10.40.0.0/16, zatiaľ čo VPN inzeruje 10.40.12.0/24. Konkrétnejší prefix vyhrá a zvyšok rozsahu zostane priamy.

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

Rovnakú kontrolu urobte v lokálnom smere, pretože preferencia vášho routera rozhoduje o tom, kadiaľ odchádza odchádzajúca prevádzka. A vlastný transport tunela držte na ceste ExpressRoute; trasa, ktorá vtiahne privátny koncový bod brány do tunela, urobí tunel závislým od seba samého.

Rozhodnite, čo sa stane, keď tunel spadne

Konkrétnejšia trasa VPN zmizne, keď tunel spadne, zatiaľ čo širšia priama trasa zostane. Prevádzka potom tečie nešifrovane a všetko vyzerá zdravo, čo je najhorší režim zlyhania pre požiadavku, ktorá existuje, aby zaručila šifrovanie. Ak požiadavka tento návrat zakazuje, smerovanie a prístupová politika to musia povedať výslovne namiesto spoliehania sa na dostupnosť tunela.

Zapíšte, ktoré prefixy môžu zostať priamo dostupné a ktoré sa musia zastaviť, keď šifrovaná cesta chýba. Potom otestujte povolený prípad skutočnou prevádzkou a porovnajte počítadlá pripojenia, pretože samotná smerovacia tabuľka vám nepovie, či požiadavka na šifrovanie stále platí.

Tento rámec vám tiež umožní hodnotiť NVA podľa jeho skutočných funkcií, ako sú viaceré tunely, priepustnosť alebo inšpekcia dodávateľa, namiesto kúpy preto, že koncový bod je privátny.