Azure pribadong IP VPN sa ExpressRoute nang walang NVA

Ang mito ay ang pag-encrypt ng trapiko sa pribadong peering ng ExpressRoute ay nangangailangan ng virtual network appliance. Hindi. Sinusuportahan ng Azure ang isang Site-to-Site VPN Gateway na ang dulo ng tunnel ay isang pribadong RFC1918 address na dinadala sa circuit, at ang appliance ay opsyonal, hindi structural. Ang itinatago ng mito ng appliance ay ang bahaging talagang masakit: paganahin ang pribadong dulo sa isang bagay sa halip na dalawa, at hayaan ang direktang peering route na tahimik na manalo sa naka-encrypt na landas.

Saan galing ang mito

Ang pahayag ay may kagalang-galang na pinagmulan. Sa loob ng maraming taon, ang praktikal na recipe para sa IPsec sa pribadong peering ay isang NVA, dahil ang pinamamahalaang gateway ay naglalantad lamang ng mga pampublikong dulo. Nagbago iyon, at ang mga sagot na isinulat bago ang pagbabago ay sinipi pa rin sa mga thread kung saan walang nagsusuri ng petsa. Ang pagwawasto ay makitid: mayroong VPN gateway na may pribadong address, at binabago nito ang dulo, hindi ang routing logic sa paligid nito.

Wala sa mga ito ang nagreretiro sa NVA. Ang nagreretiro ay ang palagay na ang appliance ay ang tanging daan patungo sa pangangailangan.

Paganahin ang pribadong dulo sa dalawang antas

Magsimula sa gumaganang ExpressRoute pribadong peering connection na naka-link sa VNet na naglalaman ng VPN gateway. Ang on-premises na bahagi ay dapat na maabot na ang mga kaugnay na pribadong address sa circuit na iyon, dahil gagamitin ng tunnel ang mga address na iyon bilang transport. Pagkatapos ang paunang kondisyon ng gateway: ang pamamaraan ng Microsoft para sa pribadong-IP VPN ay nangangailangan ng gateway na itinayo sa Standard pampublikong IP resource. Hindi inaalis ng pribadong tunnel addressing ang kondisyong iyon, na ikinagulat ng mga nag-aakalang «pribado» ay nangangahulugang «walang pampublikong IP kahit saan».

Ngayon paganahin ang flag sa parehong lugar. Ang configuration ng gateway ay may sariling switch para sa mga pribadong IP, at ang indibidwal na Site-to-Site connection ay may pangalawa na nagpapa-usok sa koneksyong iyon na gamitin ang pribadong address. Ang pagtatakda ng isa at hindi ang isa pa ang pinakakaraniwang hindi kumpletong configuration; ang tunnel ay alinman sa hindi nabubuo o nabubuo sa maling dulo.

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

Kumpirmahin ang mga pangalan ng property laban sa naka-install na bersyon ng CLI, dahil ang mga label ng portal at property ng CLI ay hindi laging pareho ng pananalita. Ang aktibo-aktibong gateway ay naglalantad ng dalawang pribadong address ng tunnel, at ang on-premises na device ay kailangang may nakakonfigurang dalawang peer kung nais mong may kahulugan ang redundancy na iyon. Ang BGP ay hindi kailangan para lamang itaas ang pribadong address na tunnel na ito, bagaman karaniwan itong bahagi ng paraan ng pamamahagi mo ng mga prefix.

Ang ikalawang mito: ang naitatag na tunnel ay nag-encrypt ng iyong trapiko

Dalawang landas ang umaabot ngayon sa application network: ang direktang pribadong peering na landas at ang landas sa pamamagitan ng VPN. Pareho silang gumagana. Isa lamang ang naglalapat ng IPsec layer na ito. Idinodokumento ng Microsoft na kapag ang magkatulad na prefix ay inaanunsyo sa ExpressRoute at sa VPN, mas pinipili ng Azure ang direktang ExpressRoute na landas, kaya ang malusog na tunnel na may malusog na counter ay walang pinatutunayan tungkol sa kung saan napunta ang mga packet ng application.

Ang mga dokumentadong paraan ng pag-steer ay isang sumasaklaw na hanay sa ExpressRoute na may mas tiyak na protektadong hanay sa VPN, o magkahiwalay na prefix sa dalawang landas. Halimbawa, maaaring magdala ang pribadong peering ng 10.40.0.0/16 habang inaanunsyo ng VPN ang 10.40.12.0/24. Ang mas tiyak na prefix ang nananalo at ang natitirang bahagi ng hanay ay nananatiling direkta.

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

Gawin ang parehong pagsusuri sa direksyon ng on-premises, dahil ang kagustuhan ng iyong router ang nagtatakda kung saang panig lumalabas ang papaalis na trapiko. At panatilihin ang sariling transport ng tunnel sa landas ng ExpressRoute; ang rutang humihila sa pribadong dulo ng gateway papasok sa tunnel ay ginagawang umaasa sa sarili ang tunnel.

Magpasya kung ano ang mangyayari kapag bumagsak ang tunnel

Ang mas tiyak na ruta ng VPN ay nawawala kapag bumagsak ang tunnel, habang ang mas malawak na direktang ruta ay nananatili. Ang trapiko ay dumadaloy nang walang encryption at mukhang malusog ang lahat, na siyang pinakamasamang failure mode para sa pangangailangang umiiral upang magarantiya ang encryption. Kung ipinagbabawal ng pangangailangan ang fallback na iyon, dapat sabihin ito ng routing at access policy nang tahasan sa halip na umasa sa availability ng tunnel.

Isulat kung aling mga prefix ang maaaring manatiling direktang maabot at alin ang dapat huminto kapag wala ang naka-encrypt na landas. Pagkatapos ay subukan ang pinapayagang kaso gamit ang tunay na trapiko at ihambing ang mga counter ng koneksyon, dahil ang talahanayan ng ruta lamang ay hindi magsasabi sa iyo kung may bisa pa ang pangangailangan sa encryption.

Ang balangkas na iyon ay nagpapahintulot din sa iyo na suriin ang isang NVA batay sa mga tunay na tampok nito, tulad ng maraming tunnel, throughput o inspeksyon ng vendor, sa halip na bumili ng isa dahil pribado ang dulo.