Azure privatni IP VPN preko ExpressRoute bez NVA
Azure VPN Gateway može završiti IPsec na privatnoj adresi preko ExpressRoute. Uključite oba flaga, a zatim spriječite da izravne peering rute zaobiđu tunel.
Mit je da šifriranje saobraćaja preko ExpressRoute privatnog peeringa zahtijeva mrežni virtuelni uređaj. Ne zahtijeva. Azure podržava Site-to-Site VPN Gateway čija je krajnja tačka tunela privatna RFC1918 adresa koja se prenosi preko kola, a uređaj je opcionalan, a ne strukturalan. Ono što mit o uređaju skriva jeste dio koji zaista peče: uključivanje privatne krajnje tačke na jednom objektu umjesto na dva i to što direktna peering ruta tiho pobjeđuje šifriranu putanju.
Odakle mit dolazi
Tvrdnja ima ugledno porijeklo. Godinama je praktični recept za IPsec preko privatnog peeringa bio NVA, jer je upravljani gateway izlagao samo javne krajnje tačke. To se promijenilo, a odgovori napisani prije promjene još se citiraju u nitima gdje niko ne provjerava datum. Ispravka je uska: VPN gateway s privatnom adresom postoji i on mijenja krajnju tačku, ne logiku rutiranja oko nje.
Ništa od ovoga ne penzioniše NVA. Ono penzioniše pretpostavku da je uređaj jedini put do zahtjeva.
Uključite privatnu krajnju tačku na oba nivoa
Pođite od radne ExpressRoute privatne peering veze povezane s VNetom u kojoj je VPN gateway. Lokalna strana već mora dosezati relevantne privatne adrese preko tog kola, jer će tunel koristiti te adrese kao transport. Zatim preduvjet gatewaya: Microsoftova procedura za VPN s privatnim IP-om zahtijeva gateway izgrađen na Standard javnom IP resursu. Privatno adresiranje tunela ne uklanja taj uvjet, što iznenađuje ljude koji pretpostavljaju da „privatno“ znači „nema javnog IP-a nigdje“.
Sada uključite flag na oba mjesta. Konfiguracija gatewaya ima svoj prekidač za privatne IP-ove, a pojedinačna Site-to-Site veza ima drugi koji tu vezu tjera da koristi privatnu adresu. Postavljanje jednog bez drugog najčešća je nepotpuna konfiguracija; tunel se ili ne uspostavlja ili se uspostavlja na pogrešnu krajnju tačku.
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}'
Provjerite nazive svojstava prema instaliranoj verziji CLI-ja, jer se oznake portala i CLI svojstva ne slažu uvijek u formulaciji. Aktivno-aktivni gateway izlaže dvije privatne adrese tunela, a lokalni uređaj mora imati konfigurirana oba peera ako želite da ta redundantnost nešto znači. BGP nije potreban samo za podizanje ovog tunela s privatnom adresom, iako je obično dio načina na koji distribuirate prefikse.
Drugi mit: uspostavljen tunel šifrira vaš saobraćaj
Dvije putanje sada dosežu aplikacijsku mrežu: direktna privatna peering putanja i putanja kroz VPN. Obje rade. Samo jedna primjenjuje ovaj IPsec sloj. Microsoft dokumentuje da kada se identični prefiksi oglašavaju preko ExpressRoute i preko VPN-a, Azure preferira direktnu ExpressRoute putanju, pa zdrav tunel sa zdravim brojačima ne dokazuje ništa o tome kuda su otišli aplikacijski paketi.
Dokumentovane metode usmjeravanja su pokrivajući raspon na ExpressRoute s konkretnijim zaštićenim rasponom na VPN-u, ili disjunktni prefiksi na dvije putanje. Za ilustraciju, privatni peering može nositi 10.40.0.0/16 dok VPN oglašava 10.40.12.0/24. Konkretniji prefiks pobjeđuje i ostatak raspona ostaje direktan.
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
Uradite istu provjeru u lokalnom smjeru, jer preferencija vašeg rutera odlučuje kojim putem izlazi izlazni saobraćaj. I držite vlastiti transport tunela na ExpressRoute putanji; ruta koja uvlači privatnu krajnju tačku gatewaya u tunel čini tunel ovisnim o samom sebi.
Odredite šta se dešava kada tunel padne
Konkretnija VPN ruta nestaje kada tunel padne, dok šira direktna ruta ostaje. Saobraćaj tada teče nešifriran i sve izgleda zdravo, što je najgori način otkaza za zahtjev koji postoji da garantuje šifriranje. Ako zahtjev zabranjuje taj fallback, rutiranje i pravila pristupa moraju to izričito reći umjesto oslanjanja na dostupnost tunela.
Zapišite koji prefiksi smiju ostati direktno dostupni, a koji moraju stati kada šifrirane putanje nema. Zatim testirajte dozvoljeni slučaj stvarnim saobraćajem i uporedite brojače veze, jer sama tabela ruta neće vam reći da li zahtjev za šifriranjem još vrijedi.
Taj okvir vam takođe omogućava da NVA ocijenite po njegovim stvarnim funkcijama, kao što su više tunela, propusnost ili inspekcija dobavljača, umjesto da ga kupite zato što je krajnja tačka privatna.