Peering в Azure чи VPN між VNet? Вирішіть до маршрутизації

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

Три умови, що визначають модель

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

Спільне для обох моделей — жорстке правило адресації: адресні простори VNet не повинні перетинатися. Ні peering, ні VPN між VNet не є підтримуваним способом зробити два однакові діапазони однозначними, а перетин потребує схеми відображення або перепроєктування, а не іншого типу з'єднання.

Умова 1: чи потрібна вам межа IPsec, якою володієте ви?

Peering передає трафік приватною магістраллю Azure і не потребує VPN-шлюзу для самого peered-з'єднання. Це твердження про транспорт, а не твердження про шифрування, яке можна передати аудитору як «ми використовуємо IPsec». Якщо вимога називає тунель, налаштований клієнтом, конкретну політику IKE або межу, що закінчується на обладнанні під вашим контролем, peering цього не виконує, хоч би якою приватною була магістраль.

VPN між VNet таку межу дає: два шлюзи, відношення IPsec/IKE, спільні ключі й уся операційна поверхня, що з цим іде. Ви успадковуєте стан тунелю, ємність шлюзу, обмеження SKU і моніторинг, який доводить, що тунель працює. Це правильна відповідь, коли вимога стосується саме цієї межі, описаної в огляді peering як окремий тип з'єднання.

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

Умова 2: топологія пряма чи чомусь треба транзитувати?

Peering не транзитивний. Дві VNet, з'єднані peering з концентратором, не стають від цього пов'язаними одна з одною, і маршрут, що виглядає працездатним в один бік, зазвичай є 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 це означає обидва стани peering у Connected, чинний маршрут показує наступний перехід peering для префікса призначення, і на шляху немає шлюзу. Для VPN між VNet це означає обидва з'єднання в Connected, збіжні ключі та політики на обох шлюзах і маршрут, наступний перехід якого — шлюз віртуальної мережі.

Якщо перевірки суперечать реченню, спершу виправте речення. Більшість плутанини в цих проєктах походить із гібрида, якого ніхто не описав: peering для підмережі робочого навантаження, VPN для однієї старої служби й таблиця маршрутів, що тихо віддає перевагу одному з них.