Azure peering ці VPN VNet–VNet? Вызначцеся да маршрутызацыі

Azure дае вам як мінімум два спосабы злучыць дзве віртуальныя сеткі, і гэта не ўзаемазаменныя налады на адным аб'екце. Peering злучае VNet у магістралі Microsoft без шлюза; VPN VNet–VNet стварае адносіны IPsec паміж двума шлюзамі, якія вы разгортваеце, падбіраеце па памеры і маніторыце. Рашэнне зводзіцца да трох умоў, і калі вы не можаце адказаць на ўсе тры да таго, як дадасце маршрут, вы збіраецеся пабудаваць абыход для мадэлі, якую ніколі не выбіралі.

Тры ўмовы, якія вызначаюць мадэль

Першая — ці патрабуе нешта ў патрабаванні мяжы IPsec, якой валодаеце вы і на якую можаце паказаць. Другая — ці чыстыя адрасныя прасторы і ці трэба дзвюм VNet мець зносіны толькі адна з адной. Трэцяя — хто валодае любым транзітным шляхам і хто плаціць за шлюз. Адказвайце ў гэтым парадку, бо першая можа выключыць peering, як бы прывабна ні выглядала другая.

Агульнае для абедзвюх мадэляў — жорсткае правіла адрасацыі: адрасныя прасторы VNet не павінны перакрывацца. Ні peering, ні VPN VNet–VNet не з'яўляецца падтрыманым спосабам зрабіць два аднолькавыя дыяпазоны адназначнымі, і перакрыццё патрабуе схемы адлюстравання або перапраектавання, а не іншага тыпу злучэння.

Умова 1: ці патрэбна вам мяжа IPsec, якой вы валодаеце?

Peering пераносіць трафік па прыватнай магістралі Azure і не патрабуе шлюза VPN для самога peered-злучэння. Гэта сцвярджэнне пра транспарт, а не пра шыфраванне, якое можна прад'явіць аўдытару як «мы выкарыстоўваем IPsec». Калі патрабаванне называе тунэль, наладжаны кліентам, пэўную палітыку IKE або мяжу, якая сканчаецца на абсталяванні пад вашым кантролем, peering гэтага не задавальняе, якой бы прыватнай ні была магістраль.

VPN VNet–VNet такую мяжу забяспечвае: два шлюзы, адносіны IPsec/IKE, агульныя ключы і ўся аперацыйная паверхня, што з гэтым ідзе. Вы атрымліваеце стан тунэля, ёмістасць шлюза, абмежаванні SKU і маніторынг, які даказвае, што тунэль працуе. Гэта правільны адказ, калі патрабаванне тычыцца менавіта гэтай мяжы, апісанай у аглядзе peering як асобны тып злучэння.

Будзьце гэтак жа асцярожныя ў іншы бок. «Нам патрэбна шыфраванне паміж VNet» часта задавальняецца ўласным TLS нагрузкі, і тады шлюз — гэта выдатак без патрабавання за ім. Напішыце сказ, які прачытае аўдытар, перш чым выбіраць механізм.

Умова 2: тапалогія прамая ці нешта павінна транзітаваць?

Peering не транзітыўны. Дзве VNet, peered да цэнтра, не становяцца ад гэтага злучанымі адна з адной, і маршрут, які выглядае працоўным у адным кірунку, звычайна ёсць peering, што дасягнуў Connected толькі з аднаго боку. Абодва бакі павінны існаваць і абодва паказваць Connected — гэта першае, што трэба праверыць, калі трафік ціха знікае.

Калі патрабаванне — дасяжнасць лакальнай сеткі праз цэнтр, транзіт шлюза ёсць асобным праектам з пэўнымі ролямі: цэнтр валодае шлюзам, peering філіяла дазваляе транзіт шлюза, а філіял павінен дазваляць перанакіраваны трафік. Гэта ўласцівасці peering, а не аўтаматычныя вынікі злучэння VNet:

az network vnet peering create -g hub-rg -n hub-to-spoke1   --vnet-name hub-vnet --remote-vnet /subscriptions/SUB/resourceGroups/spoke-rg/providers/Microsoft.Network/virtualNetworks/spoke1-vnet   --allow-vnet-access --allow-gateway-transit --allow-forwarded-traffic

az network vnet peering list -g hub-rg --vnet-name hub-vnet -o table
az network nic show-effective-route-table -g spoke-rg -n app-nic -o table

Эфектыўная табліца маршрутаў — сумленны адказ на «ці існуе шлях?». Яна паказвае тып наступнага пераходу, які платформа рэальна выкарыстае, таму peering, што выглядае наладжаным, але не злучаны, паказваецца як адсутны або няправільны маршрут, а не як загадка.

Умова 3: хто валодае транзітным шляхам і рахункам?

Кожны дадатковы пераход мае ўладальніка. Пры peering новая VNet азначае новую пару peering з абодвух бакоў, а для транзіту — цэнтр, які працягвае перасылаць трафік, і табліцу маршрутаў, якая працягвае на яго паказваць. Пры VPN новая VNet азначае яшчэ адзін шлюз або яшчэ адно злучэнне на існуючым, з уласнай столлю ёмістасці, за якой трэба сачыць.

Кошт ідзе па той жа форме, але не па тых жа артыкулах: плацяжы peering — гэта злучэнне і перадача даных, а VPN дадае гадзіны шлюза і ўласныя плацяжы за перадачу. Параўноўвайце суму для тапалогіі, якую вы рэальна будзеце трымаць год, уключаючы другі тунэль і маніторынг, а не цану аднаго злучэння сёння. Уключыце працу, якую ніхто не фактуруе: хтосьці мусіць круціць ключы, сачыць за станам тунэля і адказваць на сігнал у тры гадзіны ночы, калі шлюз перазапускаецца. Звычайна менавіта гэты артыкул вырашае спрэчку, бо ён адзіны, які ніколі не з'яўляецца ў камерцыйнай прапанове.

Што б вы ні выбралі, праверце тры патоку: намечаны, адхілены, які павінен застацца адхіленым, і выпадак аднаўлення, калі шлюз цэнтра або peering не працуе. Мадэль, якая тлумачыць толькі шчаслівы шлях, не праверана — яе прадэманстравалі.

Праверце выбар супраць яго ўласнага сцвярджэння

Напішыце адзін сказ, які называе мадэль, мяжу і ўладальніка, затым праверце, што разгорнуты стан яму адпавядае. Для peering гэта значыць абодва станы Connected, эфектыўны маршрут з наступным пераходам peering для прэфікса прызначэння і без шлюза на шляху. Для VPN VNet–VNet гэта значыць абодва злучэнні Connected, адпаведныя ключы і палітыкі на абодвух шлюзах і маршрут, наступны пераход якога — шлюз віртуальнай сеткі.

Калі праверкі супярэчаць сказу, спачатку выпраўце сказ. Большасць блытаніны ў гэтых праектах паходзіць з гібрыда, якога ніхто не апісаў: peering для падсеткі нагрузкі, VPN для адной старой службы і табліца маршрутаў, якая ціха аддае перавагу аднаму з іх.