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 на spoke мрежата разрешава транзит през шлюза, а spoke мрежата трябва да разрешава препратения трафик. Това са свойства на 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 за една стара услуга и таблица на маршрутите, която тихо предпочита едно от двете.