Чаму злучэнню пункт-сайт патрэбны шлюз Azure VPN на аснове маршрутызацыі

Шлюз на аснове палітыкі будуе тунель IPsec, які выбіраецца селектарамі трафіку, і не мае інтэрфейсу, каб перадаваць яму маршруты кліентаў. Злучэнне пункт-сайт — гэта функцыя маршрутызацыі: шлюз валодае пулам адрасоў кліентаў і ўсталёўвае маршруты да гэтых кліентаў у віртуальнай сетцы. Менавіта праз гэтую неадпаведнасць партал не паказвае опцыі дадаць яго. Нішто на існуючым шлюзе нельга пераключыць, каб стварыць інтэрфейс, таму змена — гэта замена, а не рэдагаванне канфігурацыі.

Парадак важнейшы за асобныя крокі. Памыліцеся з паслядоўнасцю — і прастой паміж сайтамі выйдзе за межы акна абслугоўвання.

Што насамрэч робіць шлюз на аснове палітыкі

Шлюз на аснове палітыкі супастаўляе пакеты з селектарамі трафіку, наладжанымі на злучэнні, і накіроўвае супадзенні ў адзін тунель. Тунельнага інтэрфейсу з адрасам няма, і нідзе ў віртуальнай сетцы не з’яўляецца маршрут для асобнага кліента. Табліца маршрутызацыі проста атрымлівае лакальныя прэфіксы, якія паказваюць на шлюз. Гэтай мадэлі дастаткова для злучэння паміж сайтамі з двума фіксаванымі адраснымі прасторамі.

Шлюз на аснове маршрутызацыі працуе наадварот: ён прадстаўляе тунельны інтэрфейс, і маршруты вырашаюць, што ў яго трапіць. Злучэнне пункт-сайт і любая архітэктура, дзе набор партнёраў змяняецца, залежаць ад існавання гэтага інтэрфейсу.

Чаму пулу кліентаў патрэбны гэты інтэрфейс

Калі ноўтбук падключаецца, шлюз прызначае яму адрас з пула пункт-сайт. Тады віртуальнай сетцы патрэбны маршрут, які кажа, што гэты адрас дасяжны праз шлюз. Без тунельнага інтэрфейсу няма да чаго прывязаць гэты маршрут.

Пул бярэцца з дыяпазону, які вы вызначаеце, і шлюз размеркаўвае з яго. Калі гэты дыяпазон перасякаецца з лакальнай сеткай або злучанай віртуальнай сеткай, канфлікт выявіцца толькі пасля падключэння кліента, а гэта дрэнны момант для выяўлення. Зарэзервуйце пул да пачатку міграцыі.

Тып таксама не з’яўляецца наладай для кожнага злучэння. У аднаго шлюза адзін тып, і кожнае злучэнне, якое ён трымае, паводзіць сябе адпаведна, таму змяшаная архітэктура патрабуе другога шлюза, а не другога злучэння.

Тып фіксуецца пры стварэнні

Microsoft заяўляе, што шлюз віртуальнай сеткі нельга змяніць паміж палітыкай і маршрутызацыяй пасля разгортвання. Няма ні каманды пераўтварэння, ні пераключальніка ў партале. Стварэнне другога шлюза ў той жа падсетцы таксама не абыход, бо Azure дазваляе адзін шлюз на віртуальную сетку. Таму міграцыя — гэта выдаліць, перабудаваць, падключыць зноў.

Гэта таксама ўключае рашэнне пра SKU у тую ж зборку. Пераход на большы SKU пазней — гэта яшчэ адна замена шлюза з яшчэ адным прастоем.

Адзін шлюз, адна GatewaySubnet

Шлюз жыве ў падсетцы з назвай GatewaySubnet, і толькі адзін шлюз займае яе. Вызначэнне памеру гэтай падсеткі ўваходзіць у падрыхтоўку, бо большаму SKU патрэбна больш адрасоў, а падсетку нельга паменшыць потым. Запішыце бягучыя налады злучэння паміж сайтамі, агульны ключ, шлюз лакальнай сеткі і эфектыўныя маршруты, перш чым нешта чапаць. Затым разглядайце акно як прастой, бо тунель паміж сайтамі застаецца выключаным, пакуль не будзе наладжана новае злучэнне.

Парадак перабудовы, які абмяжоўвае прастой: стварыце шлюз на аснове маршрутызацыі, аднавіце злучэнне паміж сайтамі да таго ж шлюза лакальнай сеткі, пацвердзіце тунель і адзін запыт паміж хастамі, і толькі пасля гэтага дадайце пункт-сайт і згенеруйце новы кліенцкі пакет.

Што замена не выпраўляе

Другое абмежаванне належыць партнёру, а не Azure. Лакальная прылада на аснове палітыкі можа дасягнуць толькі той віртуальнай сеткі, да якой падключана, і не можа транзітам дасягаць іншых лакальных сетак або іншых віртуальных сетак праз той жа шлюз. Замена боку Azure не змяняе таго, што партнёр можа выбраць.

Калі патрабаванне сапраўды ў транзіце паміж сайтамі, адказ — партнёрская прылада на аснове маршрутызацыі або тапалогія, дзе кожны пункт прызначэння сканчаецца асобна. Вырашыце гэта, перш чым абяцаць дату, бо адна замена шлюза гэтага не забяспечыць.

Парадак аперацый і праверак

Правярайце кожную магчымасць асобна. Спачатку статус тунеля паміж сайтамі і адзін запыт паміж хастамі, потым злучэнне пункт-сайт і адзін прыватны рэсурс, потым любы транзітны шлях, які заяўляе архітэктура. Зялёны статус шлюза даказвае толькі тое, што асацыяцыя бяспекі ўзнялася, і нічога больш. Трымайце праверкі ў гэтым парадку, каб збой паказваў на этап, які яго ўнёс.

Пасля любой змены тапалогіі перагенеруйце кліенцкія пакеты і трымайце пул па-за любым лакальным і злучаным дыяпазонам. Абмежаванні і адрозненні SKU сабраны ў даведніку па наладах Azure VPN Gateway.