Гибридная сетевая инфраструктура в Microsoft Azure (часть 8)

• Гибридная сетевая инфраструктура в Microsoft Azure (часть 1)
• Гибридная сетевая инфраструктура в Microsoft Azure (часть 2)
• Гибридная сетевая инфраструктура в Microsoft Azure (часть 3)
• Гибридная сетевая инфраструктура в Microsoft Azure (часть 4)
• Гибридная сетевая инфраструктура в Microsoft Azure (часть 5)
• Гибридная сетевая инфраструктура в Microsoft Azure (часть 6)
• Гибридная сетевая инфраструктура в Microsoft Azure (часть 9)
• Гибридная сетевая инфраструктура в Microsoft Azure (часть 10)

Введение

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

Затем в части 4 мы потратили большую часть нашего времени на обсуждение того, что такое виртуальные сети Azure и как они сравниваются с виртуальными сетями, которые мы используем в традиционных локальных установках Hyper-V. В части 5 были более подробно описаны виртуальные сети Azure и некоторые особенности, которые необходимо учитывать. В части 6 мы обсудили виртуальные сети Azure и внешние балансировщики нагрузки. Теперь мы продолжим работать над нашим списком сетевых возможностей, доступных в Azure на момент написания этой статьи (всегда помня о том, что Azure постоянно меняется, расширяется и добавляет новые функции):

√ Виртуальные частные сети между сайтами

√ Виртуальные частные сети типа «укажи на сайт»

√ Выделенные каналы WAN

√ Виртуальные сетевые шлюзы

√ Виртуальные сети Azure

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

√ Внешние балансировщики нагрузки

> Внутренние балансировщики нагрузки

> Группы безопасности сети

• ACL виртуальной машины
• Сторонние прокси-брандмауэры
• Двойной дом
• Выделенные общедоступные IP-адреса
• Статические IP-адреса на виртуальных машинах
• Публичные адреса на виртуальных машинах
• DNS

В части 7 мы начали обсуждение внутренней балансировки нагрузки и того, как использовать PowerShell для настройки ILB для виртуальных машин, содержащихся в виртуальной сети Azure.

Использование файла конфигурации облачной службы для настройки ILB для облачных служб

Если виртуальные машины находятся в облачных службах, вам потребуется настроить файл.cscfg. Это файл конфигурации облачной службы, который создается в Visual Studio или может быть создан вручную с помощью инструментов командной строки. Azure использует эти файлы для управления вашими облачными службами. Этот файл содержит количество экземпляров ролей для развертывания для каждой роли в службе, значения параметров конфигурации и отпечатки сертификатов, связанных с каждой из ролей, а также информацию о конфигурации сети, когда служба является частью виртуальная сеть.

Есть несколько очень важных предостережений, которые вы должны иметь в виду по этому поводу:

• Конфигурацию ILB необходимо задать в файле.cscfg при создании первого развертывания облачной службы.
• У вас уже должна быть создана виртуальная сеть для облачной службы, прежде чем вы зададите конфигурацию ILB в файле.cscfg.

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

Шаги для настройки конфигурации в файле.cscfg следующие:

1. Используйте Visual Studio, чтобы открыть файл конфигурации облачной службы для вашего облачного развертывания.
2. Добавьте раздел в файл.cscfg под последним элементом </Role> для конфигурации сети, в котором указано имя балансировщика нагрузки, тип конфигурации IP-интерфейса, имя подсети и статический IP-адрес виртуальной сети, как показано в примере ниже.
3. Измените файл определения службы (.csdef), чтобы добавить конечные точки в ILB с соответствующими значениями, как показано во втором примере ниже.

Образец 1

Образец 2

Для получения более подробных пошаговых инструкций о том, как изменить файл.cscfg для настройки ILB в облачных службах, перейдите на веб-сайт Microsoft Azure и ознакомьтесь со статьей Приступая к настройке внутреннего балансировщика нагрузки.

Группы безопасности сети

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

Например, предположим, что вы создали виртуальную сеть Azure и присвоили ей идентификатор сети 10.0.0.0/8. Теперь вы можете создать несколько подсетей в этом адресном пространстве, например 10.0.1.0/24 и 10.0.2.0/24 и т. д. Затем вы можете назначить роль каждой из этих подсетей; например, вы можете назначить подсеть для интерфейсных веб-служб, подсеть для уровней приложений, подсеть для уровней баз данных и подсеть для служб инфраструктуры (Active Directory, DNS, DHCP, службы сертификатов и т. д.).

Это довольно удобная возможность, но тогда безопасность поднимает свою уродливую голову. Видите ли, по умолчанию соединения между этими подсетями полностью маршрутизируются, и между ними нет никаких средств управления доступом по умолчанию. Очевидно, что это не сработает для большинства из нас. Однако хорошая новость заключается в том, что вы можете решить эту проблему, и есть несколько способов сделать это. Рассмотрим оба метода:

• Azure теперь поддерживает многосетевые сетевые устройства, которые можно размещать между подсетями; эти виртуальные устройства доступны в Azure Marketplace. Их можно использовать для создания необходимой вам изоляции, но плохая новость заключается в том, что вам придется платить любую цену, установленную поставщиком, который предоставляет вам виртуальное устройство. Вам также придется столкнуться с кривой обучения настройке любого устройства, которое вы выберете, и капризами сторонней поддержки.
• В качестве альтернативы вы можете использовать группу безопасности сети Azure (NSG), которая является частью Azure и фактически является маршрутизатором с фильтрацией пакетов, который можно использовать для управления трафиком, перемещающимся в подсети или виртуальные машины и из них. Группы безопасности сети настроены с помощью правил доступа, чтобы разрешать или запрещать определенный трафик, и вы можете изменить эти правила в любое время.

Как работают группы безопасности сети

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

• Трафик HTTP/HTTPS из локальной сети
• RDP/удаленный трафик PowerShell из локальной сети

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

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

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

NSG содержит некоторые правила по умолчанию, которые вы не можете удалить, но им назначается самый низкий приоритет (который равен 65 500), поэтому вы переопределить их своими собственными правилами, которые будут обрабатываться первыми, если им присвоен более высокий (более низкий) приоритет.. Когда совпадение найдено, правила больше не обрабатываются.

Если вы хотите реализовать более высокий уровень безопасности с точки зрения сети, вы также можете настроить правила в брандмауэре на основе хоста. В этом случае вам придется сделать это на самой виртуальной машине, поскольку система управления структурой Azure не будет настраивать или отслеживать правила, которые вы настраиваете для каждой виртуальной машины.

Какими бы замечательными ни были NSG, у них есть свои ограничения и предостережения, как и у большинства технологий. Важные из них заключаются в том, что вы не можете использовать их с виртуальными сетями, связанными с аффинити-группами. Также имейте в виду, что виртуальная машина или подсеть могут быть связаны только с одной группой безопасности сети. Наконец, имейте в виду, что вы не можете использовать ACL и NSG на основе конечных точек с одним и тем же экземпляром виртуальной машины. Все ACL конечных точек, которые уже подключены к виртуальной машине, необходимо удалить, прежде чем вы сможете использовать группы безопасности сети с этой виртуальной машиной.

Для получения дополнительной информации о группах безопасности сети, о том, как они работают и как их настроить, ознакомьтесь с отличной статьей Что такое группа безопасности сети (NSG)?

Резюме

В этой статье, части 8 нашей серии статей о гибридной сетевой инфраструктуре в Microsoft Azure, мы расширили наше предыдущее обсуждение внутренней балансировки нагрузки, и вы узнали, как мы можем воспользоваться преимуществами балансировки нагрузки на виртуальных машинах, не подключенных к Интернету, с помощью Внутренняя балансировка нагрузки с помощью облачных сервисов. Затем мы говорили о группах безопасности сети, которые по сути представляют собой устройства проверки пакетов с отслеживанием состояния, которые позволяют сегментировать трафик между подсетями в виртуальной сети Azure. В следующий раз, в части 9, мы углубимся в тему списков управления доступом к виртуальным машинам (ACL), поэтому обязательно присоединяйтесь к нам.

• Гибридная сетевая инфраструктура в Microsoft Azure (часть 1)
• Гибридная сетевая инфраструктура в Microsoft Azure (часть 2)
• Гибридная сетевая инфраструктура в Microsoft Azure (часть 3)
• Гибридная сетевая инфраструктура в Microsoft Azure (часть 4)
• Гибридная сетевая инфраструктура в Microsoft Azure (часть 5)
• Гибридная сетевая инфраструктура в Microsoft Azure (часть 6)
• Гибридная сетевая инфраструктура в Microsoft Azure (часть 9)
• Гибридная сетевая инфраструктура в Microsoft Azure (часть 10)