Что такое виртуальная сеть Азур? Большинство людей слышат этот термин и думают, что это просто очередная настройка при развертывании виртуальной машины, что-то, что нужно отметить галочкой и забыть. Но правда в другом. Виртуальная сеть Азур – это не просто настройка. Это фундамент всего, что вы строите в Азур. Каждая виртуальная машина, каждая база данных, каждый сервис приложений, каждая функция, которую вы развертываете, находится внутри нее. И если вы не понимаете, как они работают, вы действуете вслепую. К концу этого выпуска вы поймете, что такое Винет, как она работает и почему каждый развертываемый вами ресурс зависит от нее. Мы разберем, что такое Винет, как работают IP-адреса, подсети, безопасность, маршрутизация и как соединять Винет между собой. Берите кофе и давайте начнем. Что такое Винет? Частная облачная сеть. Начнем с самого простого определения. Виртуальная сеть Азур или сокращенно Винет – это ваша собственная частная сеть внутри Азур. Представьте ее как частное офисное здание. Только те, кому вы разрешите, могут попасть внутрь. Вы контролируете, кто проходит в дверь, кто попадает на какой этаж, а кому доступ закрыт полностью. До появления Винет все было иначе.

Разверните виртуальную машину в облаке, и она по умолчанию была фактически открыта для интернета. Никакой частной сети вокруг. Любой, кто знал IP-адрес, мог попытаться подключиться. Это был кошмар с точки зрения безопасности. Что же изменилось? Азур дала возможность создавать изолированные частные сетевые пространства. Вы определяете границы. Вы решаете, что находится внутри. Ничто снаружи не может попасть внутрь, пока вы явно не разрешите это. Важно знать заранее, ваша Винет существует в конкретном регионе Азур. Она не глобальна. Создайте Винет в Западной Европе, и она останется там. Ресурсы в другом регионе не могут просто так в нее попасть. Им понадобится своя Винет или вам придется соединить их позже. Когда вы создаете Винет, вы сами определяете пространство IP-адресов. Азур не выбирает его за вас. Вы сами решаете, какой диапазон IP-адресов будут использовать ваши ресурсы. Это большая ответственность, и мы поговорим о том, как сделать это правильно, в следующем разделе. Вот основной вывод. Винет — это фундамент. Каждая виртуальная машина, база данных или функция Азур, которую вы развертываете, находится внутри нее. Без Винет у ваших ресурсов нет контекста частной сети. Они просто плавают в облаке без границ, без изоляции, без безопасности. Итак, что это значит для вас? Если вы что-то создаете в Азур, начните с Винет, причем не после развертывания ресурсов, а до него. Ваша Винет — это земля, на которой вы строите.

Вы же не станете строить дом, не купив сначала участок, верно? Здесь та же идея. IP-адресация и CIDR — выбор адресного пространства. Что ж, давайте начнем. Когда вы создаете Винет, первое важное решение — выбор диапазона IP-адресов. Это делается с помощью нотации CIDR. CIDR расшифровывается как «бесклассовая междоменная маршрутизация», но по сути это просто способ сказать «мне нужно столько-то IP-адресов». Почему это важно? Потому что выбранный диапазон определяет, сколько ресурсов поместится в вашей виртуальной сети. Вот как это работает. CIDR использует косую черту и число. Например, 16 или 24. Это число указывает размер адресного пространства. Значение 16 дает вам около 65 000 IP-адресов. Это очень много. Значение 24 дает около 250, что идеально подходит для небольшой команды или одного уровня приложения. Поэтому при проектировании Винет нужно подумать о количестве ресурсов и о том, как вы хотите их сгруппировать.

Однако вы не можете выбрать просто любой диапазон IP-адресов. Azure следует стандарту RFC 1918, который выделяет частные IP-диапазоны для внутренних сетей. У вас есть три варианта. Диапазон 10XXX самый большой, он дает много пространства для роста. Диапазон 172.16XX немного меньше, но тоже полезен. А диапазон 192.168XX, вероятно, используется у вас дома на роутере. И вот в чем дело. Адресное пространство вашей Винет не должно пересекаться с любой другой сетью, которой вы планируете подключиться. Это распространенная ошибка. Многие выбирают знакомый диапазон, а потом обнаруживают, что он конфликтует с корпоративной сетью. Поэтому, если офисная сеть вашей компании использует 1.0.0.0.0, касая черта 1.6, не используйте тот же диапазон в Azure. Если позже вы попытаетесь их соединить, они будут конфликтовать, и трафик не будет знать, куда идти. Приведу конкретный пример. Представьте, что вы строите гибридную инфраструктуру, где Azure подключается к вашему локальному дата-центру, а в нем используется 1.0.0.0.0, касая черта 1.6. Если вы создадите Винет с таким же диапазоном, две сети будут бороться за одни и те же IP. Только вдумайтесь, две сети с одним диапазоном IP не смогут нормально взаимодействовать.

Это как два дома с одним и тем же адресом. Почта придет не туда. Эту проблему лучше не решать постфактум. Поэтому планируйте заранее и выбирайте уникальный диапазон. И вот вам совет по планированию. Выбирайте диапазон больше, чем, как вам кажется, вам нужно. Возможно, вы думаете, что сейчас вам хватит маски 24, но по мере роста приложения вы пожалеете, что не взяли 16. Позже это будет нелегко изменить. Когда ваша виртуальная сеть создана и ресурсы развернуты, менять адресное пространство крайне неудобно. Это возможно, но вы вряд ли захотите делать это в рабочей системе. Поэтому оставьте себе пространство для роста. Что это значит для вас? Представьте адресное пространство своей виртуальной сети как покупку земли. Возьмите с запасом для будущего роста. Если думаете, что вам нужен небольшой участок, купите средний. Потом скажете себе спасибо. Это главный вывод. Планируйте адресное пространство с прицелом на будущее.

Подсети – разделение вашей сети. Итак, у вас есть виртуальная сеть и выбранное адресное пространство. Что дальше? Не стоит просто сваливать все в одну кучу. Вот тут-то и пригодятся подсети. Подсети – один из фундаментальных строительных блоков вашей виртуальной сети. Они позволяют организовать и обезопасить ваши ресурсы. Подсеть – это меньший раздел адресного пространства вашей виртуальной сети. Если виртуальная сеть – это здание, то подсети – это отдельные комнаты. Вы ведь не станете размещать серверную, стойку регистрации и комнату отдыха в одном общем пространстве, верно? Здесь тот же принцип. Это простая концепция, но она кардинально меняет управление сетью. Разные ресурсы помещаются в разные подсети. Веб-серверы в одну подсеть, базы данных в другую, прикладная логика в третью. Почему? По двум причинам. Безопасность и организация. Давайте сначала поговорим о безопасности, ведь это обычно самое важное.

Безопасность прежде всего. Если кто-то взломает ваш веб-сервер, вы не захотите, чтобы он получил прямой доступ к базе данных. Отдельные подсети создают естественный барьер. Злоумышленнику придется преодолеть эту границу, а вы можете точно контролировать, что через нее проходит. Вы также можете использовать группы сетевой безопасности для контроля трафика между подсетями. Это тема для другого видео, но важно знать, что подсети – основа такой безопасности. Теперь об организации. Когда у всего есть свое место, управлять этим гораздо проще. Вы знаете, какая подсеть содержит ресурсы внешнего интерфейса, а какая – данные бэкенда. Вы можете применять политики и правила ко всей подсети сразу, вместо настройки каждого ресурса по отдельности. Это экономит время и уменьшает количество ошибок. А вот деталь, которая часто застает врасплох. Азор резервирует 5 IP-адресов в каждой подсети для своих внутренних нужд, таких как маршрутизация и DNS. Поэтому, если вы создаете подсеть с маской 24, дающей 256 адресов, фактически вы получите только 251 доступный. Это распространенная ловушка. Вы планируете 256, но получаете только 251. Поэтому всегда добавляйте немного запаса при расчете размера подсетей.

Хорошая новость в том, что подсети можно добавить после создания виртуальной сети. Вы не ограничены только теми, что настроили при создании. Поэтому, если вы поймете, что вам нужна отдельная подсеть для инструментов управления или мониторинга, добавьте ее позже. Это не проблема. Но все же лучше планировать их заранее. Добавлять подсети позже можно, но вам, возможно, придется перемещать ресурсы, что может вызвать перебой. Но вот лучшая практика. Используйте отдельные подсети для разных уровней вашего приложения с самого начала. Подумайте об архитектуре вашего приложения. Обычно у вас есть внешний уровень, обрабатывающий запросы пользователей, внутренний уровень бизнес-логики и уровень данных для хранения информации. У каждого из них должна быть своя подсеть. Не ждите перехода в продуктивную среду, чтобы понять необходимость разделения компонентов. Это гораздо сложнее, когда ресурсы уже развернуты. Что это значит для вас? Подсети помогают поддерживать порядок и безопасность в вашей сети. Это как комнаты в вашем здании. Планируйте их заранее и предоставляйте каждому уровню приложения свое пространство. Так вы сохраните свою сеть чистой и защищенной.

Публичные и частные IP-адреса. Кто что видит. Давайте поговорим об IP-адресах, ведь они бывают разными. Когда вы развертываете ресурс внутри виртуальной сети, он по умолчанию получает частный IP-адрес. Этот адрес используется для связи с другими ресурсами внутри виртуальной сети. Представьте его как внутренний телефонный номер. Только люди внутри здания могут по нему позвонить. Частные IP-адреса доступны только изнутри виртуальной сети или из подключенных к ней сетей. Если вы сидите дома за ноутбуком, вы не сможете подключиться к частному IP в Азур. Его нет в интернете. Он находится внутри вашей частной сети. Так как же сделать ресурс доступным из интернета? Вы назначаете ему публичный IP-адрес. Этот адрес виден внешнему миру, как опубликованный номер телефона вместо внутреннего добавочного. Вот ключевой момент. Публичные IP-адреса необязательны. Вы назначаете их явно, потому что Азур никогда не дает ресурсам публичный IP, если вы об этом не просите. Это сделано намеренно. По умолчанию должен быть частный адрес, а публичный – это осознанный выбор. И именно здесь многие новички совершают ошибку. Они назначают публичные IP-адреса всему подряд. Их веб-сервер, база данных и внутренний IP все получают по публичному адресу. Это риск для безопасности.

Ваша база данных не должна быть доступна из интернета, как и ваш внутренний IP. Публичные IP-адреса должны быть только у тех фронтенд-ресурсов, с которыми непосредственно взаимодействуют пользователи. Существует два типа публичных IP-адресов – статические и динамические. Статический публичный IP-адрес остается неизменным, даже если вы останавливаете и перезапускаете ресурс. Динамический публичный IP-адрес может меняться. Если вы запускаете рабочие приложения, вам, скорее всего, нужны статические IP, чтобы пользователи всегда могли вас найти. Если вы что-то тестируете, динамический IP вполне подойдет. Вы также можете использовать префикс публичного IP-адреса, который позволяет зарезервировать блок адресов. Вместо создания адресов по одному, вы резервируете диапазон, а затем назначаете отдельные адреса из этого диапазона. Это удобно, если вы знаете, что для проекта вам потребуется несколько публичных IP-адресов. Что это значит для вас? Приватные IP-адреса – это безопасный выбор по умолчанию. Это ваш внутренний телефонный номер. Публичные IP – это осознанный выбор, который вы делаете, только когда ресурс должен быть доступен извне. И когда они вам нужны, подумайте, статический или динамический адрес выбрать и имеет ли смысл использовать префикс. Группы сетевой безопасности контролируют трафик. Итак, вы разобрались с виртуальной сетью, подсетями и IP-адресами. Но как на самом деле контролировать, какой трафик разрешен, а какой нет? Здесь на помощь приходят группы сетевой безопасности NSG. NSG – это швейцар, который контролирует входящий и исходящий трафик ваших ресурсов. Представьте его как охранника на входе в клуб, который проверяет документы, сверяется со списком гостей и не пускает тех, кому не положено. Весь трафик, который пытается достичь вашего ресурса, сначала должен пройти через этого охранника. NSG работают на основе правил. Каждое правило разрешает или запрещает трафик на основе четырех критериев – IP-адрес источника, IP-адрес назначения, номер порта и протокол. Например, можно разрешить трафик с IP-адреса вашего офиса через порт 443 или запретить весь трафик из интернета через порт 22. Вот такой уровень контроля. А вот и мощная функция. Вы можете привязать NSG к подсети или напрямую к сетевому интерфейсу отдельной виртуальной машины. Если вы привязываете ее к подсети, NSG применяется ко всему, что находится внутри. Каждой виртуальной машине – базе данных и ресурсу. Это общая политика безопасности. Если привязать ее к сетевому интерфейсу конкретной машины, она будет действовать только для этого устройства. Можно использовать это и другое одновременно. NSG на уровне подсети для общих правил и NSG на уровне сетевой карты для исключений. Правила по умолчанию, которые создает Azure, довольно разумны. Они разрешают весь трафик внутри виртуальной сети, чтобы ресурсы могли взаимодействовать, и блокируют весь входящий трафик из интернета, поэтому никто из вне не получит доступ к вашим ресурсам, пока вы сами не разрешите это явно.

Это хорошая отправная точка. Позвольте привести распространенный пример. Допустим, вы управляете виртуальной машиной Linux, и вам нужно подключиться к ней по SSH. Вы создаете правила NSG, разрешающие входящий трафик на порт 22. Но вы ведь не хотите разрешать SSH отовсюду. Это напрашивание на неприятности, поэтому вы ограничиваете доступ своим IP-адресам, чтобы только вы могли подключаться по SSH, а все остальные блокировались. То же самое применимо CarDP на порту 3389 для машин с Windows. Что это означает для вас? NSG — это ваш первый рубеж защиты, и самое лучшее — они бесплатны. За их использование не взимается дополнительная плата, так что нет причин их не настраивать. Каждая подсеть и каждый ресурс должны быть защищены с помощью NSG. Начинайте с запрета всего трафика и открывайте только то, что необходимо. Таблица маршрутизации и маршрутизация — направление трафика. Теперь давайте поговорим о маршрутизации, ведь как только вы определили, какой трафик разрешен, нужно решить, куда он должен направляться. Суть в том, что Azure автоматически создает системные маршруты для каждой подсети. Вам не нужно ничего делать. Представьте это как встроенный GPS, который знает основные дороги. Трафик внутри виртуальной сети, трафик в пиринговые сети, трафик в интернет. Все это работает из коробки, но иногда стандартный GPS ведет не туда, куда вам нужно. Вот здесь вам и пригодятся пользовательские маршруты или UDR. Они позволяют переопределить системные маршруты Azure и взять под контроль путь прохождения трафика. Как это работает?

Вы создаете таблицу маршрутизации. Добавляете свои пользовательские маршруты. Затем связываете эту таблицу маршрутизации с подсетью. С этого момента трафик, покидающий подсеть, будет следовать вашим правилам вместо стандартных. Позвольте привести конкретный пример. Допустим, вы хотите, чтобы весь интернет-трафик из вашей виртуальной сети сначала проходил через Брандмауэ. Возможно, вам нужно проверять его, регистрировать в журнале или блокировать вредоносные сайты. Стандартный системный маршрут отправляет интернет-трафик напрямую. Это вас не устраивает, поэтому вы создаете маршрут, согласно которому любой трафик в адрес 0.0.0.0, то есть в любую точку интернета, должен направляться на Брандмауэ. Это и есть пользовательский маршрут. В таблицах маршрутизации используется понятие «следующий переход». Это пункт назначения, куда трафик направляется далее. У вас есть несколько вариантов. Вы можете отправить его на виртуальное устройство, например, Брандмауэ. Вы можете отправить его на шлюз виртуальной сети, именно так происходит подключение к локальным сетям. Вы можете отправить его напрямую в интернет или в NAN, что по сути отбрасывает трафик. Важно понимать, что маршрутизация – это то, как вы управляете путем прохождения трафика в вашей сети.

Системные маршруты – это хороший стандарт, но они не всегда подходят для вашей ситуации. Если вам нужно, чтобы трафик проходил через точку проверки, конкретный шлюз или был полностью заблокирован, вам нужны пользовательские маршруты. Что это значит для вас? Маршрутизация – это способ управления трафиком, и вы можете переопределить настройки Азура в любой момент. Начните с системных маршрутов, поймите, как они работают, а затем добавляйте свои, когда этого требует архитектура. Перинг Ви нет, соединение сетей. До сих пор мы говорили об одной Ви нет, одном здании, одной частной сети. Но что происходит, когда у вас несколько Ви нет? Может быть, одна для рабочей среды, другая для тестирования, или вы запускаете приложения в разных регионах Азу. По умолчанию эти Ви нет полностью изолированы. Они не могут взаимодействовать друг с другом. Они как отдельные здания, без дорог между ними. Вот здесь и пригодится Перинг Ви нет. Он позволяет объединить две Ви нет в частном порядке, именно в частном. Трафик между объединенными Ви нет остается внутри магистральной сети Microsoft. Он никогда не выходит в публичный интернет. Это означает низкую задержку, высокую пропускную способность и отсутствие внешних угроз. Вот что удивляет многих.

Перинг работает и между регионами. Это называется глобальным Перингом. Вы можете соединить Ви нет в Западной Европе с Ви нет в Юго-Восточной Азии, и трафик останется в частной сети Microsoft. Никаких VPN-шлюзов, никаких публичных IP, просто прямое частное соединение. Но есть правила, которые нельзя нарушать. У Перинговых Ви нет не должны пересекаться адресные пространства. Если обе Ви нет пытаются использовать диапазон 1.0.0.0.0, косая черта 1.6, их нельзя объединить. IP-адреса будут конфликтовать, и Азур не поймет, какой сети принадлежит пакет. Помните наш ранний совет о тщательном выборе адресного пространства. Вот почему. Если вы планируете Перинг в будущем, убедитесь, что диапазоны не пересекаются с самого начала. А вот деталь, на которой многие спотыкаются. Перинг нетранзитивен. Что это значит? Допустим, Ви нет А соединена с Ви нет Б, а Ви нет Б с Ви нет Си винета не получит доступ к Ви нет С через Б автоматически. Они не соединены. Каждый Перинг – это прямая связь ровно между двумя Ви нет.

Если нужно, чтобы А общалась с С, требуется отдельный Перинг между ними. Как же масштабировать это решение? Используйте архитектуру «Звезда» Hub & Spoke. Одна центральная виртуальная сеть, концентратор, объединяется с множеством других сетей, периферийных. В концентраторе могут находиться общие службы, такие как Брандмауэр, VPN-шлюз или инструменты мониторинга. В периферийных сетях размещаются ваши отдельные рабочие нагрузки. Каждая периферийная сеть напрямую соединяется с концентратором, но не соединяется с другими периферийными сетями. Если периферийной сети нужно связаться с другой, трафик проходит через концентратор. Это позволяет поддерживать порядок и централизованное применять политики безопасности. Что это значит для вас? Перинг – это способ создания сетей, охватывающих несколько виртуальных сетей и регионов. Это мост между вашими зданиями. Планируйте адресные пространства так, чтобы они не пересекались.

Помните, что Перинг не является транзитивным, и рассмотрите топологию «Звезда», когда вы перерастаете рамки одной сети. Как все это связано? Общая картина. Давайте посмотрим, как эти части сочетаются друг с другом. В этом заключается настоящая сила. Вы начинаете с виртуальной сети «Винет». Это ваше личное пространство в АЗУ. Представьте его как свой земельный участок. Внутри этого участка вы создаете подсети. Это ваши «комнаты». Одна для веб-серверов, одна для баз данных, одна для инструментов управления. Каждая подсеть получает свой блок адресов, выделенный из адресного пространства виртуальной сети. Затем вы добавляете безопасность. Подсетям подключаются группы сетевой безопасности «НСГ». Они контролируют входящий и исходящий трафик. Ваша веб-подсеть разрешает трафик из интернета через порт 443.

Каждой двери точно знает, кому разрешен вход. Далее вы настраиваете маршрутизацию. Возможно, вы хотите, чтобы весь исходящий интернет-трафик проходил через Брандмауэр для проверки. Вы создаете таблицу маршрутов, добавляете пользовательский маршрут и привязываете его к подсетям. Теперь трафик следует по созданному вами пути, а не по стандартному пути АЗУ. И, наконец, вы соединяете все вместе. Вы объединяете свою Винет с другими сетями, возможно, с центральным концентратором, где находятся Брандмауэр и общие службы. Теперь ваше приложение охватывает несколько сетей, но работает как единая система. Вот тот самый важный момент. Ни один из этих элементов не работает изолированно. Виртуальная сеть без подсетей – это просто пустое пространство. Подсети без NSG полностью открыты. Маршрутизация без четкого плана направляет трафик не туда. Peering без планирования создает конфликты адресов. Все они представляют собой единую систему.

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

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

Подпишитесь на своей любимой платформе для подкастов и поделитесь этим с тем, кто только начинает свой путь в Azure. Оставьте комментарий, если вы что-то для себя открыли. Увидимся в следующем эпизоде.