Да ли је Azure VNet повезан peering-ом потребна сопствена VPN капија?

Појављује се нови spoke VNet, hub већ има радну site-to-site капију, а очигледно питање је да ли морате да платите другу капију. Обично не: транзит капије омогућава spoke-у да преко peering-а користи капију hub-а. Три услова одлучују да ли ће то радити, а ниједан се не види на значки статуса peering-а. Повезаност peering-а и дозвола за коришћење туђе капије су одвојена подешавања, па два VM-а која већ могу да пингују један други не доказују ништа о VPN путу.

Први услов: капија и њено одсуство у spoke-у

Azure подржава транзит капије за SKU-ове VPN Gateway осим Basic, а носе га и регионални и глобални peering. Spoke троши капију коју не поседује, па не може имати своју: ако у spoke-у већ постоји капија или је већ изабрана опција удаљене капије, подешавање транзита које желите биће недоступно или неефикасно. Проверите то пре него што било шта отклањате, јер онемогућено поље за потврду је симптом, а не квар. Прво прочитајте SKU и постојећу капију, па погледајте подешавања peering-а.

Не бришите постојећу spoke капију да би се опција појавила док не сазнате шта од ње зависи. Редослед миграције је важнији од поља за потврду.

Други услов: једно подешавање у сваком смеру peering-а

Peering су два објекта, по један на сваком VNet-у, а подешавања транзита живе на различитим странама тог пара. Peering hub-а према spoke-у мора да дозволи капији hub-а да опслужује spoke; peering spoke-а према hub-у мора да прихвати капију hub-а. Microsoft-ов водич за транзит капије их именује по смеру, и то је једини начин да их одржите исправним:

Контрола означена са remote мења значење у зависности од тога чији peering уређујете, зато читајте смер, а не реч. Подесите обе стране, сачувајте и потврдите да peering пријављује повезаност на оба места.

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

Транзит не може да учини да исти префикс одредишта значи две мреже, па се опсези hub-а, spoke-а и локалне мреже морају разликовати пре него што било шта од овога проради. VNet-ови могу бити и у различитим претплатама или различитим закупцима; то није забрана, али идентитет који ствара или ажурира сваки peering треба потребне дозволе на тој мрежи. Промене између претплата често падају на дозволама, а грешку је лако погрешно прочитати као проблем топологије.

Запишите опсеге и власнике пре промене. Погађање било чега од тога даје peering који се повезује и ништа не усмерава.

Проверавајте ефективним рутама, а не статусом peering-а

Погледајте ефективне руте на мрежном интерфејсу spoke радног оптерећења и пронађите стварни префикс локалне мреже. Проверите табелу рута подмреже и да ли је пропагација рута капије онемогућена, јер кориснички дефинисана рута или уређај за инспекцију може да надјача пут који сугеришу заставице peering-а. Затим потврдите супротан смер: локална мрежа мора да зна како да дође до spoke префикса преко site-to-site везе, било наученим објавама било експлицитном рутом и одговарајућим уносом заштићене мреже на корисничком уређају. Ако префикс недостаје на било којој страни, заставице peering-а нису оно што треба мењати.

Тестирајте једну услугу са spoke радног оптерећења и пратите одговор. Тест са VPN капије или са hub VM-а користи другачији изворни префикс и другачији пут.

Ако топологија опслужује и point-to-site клијенте, засебно проверите њихове инсталиране руте. Windows клијентски пакети могу захтевати поновно генерисање након промене топологије, а то је задатак клијентског усмеравања, а не доказ да је дељење капије пропало.

Шта дељење капије не даје

Транзит капије је погодност усмеравања, а не ауторизација. Мрежне сигурносне групе, локални филтери и правила на нивоу услуге и даље одлучују до чега spoke радно оптерећење може да дође, па омогућите конкретну услугу од извора до одредишта уместо да претпоставите да заједнички тунел дозвољава све иза њега.

Peering такође није транзитиван онако како људи прижељкују. Додавање још једног spoke-а или приватне крајње тачке уводи сопствене захтеве за усмеравањем и приступом које тренутно подешавање транзита не покрива.