UDR у Azure да шлюза VPN: адзін пункт прызначэння, а не ўвесь зыходны трафік

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

Вы дадаяце карыстальніцкі маршрут для аднаго знешняга прэфікса, накіроўваеце яго на шлюз VPN, а трафік усё роўна выходзіць праз інтэрнэт-шлях Azure. Або ён выходзіць правільна, і адказ ніколі не вяртаецца. Абодва вынікі — ад адной памылкі: стаўленне да наступнага кроку Azure як да ўсяго дызайну. Табліца маршрутаў вырашае толькі, які выхад пакет возьме ўнутры Azure. Што здарыцца з ім пасля тунеля і як вернецца адказ — гэта другая палова, якую трэба пабудаваць.

Наступны крок — гэта шлюз, а не IP прылады

UDR адпраўляе адпаведны прэфікс на тып наступнага кроку, і VirtualNetworkGateway — гэта тып, а не адрас. Людзі ўстаўляюць прыватны IP шлюза ў маршрут VirtualAppliance і потым здзіўляюцца, чаму нічога не супадае, бо гэты тып чакае замест гэтага NIC або ўнутраны балансіроўшчык нагрузкі. Дакументацыя Microsoft па маршрутызацыі таксама абмяжоўвае наступны крок шлюза віртуальнай сеткай, чый шлюз з'яўляецца шлюзам VPN. ExpressRoute, Route Server і цэнтр Virtual WAN гэтым варыянтам не адрасуюцца.

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

Прачытайце эфектыўны маршрут, перш чым нешта змяняць

Azure аб'ядноўвае сістэмныя маршруты, прэфіксы, вывучаныя праз BGP, і UDR у эфектыўную табліцу маршрутаў для кожнага NIC, і самы доўгі адпаведны прэфікс перамагае незалежна ад таго, адкуль ён узяўся. Для аднаго прэфікса UDR перамагае маршрут BGP. Менавіта таму састарэлы UDR з папярэдняга эксперыменту можа ціха перакрыць прэфікс, які вы толькі што вывучылі праз тунель.

Спачатку паглядзіце на эфектыўную табліцу, потым вырашыце, дадаяце вы маршрут ці замяняеце:

az network nic show-effective-route-table \
  --resource-group rg-net --name vm-web-nic -o table

Чытайце слупок крыніцы разам з прэфіксам. Маршрут з правільным прэфіксам і няправільнай крыніцай паказвае, які аб'ект рэдагаваць, і ратуе ад дадання другога маршруту, які прайграе першаму.

Пішыце маршрут пад рэальны прэфікс і падсетку

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

Стварыце маршрут, затым прывяжыце табліцу да падсеткі, якая размяшчае нагрузку:

az network route-table route create --resource-group rg-net --route-table-name rt-egress \
  --name to-partner --address-prefix 203.0.113.0/24 --next-hop-type VirtualNetworkGateway
az network vnet subnet update --resource-group rg-net --vnet-name vnet-app \
  --name snet-web --route-table rt-egress

Распаўсюджванне таксама важнае. Калі на гэтай табліцы ўключана распаўсюджванне BGP, вывучаныя прэфіксы з'яўляюцца побач з напісанымі вамі, і больш канкрэтны вывучаны прэфікс можа перамагчы шырэйшы UDR. Адключайце распаўсюджванне толькі тады, калі хочаце, каб набор UDR быў галоўным для гэтай падсеткі.

Завяршыце лакальную палову, інакш паток памрэ там

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

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

Селектары і спісы дазволаў — асобна ад усяго гэтага. Выбар наступнага кроку Azure не пашырае селектары трафіку VPN і не змяняе спіс дазволаў крыніц знешняга сэрвісу.

Правярайце па крыніцы, якую бачыць прызначэнне

Адпраўце запыт з рэальнай нагрузкі, а не з прамежкавага хоста ў іншай падсетцы, затым прачытайце адрас крыніцы, які назірала прызначэнне. Гэта адзіная велічыня паказвае, які з двух дызайнаў вяртання ўжыты. Далей праверце зваротны шлях і пацвердзіце, што звычайны кіраўнічы трафік да VM усё яшчэ працуе, бо маршрут па змаўчанні, дададзены выпадкова, паказвае сябе як зламаная SSH-сесія значна раней, чым як зламаная праграма.

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

Падобныя артыкулы