Ці патрэбны злучанаму Azure VNet уласны VPN-шлюз?
Злучаны VNet можа выкарыстоўваць VPN-шлюз цэнтральнага вузла з падтрымліваным SKU і адным параметрам у кожным кірунку злучэння. Правярайце эфектыўныя маршруты, а не стан злучэння.
З'яўляецца новы дачэрні VNet, у цэнтральным вузле ўжо ёсць працоўны шлюз site-to-site, і відавочнае пытанне — ці давядзецца плаціць за другі шлюз. Звычайна не: транзіт шлюза дазваляе дачэрняму VNet выкарыстоўваць шлюз цэнтральнага вузла праз злучэнне. Тры ўмовы вырашаюць, ці будзе гэта працаваць, і ні адну з іх не відаць у значку стану злучэння. Злучанасць і дазвол на выкарыстанне чужога шлюза — асобныя параметры, таму два VM, якія ўжо пінгуюць адно аднаго, нічога не даказваюць пра шлях VPN.
Першая ўмова: шлюз і яго адсутнасць у дачэрнім VNet
Azure падтрымлівае транзіт шлюза для SKU VPN Gateway, акрамя Basic, і яго могуць забяспечваць як рэгіянальныя, так і глабальныя злучэнні. Дачэрні VNet спажывае шлюз, якім не валодае, таму не можа мець уласны: калі ў дачэрнім VNet ужо ёсць шлюз або ўжо выбрана опцыя выдаленага шлюза, патрэбны вам параметр транзіту будзе недаступны або неэфектыўны. Праверце гэта, перш чым што-небудзь адладжваць, бо неактыўны сцяжок — гэта сімптом, а не няспраўнасць. Спачатку прачытайце SKU і наяўны шлюз, а потым глядзіце на параметры злучэння.
Не выдаляйце наяўны шлюз дачэрняга VNet, каб з'явілася опцыя, пакуль не даведаецеся, што ад яго залежыць. Парадак міграцыі важнейшы за сцяжок.
Другая ўмова: адзін параметр у кожным кірунку злучэння
Злучэнне — гэта два аб'екты, па адным на кожным VNet, і параметры транзіту знаходзяцца на розных баках гэтай пары. Злучэнне цэнтральнага вузла ў бок дачэрняга павінна дазваляць шлюзу цэнтральнага вузла абслугоўваць дачэрні; злучэнне дачэрняга ў бок цэнтральнага павінна прымаць шлюз цэнтральнага вузла. Кіраўніцтва Microsoft па транзіце шлюза называе іх па кірунках, і гэта адзіны спосаб трымаць іх правільна:
| Peering direction | What to enable |
|---|---|
| Hub → spoke | Allow gateway transit on the hub's peering |
| Spoke → hub | Use remote gateways on the spoke's peering |
Элемент кіравання з пазнакай remote змяняе сэнс у залежнасці ад таго, злучэнне якога VNet вы рэдагуеце, таму чытайце кірунак, а не слова. Задайце абодва бакі, захавайце і пацвердзіце, што злучэнне паказваецца як злучанае ў абодвух месцах.
Трэцяя ўмова: адрасная прастора і межы дазволаў
Транзіт не можа прымусіць адзін і той жа прэфікс прызначэння азначаць дзве сеткі, таму дыяпазоны цэнтральнага вузла, дачэрняга і лакальнай сеткі павінны не перасякацца, перш чым хоць што-небудзь з гэтага запрацуе. VNet таксама могуць знаходзіцца ў розных падпісках або розных арэндадаўцах; гэта не забарона, але ідэнтычнасць, якая стварае або абнаўляе кожнае злучэнне, павінна мець патрэбныя дазволы на гэтай сетцы. Змены паміж падпіскамі часта не ўдаюцца праз дазволы, і памылку лёгка прачытаць як праблему тапалогіі.
Запішыце дыяпазоны і ўладальнікаў да змены. Здагадкі хоць бы ў адным даюць злучэнне, якое падключаецца і нічога не маршрутызуе.
Правярайце эфектыўнымі маршрутамі, а не станам злучэння
Паглядзіце на эфектыўныя маршруты на сеткавым інтэрфейсе працоўнай нагрузкі дачэрняга VNet і знайдзіце фактычны прэфікс лакальнай сеткі. Праверце табліцу маршрутаў падсеткі і тое, ці адключана распаўсюджванне маршрутаў шлюза, бо карыстальніцкі маршрут або прылада інспекцыі можа перакрыць шлях, які прапануюць сцяжкі злучэння. Затым пацвердзіце зваротны кірунак: лакальная сетка павінна ведаць, як дасягнуць прэфікса дачэрняга праз злучэнне site-to-site, ці то праз атрыманыя аб'явы, ці праз явны маршрут і адпаведны запіс абароненай сеткі на кліенцкай прыладзе. Калі прэфікс адсутнічае з любога боку, змяняць трэба не сцяжкі злучэння.
Праверце адну службу з працоўнай нагрузкі дачэрняга VNet і прасачыце за адказам. Тэст са шлюза VPN або з VM цэнтральнага вузла выкарыстоўвае іншы прэфікс крыніцы і іншы шлях.
Калі тапалогія таксама абслугоўвае кліентаў point-to-site, асобна праверце іх усталяваныя маршруты. Пакеты кліента Windows могуць спатрэбіцца перагенераваць пасля змены тапалогіі, і гэта задача маршрутызацыі кліента, а не доказ таго, што сумеснае выкарыстанне шлюза не ўдалося.
Што сумеснае выкарыстанне шлюза не дае
Транзіт шлюза — гэта зручнасць маршрутызацыі, а не аўтарызацыя. Групы бяспекі сеткі, лакальныя фільтры і правілы ўзроўню службы ўсё яшчэ вызначаюць, чаго можа дасягнуць працоўная нагрузка дачэрняга VNet, таму ўключыце канкрэтную службу ад крыніцы да прызначэння замест таго, каб меркаваць, што агульны тунель дазваляе ўсё за ім.
Злучэнне таксама не з'яўляецца транзітыўным так, як людзі спадзяюцца. Даданне яшчэ аднаго дачэрняга VNet або прыватнай канчатковай кропкі ўносіць свае патрабаванні да маршрутызацыі і доступу, якія бягучы параметр транзіту не пакрывае.