Azure privata IP VPN sur ExpressRoute sen NVA

La mito estas ke ĉifrado de trafiko super la privata peering de ExpressRoute postulas virtualan retan aparaton. Ĝi ne postulas. Azure subtenas Site-to-Site VPN Gateway kies tunela finpunkto estas privata RFC1918-adreso portata tra la cirkvito, kaj la aparato estas laŭvola, ne struktura. Kion la aparato-mito kaŝas estas la parto kiu vere mordas: ŝalti la privatan finpunkton sur unu objekto anstataŭ du, kaj lasi rektan peering-itinero silente venki super la ĉifrita vojo.

De kie venis la mito

La aserto havas respekteblan devenon. Dum jaroj la praktika recepto por IPsec super privata peering estis NVA, ĉar la administrata pordego elmetis nur publikajn finpunktojn. Tio ŝanĝiĝis, kaj respondoj skribitaj antaŭ la ŝanĝo ankoraŭ estas citataj en fadenoj kie neniu kontrolas la daton. La korekto estas mallarĝa: privata-adresa VPN-pordego ekzistas, kaj ĝi ŝanĝas la finpunkton, ne la enkursigan logikon ĉirkaŭ ĝi.

Nenio el tio emeritigas la NVA-on. Ĝi emeritigas la supozon ke aparato estas la sola vojo al la postulo.

Ŝaltu la privatan finpunkton je ambaŭ niveloj

Komencu de funkcianta ExpressRoute privata-peeringa konekto ligita al la VNet kiu enhavas la VPN-pordegon. La surloka flanko jam devas atingi la koncernajn privatajn adresojn tra tiu cirkvito, ĉar la tunelo uzos tiujn adresojn kiel transporton. Poste la pordega antaŭkondiĉo: la Microsoft-proceduro por privata-IP VPN postulas pordegon konstruita sur Standard publika IP-rimedo. Privata tunela adresado ne forigas tiun postulon, kio surprizas homojn kiuj supozas ke „privata“ signifas „neniu publika IP ie ajn“.

Nun ŝaltu la flagon en ambaŭ lokoj. La pordega agordo havas sian propran ŝaltilon por privataj IP-oj, kaj la unuopa Site-to-Site-konekto havas duan kiu igas tiun konekton uzi la privatan adreson. Ŝalti unu sed ne la alian estas la plej ofta nekompleta agordo; la tunelo aŭ ne ekestas aŭ ekestas al la malĝusta finpunkto.

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

Kontrolu la propraĵajn nomojn kontraŭ la instalita CLI-versio, ĉar portalaj etikedoj kaj CLI-proprajĵoj ne ĉiam havas la saman vortigon. Aktiva-aktiva pordego elmetas du privatajn tunelajn adresojn, kaj la surloka aparato bezonas ambaŭ kunulojn agorditaj se vi volas ke tiu redundo signifu ion. BGP ne necesas simple por starigi ĉi tiun privatan-adresan tunelon, kvankam ĝi kutime estas parto de kiel vi distribuas prefiksojn.

La dua mito: establita tunelo ĉifras vian trafikon

Du vojoj nun atingas la aplikaĵan reton: la rekta privata-peeringa vojo kaj la vojo tra la VPN. Ambaŭ funkcias. Nur unu aplikas ĉi tiun IPsec-tavolon. Microsoft dokumentas ke kiam identaj prefiksoj estas anoncataj super ExpressRoute kaj super la VPN, Azure preferas la rektan ExpressRoute-vojon, do sana tunelo kun sanaj nombriloj pruvas nenion pri tio kien iris la aplikaĵaj pakoj.

La dokumentitaj direktadaj metodoj estas kovranta gamo sur ExpressRoute kun pli specifa protektita gamo sur la VPN, aŭ disaj prefiksoj sur la du vojoj. Ekzemple, privata peering povus porti 10.40.0.0/16 dum la VPN anoncas 10.40.12.0/24. La pli specifa prefikso venkas kaj la resto de la gamo restas rekta.

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

Faru la saman kontrolon en la surloka direkto, ĉar la prefero de via enkursigilo decidas kien eliras la elira trafiko. Kaj tenu la propran transporton de la tunelo sur la ExpressRoute-vojo; itinero kiu tiras la privatan finpunkton de la pordego en la tunelon igas la tunelon dependa de si mem.

Decidu kio okazas kiam la tunelo falas

Pli specifa VPN-itinero malaperas kiam la tunelo falas, dum la pli larĝa rekta itinero restas. Trafiko tiam fluas neĉifrite kaj ĉio aspektas sana, kio estas la plej malbona fiaska reĝimo por postulo kiu ekzistas por garantii ĉifradon. Se la postulo malpermesas tiun retiriĝon, la enkursigado kaj la alirpolitiko devas diri tion eksplicite anstataŭ fidi la haveblecon de la tunelo.

Notu kiuj prefiksoj rajtas resti rekte atingeblaj kaj kiuj devas halti kiam la ĉifrita vojo forestas. Poste testu la permesitan kazon per reala trafiko kaj komparu la konektajn nombrilojn, ĉar la itinertabelo sola ne diros al vi ĉu la ĉifrada postulo ankoraŭ validas.

Tiu kadro ankaŭ lasas vin taksi NVA-on laŭ ĝiaj realaj trajtoj, kiel pluraj tuneloj, trairo aŭ vendista inspektado, anstataŭ aĉeti unu ĉar la finpunkto estas privata.