Нужен ли е собствен VPN шлюз на свързания Azure VNet?

Появява се нов spoke VNet, хъбът вече има работещ site-to-site шлюз и очевидният въпрос е дали трябва да плащате за втори шлюз. Обикновено не: транзитът през шлюз позволява на spoke мрежата да използва шлюза на хъба чрез peering. Три условия решават дали това ще работи и нито едно от тях не се вижда от значката за състояние на peering. Свързаността по peering и разрешението да използвате чужд шлюз са отделни настройки, така че две VM, които вече си отговарят на ping, не доказват нищо за VPN пътя.

Първо условие: шлюзът и липсата му в spoke мрежата

Azure поддържа транзит през шлюз за SKU на VPN Gateway, различни от Basic, и както регионалният, така и глобалният peering могат да го пренасят. Spoke мрежата използва шлюз, който не притежава, затова не може да има свой собствен: ако в spoke мрежата вече има шлюз или опцията за отдалечен шлюз вече е избрана, настройката за транзит, която искате, ще бъде недостъпна или неефективна. Проверете това, преди да започнете отстраняване на неизправности, защото неактивната отметка е симптом, а не повреда. Първо прочетете SKU и съществуващия шлюз, след което погледнете настройките на peering.

Не изтривайте съществуващ шлюз на spoke мрежата, за да се появи опцията, докато не разберете какво зависи от него. Редът на миграция е по-важен от отметката.

Второ условие: една настройка във всяка посока на peering

Peering са два обекта, по един на всеки VNet, а настройките за транзит живеят от различните страни на тази двойка. Peering на хъба към spoke мрежата трябва да позволява на шлюза на хъба да обслужва spoke мрежата; peering на spoke мрежата към хъба трябва да приема шлюза на хъба. Ръководството на Microsoft за транзит през шлюз ги именува по посока, а това е единственият начин да ги поддържате правилни:

Контрола с етикет remote променя значението си в зависимост от това чий peering редактирате, затова четете посоката, а не думата. Задайте двете страни, запазете и потвърдете, че peering се отчита като свързан и на двете места.

Трето условие: адресно пространство и граници на разрешенията

Транзитът не може да накара един и същ префикс на местоназначение да означава две мрежи, затова диапазоните на хъба, spoke мрежата и локалната мрежа трябва да не се застъпват, преди нещо от това да работи. VNet мрежите може също да са в различни абонаменти или различни наематели; това не е забрана, но идентичността, която създава или обновява всеки peering, се нуждае от необходимите разрешения за тази мрежа. Промените между абонаменти често се провалят заради разрешения и грешката лесно се разчита като проблем с топологията.

Запишете диапазоните и собствениците преди промяната. Гадаенето за което и да е от двете създава peering, който се свързва и не маршрутизира нищо.

Проверявайте с ефективни маршрути, а не със статус на peering

Погледнете ефективните маршрути на мрежовия интерфейс на работно натоварване в spoke мрежата и намерете действителния префикс на локалната мрежа. Проверете таблицата с маршрути на подмрежата и дали разпространението на маршрути през шлюз е изключено, защото дефиниран от потребителя маршрут или устройство за инспекция може да пренасочи пътя, който предполагат флаговете на peering. След това потвърдете обратната посока: локалната мрежа трябва да знае как да достигне префикса на spoke мрежата през site-to-site връзката, било чрез научени анонси, било чрез явен маршрут и съответстващ запис за защитена мрежа на устройството на клиента. Ако префиксът липсва от която и да е страна, флаговете на peering не са това, което трябва да се промени.

Тествайте една услуга от работно натоварване в spoke мрежата и проследете отговора. Тест от VPN шлюза или от VM в хъба използва различен изходен префикс и различен път.

Ако топологията обслужва и point-to-site клиенти, проверете инсталираните им маршрути отделно. Пакетите на Windows клиента може да се нуждаят от повторно генериране след промяна на топологията, и това е задача за клиентско маршрутизиране, а не доказателство, че споделянето на шлюз се е провалило.

Какво не дава споделянето на шлюз

Транзитът през шлюз е удобство за маршрутизиране, а не оторизация. Групите за мрежова сигурност, локалните филтри и правилата на ниво услуга все още решават до какво може да достигне работно натоварване в spoke мрежата, затова включете конкретната услуга от източник към местоназначение, вместо да предполагате, че споделеният тунел позволява всичко зад него.

Peering също не е транзитивен по начина, на който хората се надяват. Добавянето на още един spoke или на частна крайна точка въвежда собствени изисквания за маршрутизиране и достъп, които текущата настройка за транзит не покрива.