Microsoft Azure — сетевая операционная система будущего, сегодня (часть 4) — многосайтовая VPN и подключение между виртуальными сетями

Опубликовано: 8 Марта, 2023

на информационный бюллетень WindowsNetworking.com, посвященный обновлению статей в режиме реального времени

Microsoft Azure — сетевая операционная система будущего, сегодня (часть 2) — выделенное подключение к глобальной сети с помощью ExpressRoute
Microsoft Azure — сетевая операционная система будущего, сегодня (часть 3) — многосайтовая VPN и подключение между виртуальными сетями

В части 3 нашей серии статей о новых возможностях сетей Microsoft Azure мы говорили о возможностях VPN типа site-to-site и о том, как это позволяет подключать несколько локальных сайтов к виртуальной сети Azure.

Из предыдущей статьи вы узнали, что теперь к виртуальной сети Azure можно подключить не один, а несколько локальных сайтов. Это решило большую проблему для нас. До появления этих новых возможностей, если вы хотели, чтобы несколько локальных сайтов были подключены к вашей виртуальной сети Azure, у вас было два варианта:

Сделайте ресурсы в виртуальной сети Azure доступными для Интернета, чтобы все ваши сайты могли получать доступ к этим ресурсам через свои локальные интернет-соединения, или
Направляйте все запросы к ресурсам, расположенным в виртуальной сети Azure, через единый VPN-шлюз, подключающийся к вашей виртуальной сети Azure.

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

Тем не менее (всегда есть «однако», не так ли?), все наши надежды и мечты в отношении сетевой маршрутизации не реализуются с помощью VPN-шлюзов с несколькими сайтами. Существует еще одна проблема сетевой маршрутизации, с которой вы можете столкнуться и которая может свести вас с ума так же, как сценарий с одним VPN-шлюзом. Эта проблема связана с маршрутизацией трафика между виртуальными сетями Azure (VNet) между этими сетями.

Дилемма между виртуальными сетями

До недавних обновлений, если у вас было две виртуальные сети Azure и вы хотели, чтобы ресурсы в каждой из виртуальных сетей Azure взаимодействовали друг с другом, у вас было два варианта:

Вы можете маршрутизировать трафик через Интернет или
Вы можете направить трафик обратно в локальную сеть и перенаправить его в целевую виртуальную сеть Azure.

Маршрутизация трафика через Интернет

Первый вариант может быть жизнеспособным решением, если вы говорите обо всех общедоступных сетевых службах. Однако это довольно маловероятный сценарий, потому что мы обычно говорим о внешнем и внутреннем взаимодействии, и вы определенно не хотите, чтобы эти внутренние ресурсы были доступны непосредственно из Интернета.

Например, предположим, что в одной виртуальной сети Azure у вас есть несколько веб-интерфейсов, которые действуют как часть многоуровневого бизнес-приложения. Вы хотите поместить эти веб-интерфейсы в выделенную виртуальную сеть Azure, поскольку хотите, чтобы эта виртуальная сеть Azure по существу действовала как демилитаризованная зона для доступа в Интернет. Без проблем; вы настраиваете веб-интерфейсы в виртуальной сети Azure как конечные точки и разрешаете веб-трафику достигать их из любой системы, расположенной в Интернете.

Следующим шагом является передача информации обратно в серверные части. Серверная часть, скорее всего, представляет собой уровень приложений, который выполняет некоторую бизнес-логику и, вероятно, должен обращаться к уровню базы данных. Вам не нужны уровни приложения и базы данных в одной и той же виртуальной сети Azure по той же причине, по которой вы не размещаете эти системы в локальной сети DMZ. Вы не хотите раскрывать эту информацию между веб-уровнем и серверным уровнем в Интернете по ряду соображений безопасности. Таким образом, похоже, что первый вариант в большинстве случаев не сработает.

Перенаправление трафика через локальную сеть в виртуальную сеть Azure.

К счастью, второй вариант — перенаправить трафик обратно в локальную сеть и перенаправить его в целевую виртуальную сеть Azure — является безопасным вариантом. Вот что вам нужно сделать, чтобы реализовать это:

Создайте VPN типа "сеть-сеть" для обеих виртуальных сетей Azure. Одно из VPN типа «сеть-сеть» будет подключено к интерфейсному веб-уровню, а второе соединение «сеть-сеть» будет подключено к уровню приложений.
Когда клиентская система подключается к веб-уровню, информация, собранная любым веб-интерфейсом, отправляется на уровень приложений для обработки. Для этого он отправляет информацию обратно через соединение между сайтами в локальный шлюз. Затем локальный шлюз направляет эту информацию обратно через второе соединение между сайтами, которое подключается к виртуальной сети Azure уровня приложений.
Когда уровень приложений отправляет свой ответ обратно на веб-уровень, он отправляет его обратно через соединение между сайтами на локальный VPN-шлюз, а затем локальный VPN-шлюз пересылает ответ обратно на веб-уровень через сайт на VPN сайта, которая соединяет локальный шлюз с виртуальной сетью Azure, в которой размещается веб-уровень.

Хм. Если вы думаете, что это ужасно много переадресации, вы правы. И со всеми этими прыжками, требующими обратной связи через локальный VPN-шлюз, вы знаете, что вы собираетесь ввести чрезмерную задержку, которая может оказать серьезное негативное влияние на приложения, чувствительные к задержке.

Каково было решение этой проблемы? Решение состояло в том, чтобы поместить внешний и внутренний уровни в одну и ту же виртуальную сеть Azure и просто верить, что ничего плохого не произойдет в случае компрометации серверов веб-уровня. Хотя это было решением, стратегия, основанная на модели «скрести пальцы и молись», обычно не считается быстрым путем к успеху.

Возможность подключения между виртуальными сетями на помощь

Перенесемся в сегодняшний день. Эта неприятная проблема теперь решена с помощью новой функции, включенной в Microsoft Azure, которая достаточно уместно называется подключением между виртуальными сетями. Это означает, что теперь, если вы хотите, чтобы ресурсы в разных виртуальных сетях Azure взаимодействовали друг с другом, они могут сделать это, взаимодействуя друг с другом напрямую. Нет необходимости направлять этот трафик через Интернет или зацикливать его через локальный VPN-шлюз.

Виртуальные сети Azure, которые вы хотите подключить, могут находиться в одном и том же центре обработки данных Azure, или вы можете создать подключения между виртуальными сетями Azure, расположенными в разных центрах обработки данных Azure в одном регионе или даже в разных регионах. Например, вы можете разместить один уровень в Северной Америке, а другой — в одном из европейских центров обработки данных. Вы можете сделать это. Кроме того, вы можете подключить виртуальные сети Azure к нескольким подпискам, включая подписки, которые принадлежат и управляются разными компаниями.

Структура виртуальной сети Azure работает очень быстро, поэтому эти соединения будут высокоскоростными. Это создаст ощущение, что вы передаете данные через свой собственный центр обработки данных или, возможно, хостинг-сайт, где у вас есть несколько стоек, которыми вы владеете.

Прежде чем вы слишком взволноваетесь и броситесь делать это, вам нужно кое-что знать. Весь трафик, исходящий из виртуальной сети Azure (исходящий или «исходящий» трафик), оплачивается так же, как и исходящий трафик из виртуальной сети Azure в Интернет (или в Интернет и обратно в локальный VPN-шлюз). С учетом сказанного, стоимость трафика относительно невелика, поэтому вам, вероятно, не нужно слишком беспокоиться, но вам нужно знать об этом и убедиться, что вы выполняете некоторое моделирование трафика, чтобы получить представление о потенциальных затратах, если только по той причине, что вы не хотите, чтобы вас удивил счет.

Факторы, которые следует учитывать

Конечно, у каждого решения есть свои предостережения, а также некоторые неожиданные дополнительные преимущества. Некоторые другие факторы, которые следует учитывать, если вы планируете подключать виртуальные сети Azure друг к другу через сетевую структуру Azure, включают следующее:

Хотя Azure может предоставить хранилище с георепликацией, вы можете настроить несколько виртуальных сетей Azure для создания системы синхронизации с геореплицацией. Подумайте о постоянной доступности SQL. Вы можете распределить группы SQL Always-on Availability по виртуальным сетям Azure, расположенным на разных континентах.
Помните, что хотя можно создавать автономные виртуальные машины, которые не расположены в виртуальной сети Azure, подключение между виртуальными сетями не будет работать, если вы не поместите эти виртуальные машины в виртуальную сеть Azure.
Шлюзы VPN, используемые для соединения виртуальных сетей Azure, должны быть шлюзами статической маршрутизации. Также возможно подключить одну виртуальную сеть Azure к локальному VPN-шлюзу и VPN-шлюзу к другой виртуальной сети Azure. Однако для того, чтобы это работало, вам нужен VPN-шлюз, который вы используете локально, для поддержки динамической маршрутизации, а также VPN-шлюзы в виртуальных сетях Azure для поддержки динамической маршрутизации. Если в настоящее время у вас есть VPN-соединение типа "сеть-сеть", работающее между виртуальной сетью Azure и локальной средой и настроенное как статический шлюз, вам придется это исправить.
Максимальное количество VPN типа "сеть-сеть", которое можно создать для любого сайта (локально или для другой виртуальной сети Azure), равно 10.
К сожалению, у вас может быть только один туннель. Вы не можете создавать избыточные туннели для поддержки высокой доступности (пока). Хотя сейчас это недоступно, учитывая быстрый темп разработки Azure, я думаю, что это только вопрос времени, когда это будет поддерживаться, поскольку это ключевое требование предприятия иметь избыточность на сетевом уровне.
Если вы публикуете конечные точки с балансировкой нагрузки, все конечные точки с балансировкой нагрузки должны находиться в одной и той же виртуальной сети Azure. Вы не можете поместить некоторые из этих конечных точек с балансировкой нагрузки в одну виртуальную сеть Azure, а некоторые — в другую виртуальную сеть Azure. Другими словами, алгоритм балансировки нагрузки для кластера конечных точек с балансировкой нагрузки не будет распространяться на виртуальные сети Azure.
Шлюз Azure VPN должен будет обрабатывать весь входящий и исходящий трафик всех локальных сетей и виртуальных сетей Azure, которые к нему подключены. К сожалению, у вас нет доступа к VPN-шлюзу Azure для мониторинга производительности, который вам может понадобиться, поэтому вам придется найти какие-то другие средства, чтобы определить, создаете ли вы какие-либо пробки..

Резюме

До недавних обновлений Microsoft Azure невозможность подключить виртуальные сети Azure друг к другу напрямую приводила к тому, что некоторые обходные пути были неудовлетворительными и во многих случаях представляли собой препятствия для развертывания. С введением возможности подключения виртуальной сети Azure к виртуальной сети Azure теперь вы можете подключать виртуальные сети Azure, принадлежащие одной подписке, к разным подпискам и даже к разным организациям. Это решает множество проблем с безопасностью и производительностью. В следующем выпуске этой серии мы продолжим рассказывать о некоторых сетевых улучшениях в Microsoft Azure. Тогда увидимся! -Деб и Том.