WEBVTT

00:00:00.000 --> 00:00:04.460
Что такое виртуальная сеть Азур? Большинство людей слышат этот термин и думают, что это просто

00:00:04.460 --> 00:00:08.600
очередная настройка при развертывании виртуальной машины, что-то, что нужно отметить галочкой и

00:00:08.600 --> 00:00:13.420
забыть. Но правда в другом. Виртуальная сеть Азур – это не просто настройка. Это фундамент всего,

00:00:13.700 --> 00:00:17.580
что вы строите в Азур. Каждая виртуальная машина, каждая база данных, каждый сервис приложений,

00:00:17.760 --> 00:00:21.380
каждая функция, которую вы развертываете, находится внутри нее. И если вы не понимаете,

00:00:21.600 --> 00:00:26.060
как они работают, вы действуете вслепую. К концу этого выпуска вы поймете, что такое Винет,

00:00:26.060 --> 00:00:30.220
как она работает и почему каждый развертываемый вами ресурс зависит от нее. Мы разберем,

00:00:30.340 --> 00:00:34.380
что такое Винет, как работают IP-адреса, подсети, безопасность, маршрутизация и как соединять

00:00:34.380 --> 00:00:39.520
Винет между собой. Берите кофе и давайте начнем. Что такое Винет? Частная облачная сеть.

00:00:39.700 --> 00:00:44.700
Начнем с самого простого определения. Виртуальная сеть Азур или сокращенно Винет – это ваша

00:00:44.700 --> 00:00:48.860
собственная частная сеть внутри Азур. Представьте ее как частное офисное здание. Только те,

00:00:49.080 --> 00:00:52.320
кому вы разрешите, могут попасть внутрь. Вы контролируете, кто проходит в дверь,

00:00:52.320 --> 00:00:56.780
кто попадает на какой этаж, а кому доступ закрыт полностью. До появления Винет все было иначе.

00:00:56.940 --> 00:01:00.580
Разверните виртуальную машину в облаке, и она по умолчанию была фактически открыта для

00:01:00.580 --> 00:01:04.740
интернета. Никакой частной сети вокруг. Любой, кто знал IP-адрес, мог попытаться подключиться.

00:01:04.880 --> 00:01:08.800
Это был кошмар с точки зрения безопасности. Что же изменилось? Азур дала возможность создавать

00:01:08.800 --> 00:01:13.160
изолированные частные сетевые пространства. Вы определяете границы. Вы решаете, что находится

00:01:13.160 --> 00:01:17.500
внутри. Ничто снаружи не может попасть внутрь, пока вы явно не разрешите это. Важно знать заранее,

00:01:17.500 --> 00:01:22.020
ваша Винет существует в конкретном регионе Азур. Она не глобальна. Создайте Винет в Западной

00:01:22.020 --> 00:01:26.060
Европе, и она останется там. Ресурсы в другом регионе не могут просто так в нее попасть. Им

00:01:26.060 --> 00:01:30.160
понадобится своя Винет или вам придется соединить их позже. Когда вы создаете Винет, вы сами

00:01:30.160 --> 00:01:34.920
определяете пространство IP-адресов. Азур не выбирает его за вас. Вы сами решаете, какой диапазон IP-адресов

00:01:34.920 --> 00:01:38.520
будут использовать ваши ресурсы. Это большая ответственность, и мы поговорим о том, как сделать это

00:01:38.520 --> 00:01:43.740
правильно, в следующем разделе. Вот основной вывод. Винет — это фундамент. Каждая виртуальная машина,

00:01:43.740 --> 00:01:49.460
база данных или функция Азур, которую вы развертываете, находится внутри нее. Без Винет у ваших

00:01:49.460 --> 00:01:54.300
ресурсов нет контекста частной сети. Они просто плавают в облаке без границ, без изоляции,

00:01:54.460 --> 00:01:59.360
без безопасности. Итак, что это значит для вас? Если вы что-то создаете в Азур, начните с Винет,

00:01:59.520 --> 00:02:04.000
причем не после развертывания ресурсов, а до него. Ваша Винет — это земля, на которой вы строите.

00:02:04.140 --> 00:02:09.680
Вы же не станете строить дом, не купив сначала участок, верно? Здесь та же идея. IP-адресация и CIDR — выбор

00:02:09.680 --> 00:02:13.040
адресного пространства. Что ж, давайте начнем. Когда вы создаете Винет,

00:02:13.040 --> 00:02:17.580
первое важное решение — выбор диапазона IP-адресов. Это делается с помощью нотации CIDR.

00:02:17.720 --> 00:02:22.060
CIDR расшифровывается как «бесклассовая междоменная маршрутизация», но по сути это просто способ

00:02:22.060 --> 00:02:26.320
сказать «мне нужно столько-то IP-адресов». Почему это важно? Потому что выбранный диапазон

00:02:26.320 --> 00:02:30.680
определяет, сколько ресурсов поместится в вашей виртуальной сети. Вот как это работает.

00:02:30.900 --> 00:02:36.100
CIDR использует косую черту и число. Например, 16 или 24. Это число указывает размер адресного

00:02:36.100 --> 00:02:42.400
пространства. Значение 16 дает вам около 65 000 IP-адресов. Это очень много. Значение 24 дает

00:02:42.400 --> 00:02:46.840
около 250, что идеально подходит для небольшой команды или одного уровня приложения. Поэтому при

00:02:46.840 --> 00:02:51.000
проектировании Винет нужно подумать о количестве ресурсов и о том, как вы хотите их сгруппировать.

00:02:51.180 --> 00:02:55.000
Однако вы не можете выбрать просто любой диапазон IP-адресов. Azure следует стандарту

00:02:55.000 --> 00:03:00.400
RFC 1918, который выделяет частные IP-диапазоны для внутренних сетей. У вас есть три варианта.

00:03:00.560 --> 00:03:07.340
Диапазон 10XXX самый большой, он дает много пространства для роста. Диапазон 172.16XX немного меньше,

00:03:07.340 --> 00:03:12.820
но тоже полезен. А диапазон 192.168XX, вероятно, используется у вас дома на роутере.

00:03:12.960 --> 00:03:16.660
И вот в чем дело. Адресное пространство вашей Винет не должно пересекаться с любой другой сетью,

00:03:16.820 --> 00:03:20.180
которой вы планируете подключиться. Это распространенная ошибка. Многие выбирают

00:03:20.180 --> 00:03:24.080
знакомый диапазон, а потом обнаруживают, что он конфликтует с корпоративной сетью. Поэтому,

00:03:24.280 --> 00:03:29.420
если офисная сеть вашей компании использует 1.0.0.0.0, касая черта 1.6, не используйте тот же диапазон в Azure.

00:03:29.560 --> 00:03:33.220
Если позже вы попытаетесь их соединить, они будут конфликтовать, и трафик не будет знать,

00:03:33.220 --> 00:03:37.420
куда идти. Приведу конкретный пример. Представьте, что вы строите гибридную инфраструктуру,

00:03:37.620 --> 00:03:42.800
где Azure подключается к вашему локальному дата-центру, а в нем используется 1.0.0.0.0,

00:03:42.860 --> 00:03:48.080
касая черта 1.6. Если вы создадите Винет с таким же диапазоном, две сети будут бороться за одни и

00:03:48.080 --> 00:03:52.840
те же IP. Только вдумайтесь, две сети с одним диапазоном IP не смогут нормально взаимодействовать.

00:03:52.980 --> 00:03:57.520
Это как два дома с одним и тем же адресом. Почта придет не туда. Эту проблему лучше не решать

00:03:57.520 --> 00:04:01.760
постфактум. Поэтому планируйте заранее и выбирайте уникальный диапазон. И вот вам совет по планированию.

00:04:01.760 --> 00:04:05.000
Выбирайте диапазон больше, чем, как вам кажется, вам нужно. Возможно, вы думаете,

00:04:05.140 --> 00:04:08.660
что сейчас вам хватит маски 24, но по мере роста приложения вы пожалеете, что не взяли 16.

00:04:08.880 --> 00:04:12.860
Позже это будет нелегко изменить. Когда ваша виртуальная сеть создана и ресурсы развернуты,

00:04:13.020 --> 00:04:16.960
менять адресное пространство крайне неудобно. Это возможно, но вы вряд ли захотите делать это в

00:04:16.960 --> 00:04:21.060
рабочей системе. Поэтому оставьте себе пространство для роста. Что это значит для вас? Представьте

00:04:21.060 --> 00:04:24.600
адресное пространство своей виртуальной сети как покупку земли. Возьмите с запасом для будущего роста.

00:04:24.760 --> 00:04:28.500
Если думаете, что вам нужен небольшой участок, купите средний. Потом скажете себе спасибо.

00:04:28.500 --> 00:04:32.360
Это главный вывод. Планируйте адресное пространство с прицелом на будущее.

00:04:32.520 --> 00:04:36.800
Подсети – разделение вашей сети. Итак, у вас есть виртуальная сеть и выбранное адресное

00:04:36.800 --> 00:04:40.840
пространство. Что дальше? Не стоит просто сваливать все в одну кучу. Вот тут-то и пригодятся

00:04:40.840 --> 00:04:44.460
подсети. Подсети – один из фундаментальных строительных блоков вашей виртуальной сети. Они

00:04:44.460 --> 00:04:48.280
позволяют организовать и обезопасить ваши ресурсы. Подсеть – это меньший раздел адресного

00:04:48.280 --> 00:04:52.780
пространства вашей виртуальной сети. Если виртуальная сеть – это здание, то подсети – это отдельные

00:04:52.780 --> 00:04:56.520
комнаты. Вы ведь не станете размещать серверную, стойку регистрации и комнату отдыха в одном

00:04:56.520 --> 00:05:01.180
общем пространстве, верно? Здесь тот же принцип. Это простая концепция, но она кардинально меняет

00:05:01.180 --> 00:05:05.900
управление сетью. Разные ресурсы помещаются в разные подсети. Веб-серверы в одну подсеть,

00:05:06.160 --> 00:05:11.400
базы данных в другую, прикладная логика в третью. Почему? По двум причинам. Безопасность и

00:05:11.400 --> 00:05:15.100
организация. Давайте сначала поговорим о безопасности, ведь это обычно самое важное.

00:05:15.360 --> 00:05:18.620
Безопасность прежде всего. Если кто-то взломает ваш веб-сервер, вы не захотите,

00:05:18.840 --> 00:05:22.500
чтобы он получил прямой доступ к базе данных. Отдельные подсети создают естественный барьер.

00:05:22.660 --> 00:05:25.480
Злоумышленнику придется преодолеть эту границу, а вы можете точно контролировать,

00:05:25.480 --> 00:05:28.980
что через нее проходит. Вы также можете использовать группы сетевой безопасности для контроля

00:05:28.980 --> 00:05:33.580
трафика между подсетями. Это тема для другого видео, но важно знать, что подсети – основа

00:05:33.580 --> 00:05:38.020
такой безопасности. Теперь об организации. Когда у всего есть свое место, управлять этим

00:05:38.020 --> 00:05:42.920
гораздо проще. Вы знаете, какая подсеть содержит ресурсы внешнего интерфейса, а какая – данные

00:05:42.920 --> 00:05:47.560
бэкенда. Вы можете применять политики и правила ко всей подсети сразу, вместо настройки каждого

00:05:47.560 --> 00:05:51.780
ресурса по отдельности. Это экономит время и уменьшает количество ошибок. А вот деталь,

00:05:51.780 --> 00:05:56.500
которая часто застает врасплох. Азор резервирует 5 IP-адресов в каждой подсети для своих внутренних

00:05:56.500 --> 00:06:01.480
нужд, таких как маршрутизация и DNS. Поэтому, если вы создаете подсеть с маской 24, дающей 256

00:06:01.480 --> 00:06:06.180
адресов, фактически вы получите только 251 доступный. Это распространенная ловушка. Вы планируете

00:06:06.180 --> 00:06:10.780
256, но получаете только 251. Поэтому всегда добавляйте немного запаса при расчете размера подсетей.

00:06:10.940 --> 00:06:14.640
Хорошая новость в том, что подсети можно добавить после создания виртуальной сети. Вы не ограничены

00:06:14.640 --> 00:06:18.920
только теми, что настроили при создании. Поэтому, если вы поймете, что вам нужна отдельная подсеть

00:06:18.920 --> 00:06:22.880
для инструментов управления или мониторинга, добавьте ее позже. Это не проблема. Но все же

00:06:22.880 --> 00:06:27.380
лучше планировать их заранее. Добавлять подсети позже можно, но вам, возможно, придется перемещать

00:06:27.380 --> 00:06:31.500
ресурсы, что может вызвать перебой. Но вот лучшая практика. Используйте отдельные подсети для

00:06:31.500 --> 00:06:35.440
разных уровней вашего приложения с самого начала. Подумайте об архитектуре вашего приложения.

00:06:35.640 --> 00:06:40.560
Обычно у вас есть внешний уровень, обрабатывающий запросы пользователей, внутренний уровень бизнес-логики

00:06:40.560 --> 00:06:45.180
и уровень данных для хранения информации. У каждого из них должна быть своя подсеть. Не ждите перехода

00:06:45.180 --> 00:06:48.700
в продуктивную среду, чтобы понять необходимость разделения компонентов. Это гораздо сложнее,

00:06:48.700 --> 00:06:53.000
когда ресурсы уже развернуты. Что это значит для вас? Подсети помогают поддерживать порядок и

00:06:53.000 --> 00:06:56.980
безопасность в вашей сети. Это как комнаты в вашем здании. Планируйте их заранее и предоставляйте

00:06:56.980 --> 00:07:00.900
каждому уровню приложения свое пространство. Так вы сохраните свою сеть чистой и защищенной.

00:07:01.100 --> 00:07:06.600
Публичные и частные IP-адреса. Кто что видит. Давайте поговорим об IP-адресах, ведь они бывают

00:07:06.600 --> 00:07:11.520
разными. Когда вы развертываете ресурс внутри виртуальной сети, он по умолчанию получает частный IP-адрес.

00:07:11.660 --> 00:07:15.940
Этот адрес используется для связи с другими ресурсами внутри виртуальной сети. Представьте его как

00:07:15.940 --> 00:07:20.340
внутренний телефонный номер. Только люди внутри здания могут по нему позвонить. Частные IP-адреса

00:07:20.340 --> 00:07:24.380
доступны только изнутри виртуальной сети или из подключенных к ней сетей. Если вы сидите дома

00:07:24.380 --> 00:07:28.980
за ноутбуком, вы не сможете подключиться к частному IP в Азур. Его нет в интернете. Он находится

00:07:28.980 --> 00:07:33.520
внутри вашей частной сети. Так как же сделать ресурс доступным из интернета? Вы назначаете ему

00:07:33.520 --> 00:07:38.020
публичный IP-адрес. Этот адрес виден внешнему миру, как опубликованный номер телефона вместо

00:07:38.020 --> 00:07:43.260
внутреннего добавочного. Вот ключевой момент. Публичные IP-адреса необязательны. Вы назначаете их явно,

00:07:43.260 --> 00:07:47.340
потому что Азур никогда не дает ресурсам публичный IP, если вы об этом не просите. Это сделано

00:07:47.340 --> 00:07:51.040
намеренно. По умолчанию должен быть частный адрес, а публичный – это осознанный выбор. И именно

00:07:51.040 --> 00:07:55.380
здесь многие новички совершают ошибку. Они назначают публичные IP-адреса всему подряд. Их веб-сервер,

00:07:55.520 --> 00:07:59.100
база данных и внутренний IP все получают по публичному адресу. Это риск для безопасности.

00:07:59.320 --> 00:08:04.140
Ваша база данных не должна быть доступна из интернета, как и ваш внутренний IP. Публичные IP-адреса должны

00:08:04.140 --> 00:08:07.380
быть только у тех фронтенд-ресурсов, с которыми непосредственно взаимодействуют пользователи.

00:08:07.380 --> 00:08:11.820
Существует два типа публичных IP-адресов – статические и динамические. Статический публичный IP-адрес

00:08:11.820 --> 00:08:15.320
остается неизменным, даже если вы останавливаете и перезапускаете ресурс. Динамический публичный

00:08:15.320 --> 00:08:18.560
IP-адрес может меняться. Если вы запускаете рабочие приложения, вам, скорее всего,

00:08:18.740 --> 00:08:22.060
нужны статические IP, чтобы пользователи всегда могли вас найти. Если вы что-то тестируете,

00:08:22.260 --> 00:08:26.320
динамический IP вполне подойдет. Вы также можете использовать префикс публичного IP-адреса,

00:08:26.440 --> 00:08:29.760
который позволяет зарезервировать блок адресов. Вместо создания адресов по одному,

00:08:29.980 --> 00:08:34.360
вы резервируете диапазон, а затем назначаете отдельные адреса из этого диапазона. Это удобно,

00:08:34.360 --> 00:08:38.480
если вы знаете, что для проекта вам потребуется несколько публичных IP-адресов. Что это значит

00:08:38.480 --> 00:08:42.440
для вас? Приватные IP-адреса – это безопасный выбор по умолчанию. Это ваш внутренний телефонный

00:08:42.440 --> 00:08:46.060
номер. Публичные IP – это осознанный выбор, который вы делаете, только когда ресурс должен

00:08:46.060 --> 00:08:49.800
быть доступен извне. И когда они вам нужны, подумайте, статический или динамический адрес

00:08:49.800 --> 00:08:53.660
выбрать и имеет ли смысл использовать префикс. Группы сетевой безопасности контролируют

00:08:53.660 --> 00:08:58.080
трафик. Итак, вы разобрались с виртуальной сетью, подсетями и IP-адресами. Но как на самом

00:08:58.080 --> 00:09:01.740
деле контролировать, какой трафик разрешен, а какой нет? Здесь на помощь приходят группы

00:09:01.740 --> 00:09:06.200
сетевой безопасности NSG. NSG – это швейцар, который контролирует входящий и исходящий

00:09:06.200 --> 00:09:10.300
трафик ваших ресурсов. Представьте его как охранника на входе в клуб, который проверяет документы,

00:09:10.460 --> 00:09:14.660
сверяется со списком гостей и не пускает тех, кому не положено. Весь трафик, который пытается

00:09:14.660 --> 00:09:19.360
достичь вашего ресурса, сначала должен пройти через этого охранника. NSG работают на основе

00:09:19.360 --> 00:09:24.140
правил. Каждое правило разрешает или запрещает трафик на основе четырех критериев – IP-адрес

00:09:24.140 --> 00:09:29.700
источника, IP-адрес назначения, номер порта и протокол. Например, можно разрешить трафик с IP-адреса

00:09:29.700 --> 00:09:35.560
вашего офиса через порт 443 или запретить весь трафик из интернета через порт 22. Вот такой уровень

00:09:35.560 --> 00:09:40.200
контроля. А вот и мощная функция. Вы можете привязать NSG к подсети или напрямую к сетевому

00:09:40.200 --> 00:09:44.260
интерфейсу отдельной виртуальной машины. Если вы привязываете ее к подсети, NSG применяется

00:09:44.260 --> 00:09:48.720
ко всему, что находится внутри. Каждой виртуальной машине – базе данных и ресурсу. Это общая политика

00:09:48.720 --> 00:09:52.440
безопасности. Если привязать ее к сетевому интерфейсу конкретной машины, она будет действовать

00:09:52.440 --> 00:09:56.800
только для этого устройства. Можно использовать это и другое одновременно. NSG на уровне подсети

00:09:56.800 --> 00:10:00.860
для общих правил и NSG на уровне сетевой карты для исключений. Правила по умолчанию,

00:10:01.060 --> 00:10:04.940
которые создает Azure, довольно разумны. Они разрешают весь трафик внутри виртуальной сети,

00:10:05.120 --> 00:10:08.260
чтобы ресурсы могли взаимодействовать, и блокируют весь входящий трафик из интернета,

00:10:08.400 --> 00:10:11.840
поэтому никто из вне не получит доступ к вашим ресурсам, пока вы сами не разрешите это явно.

00:10:11.940 --> 00:10:15.520
Это хорошая отправная точка. Позвольте привести распространенный пример. Допустим,

00:10:15.640 --> 00:10:19.640
вы управляете виртуальной машиной Linux, и вам нужно подключиться к ней по SSH. Вы создаете правила NSG,

00:10:19.840 --> 00:10:24.260
разрешающие входящий трафик на порт 22. Но вы ведь не хотите разрешать SSH отовсюду. Это напрашивание

00:10:24.260 --> 00:10:27.720
на неприятности, поэтому вы ограничиваете доступ своим IP-адресам, чтобы только вы могли

00:10:27.720 --> 00:10:32.920
подключаться по SSH, а все остальные блокировались. То же самое применимо CarDP на порту 3389 для

00:10:32.920 --> 00:10:37.660
машин с Windows. Что это означает для вас? NSG — это ваш первый рубеж защиты, и самое лучшее — они

00:10:37.660 --> 00:10:41.020
бесплатны. За их использование не взимается дополнительная плата, так что нет причин их не

00:10:41.020 --> 00:10:45.100
настраивать. Каждая подсеть и каждый ресурс должны быть защищены с помощью NSG. Начинайте с запрета

00:10:45.100 --> 00:10:49.560
всего трафика и открывайте только то, что необходимо. Таблица маршрутизации и маршрутизация — направление

00:10:49.560 --> 00:10:52.560
трафика. Теперь давайте поговорим о маршрутизации, ведь как только вы определили,

00:10:52.560 --> 00:10:56.660
какой трафик разрешен, нужно решить, куда он должен направляться. Суть в том, что Azure автоматически

00:10:56.660 --> 00:11:00.960
создает системные маршруты для каждой подсети. Вам не нужно ничего делать. Представьте это как

00:11:00.960 --> 00:11:06.020
встроенный GPS, который знает основные дороги. Трафик внутри виртуальной сети, трафик в пиринговые

00:11:06.020 --> 00:11:10.760
сети, трафик в интернет. Все это работает из коробки, но иногда стандартный GPS ведет не туда,

00:11:10.940 --> 00:11:15.140
куда вам нужно. Вот здесь вам и пригодятся пользовательские маршруты или UDR. Они позволяют

00:11:15.140 --> 00:11:19.000
переопределить системные маршруты Azure и взять под контроль путь прохождения трафика. Как это работает?

00:11:19.000 --> 00:11:23.100
Вы создаете таблицу маршрутизации. Добавляете свои пользовательские маршруты. Затем связываете

00:11:23.100 --> 00:11:26.240
эту таблицу маршрутизации с подсетью. С этого момента трафик, покидающий подсеть,

00:11:26.440 --> 00:11:29.600
будет следовать вашим правилам вместо стандартных. Позвольте привести конкретный пример.

00:11:29.780 --> 00:11:32.820
Допустим, вы хотите, чтобы весь интернет-трафик из вашей виртуальной сети сначала проходил

00:11:32.820 --> 00:11:36.020
через Брандмауэ. Возможно, вам нужно проверять его, регистрировать в журнале или блокировать

00:11:36.020 --> 00:11:39.600
вредоносные сайты. Стандартный системный маршрут отправляет интернет-трафик напрямую.

00:11:39.600 --> 00:11:43.540
Это вас не устраивает, поэтому вы создаете маршрут, согласно которому любой трафик в адрес

00:11:43.540 --> 00:11:48.460
0.0.0.0, то есть в любую точку интернета, должен направляться на Брандмауэ. Это и есть

00:11:48.460 --> 00:11:52.260
пользовательский маршрут. В таблицах маршрутизации используется понятие «следующий переход».

00:11:52.260 --> 00:11:56.240
Это пункт назначения, куда трафик направляется далее. У вас есть несколько вариантов. Вы можете

00:11:56.240 --> 00:11:59.960
отправить его на виртуальное устройство, например, Брандмауэ. Вы можете отправить его на шлюз

00:11:59.960 --> 00:12:04.360
виртуальной сети, именно так происходит подключение к локальным сетям. Вы можете отправить его

00:12:04.360 --> 00:12:08.720
напрямую в интернет или в NAN, что по сути отбрасывает трафик. Важно понимать,

00:12:08.720 --> 00:12:13.200
что маршрутизация – это то, как вы управляете путем прохождения трафика в вашей сети.

00:12:13.400 --> 00:12:17.260
Системные маршруты – это хороший стандарт, но они не всегда подходят для вашей ситуации.

00:12:17.480 --> 00:12:21.340
Если вам нужно, чтобы трафик проходил через точку проверки, конкретный шлюз или был полностью

00:12:21.340 --> 00:12:24.740
заблокирован, вам нужны пользовательские маршруты. Что это значит для вас?

00:12:25.160 --> 00:12:29.200
Маршрутизация – это способ управления трафиком, и вы можете переопределить настройки

00:12:29.200 --> 00:12:34.260
Азура в любой момент. Начните с системных маршрутов, поймите, как они работают, а затем добавляйте

00:12:34.260 --> 00:12:38.220
свои, когда этого требует архитектура. Перинг Ви нет, соединение сетей.

00:12:38.220 --> 00:12:42.880
До сих пор мы говорили об одной Ви нет, одном здании, одной частной сети. Но что происходит,

00:12:43.080 --> 00:12:47.100
когда у вас несколько Ви нет? Может быть, одна для рабочей среды, другая для тестирования,

00:12:47.320 --> 00:12:51.380
или вы запускаете приложения в разных регионах Азу. По умолчанию эти Ви нет полностью

00:12:51.380 --> 00:12:54.820
изолированы. Они не могут взаимодействовать друг с другом. Они как отдельные здания,

00:12:54.920 --> 00:12:59.060
без дорог между ними. Вот здесь и пригодится Перинг Ви нет. Он позволяет объединить две Ви нет в

00:12:59.060 --> 00:13:03.060
частном порядке, именно в частном. Трафик между объединенными Ви нет остается внутри магистральной

00:13:03.060 --> 00:13:06.900
сети Microsoft. Он никогда не выходит в публичный интернет. Это означает низкую задержку,

00:13:06.900 --> 00:13:10.800
высокую пропускную способность и отсутствие внешних угроз. Вот что удивляет многих.

00:13:10.920 --> 00:13:15.480
Перинг работает и между регионами. Это называется глобальным Перингом. Вы можете соединить

00:13:15.480 --> 00:13:19.960
Ви нет в Западной Европе с Ви нет в Юго-Восточной Азии, и трафик останется в частной сети Microsoft.

00:13:20.260 --> 00:13:24.560
Никаких VPN-шлюзов, никаких публичных IP, просто прямое частное соединение. Но есть правила,

00:13:24.700 --> 00:13:28.700
которые нельзя нарушать. У Перинговых Ви нет не должны пересекаться адресные пространства.

00:13:28.880 --> 00:13:34.420
Если обе Ви нет пытаются использовать диапазон 1.0.0.0.0, косая черта 1.6, их нельзя объединить.

00:13:34.420 --> 00:13:38.920
IP-адреса будут конфликтовать, и Азур не поймет, какой сети принадлежит пакет.

00:13:39.020 --> 00:13:43.240
Помните наш ранний совет о тщательном выборе адресного пространства. Вот почему.

00:13:43.520 --> 00:13:47.980
Если вы планируете Перинг в будущем, убедитесь, что диапазоны не пересекаются с самого начала.

00:13:48.160 --> 00:13:52.380
А вот деталь, на которой многие спотыкаются. Перинг нетранзитивен. Что это значит?

00:13:52.580 --> 00:13:57.860
Допустим, Ви нет А соединена с Ви нет Б, а Ви нет Б с Ви нет Си винета не получит доступ к Ви нет С

00:13:57.860 --> 00:14:02.920
через Б автоматически. Они не соединены. Каждый Перинг – это прямая связь ровно между двумя Ви нет.

00:14:02.920 --> 00:14:06.080
Если нужно, чтобы А общалась с С, требуется отдельный Перинг между ними.

00:14:06.200 --> 00:14:09.800
Как же масштабировать это решение? Используйте архитектуру «Звезда» Hub & Spoke.

00:14:09.940 --> 00:14:13.040
Одна центральная виртуальная сеть, концентратор, объединяется с множеством других сетей, периферийных.

00:14:13.160 --> 00:14:17.000
В концентраторе могут находиться общие службы, такие как Брандмауэр, VPN-шлюз или инструменты мониторинга.

00:14:17.100 --> 00:14:19.500
В периферийных сетях размещаются ваши отдельные рабочие нагрузки.

00:14:19.660 --> 00:14:23.000
Каждая периферийная сеть напрямую соединяется с концентратором, но не соединяется с другими периферийными сетями.

00:14:23.000 --> 00:14:26.180
Если периферийной сети нужно связаться с другой, трафик проходит через концентратор.

00:14:26.280 --> 00:14:29.860
Это позволяет поддерживать порядок и централизованное применять политики безопасности.

00:14:30.060 --> 00:14:31.040
Что это значит для вас?

00:14:31.180 --> 00:14:34.620
Перинг – это способ создания сетей, охватывающих несколько виртуальных сетей и регионов.

00:14:34.740 --> 00:14:36.300
Это мост между вашими зданиями.

00:14:36.440 --> 00:14:38.940
Планируйте адресные пространства так, чтобы они не пересекались.

00:14:39.100 --> 00:14:44.300
Помните, что Перинг не является транзитивным, и рассмотрите топологию «Звезда», когда вы перерастаете рамки одной сети.

00:14:44.420 --> 00:14:46.200
Как все это связано? Общая картина.

00:14:46.360 --> 00:14:48.740
Давайте посмотрим, как эти части сочетаются друг с другом.

00:14:48.740 --> 00:14:50.240
В этом заключается настоящая сила.

00:14:50.380 --> 00:14:51.880
Вы начинаете с виртуальной сети «Винет».

00:14:51.880 --> 00:14:53.220
Это ваше личное пространство в АЗУ.

00:14:53.320 --> 00:14:54.720
Представьте его как свой земельный участок.

00:14:54.880 --> 00:14:56.460
Внутри этого участка вы создаете подсети.

00:14:56.600 --> 00:14:57.700
Это ваши «комнаты».

00:14:57.700 --> 00:15:00.580
Одна для веб-серверов, одна для баз данных, одна для инструментов управления.

00:15:00.720 --> 00:15:04.140
Каждая подсеть получает свой блок адресов, выделенный из адресного пространства виртуальной сети.

00:15:04.340 --> 00:15:05.740
Затем вы добавляете безопасность.

00:15:05.920 --> 00:15:08.500
Подсетям подключаются группы сетевой безопасности «НСГ».

00:15:08.500 --> 00:15:10.780
Они контролируют входящий и исходящий трафик.

00:15:10.940 --> 00:15:14.160
Ваша веб-подсеть разрешает трафик из интернета через порт 443.

00:15:18.740 --> 00:15:20.740
Каждой двери точно знает, кому разрешен вход.

00:15:20.900 --> 00:15:22.440
Далее вы настраиваете маршрутизацию.

00:15:22.660 --> 00:15:26.180
Возможно, вы хотите, чтобы весь исходящий интернет-трафик проходил через Брандмауэр для проверки.

00:15:26.320 --> 00:15:29.840
Вы создаете таблицу маршрутов, добавляете пользовательский маршрут и привязываете его к подсетям.

00:15:29.980 --> 00:15:33.260
Теперь трафик следует по созданному вами пути, а не по стандартному пути АЗУ.

00:15:33.380 --> 00:15:35.280
И, наконец, вы соединяете все вместе.

00:15:35.480 --> 00:15:40.600
Вы объединяете свою Винет с другими сетями, возможно, с центральным концентратором, где находятся Брандмауэр и общие службы.

00:15:40.600 --> 00:15:45.100
Теперь ваше приложение охватывает несколько сетей, но работает как единая система.

00:15:45.100 --> 00:15:48.640
Вот тот самый важный момент. Ни один из этих элементов не работает изолированно.

00:15:48.760 --> 00:15:50.860
Виртуальная сеть без подсетей – это просто пустое пространство.

00:15:51.000 --> 00:15:52.740
Подсети без NSG полностью открыты.

00:15:52.960 --> 00:15:55.280
Маршрутизация без четкого плана направляет трафик не туда.

00:15:55.440 --> 00:15:57.420
Peering без планирования создает конфликты адресов.

00:15:57.560 --> 00:15:59.120
Все они представляют собой единую систему.

00:15:59.260 --> 00:16:00.560
Каждый компонент зависит от других.

00:16:00.720 --> 00:16:02.220
Позвольте привести конкретный пример.

00:16:02.380 --> 00:16:03.540
Представьте веб-приложение.

00:16:03.540 --> 00:16:08.240
Ваши веб-серверы находятся в общедоступной подсети с NSG, разрешающей HTTPS трафик из интернета.

00:16:08.240 --> 00:16:12.640
Серверы приложений расположены в частной подсети, которая принимает трафик только от веб-подсети.

00:16:12.840 --> 00:16:17.360
Ваша база данных находится в другой частной подсети, которая принимает трафик только из подсети приложения.

00:16:17.520 --> 00:16:22.080
Таблица маршрутизации направляет весь исходящий трафик через брандмауэр в хаб-сети для журналирования и проверки.

00:16:22.200 --> 00:16:26.140
И все это связано пирингом с вашей корпоративной сетью, чтобы ваша внутренняя команда могла этим управлять.

00:16:26.240 --> 00:16:28.780
В этом и заключается настоящая ценность, а не в какой-то одной функции.

00:16:28.980 --> 00:16:30.480
Важно-то, как все это работает вместе.

00:16:30.480 --> 00:16:34.400
20 лет назад вам пришлось бы покупать отдельные серверы, настраивать физические маршрутизаторы

00:16:34.400 --> 00:16:38.220
и управлять брандмауерами на каждом устройстве. Все было вручную, медленно и дорого.

00:16:38.420 --> 00:16:42.440
Azure предоставляет вам все это как услугу. Вы определяете конфигурацию несколькими кликами

00:16:42.440 --> 00:16:45.980
или скриптом, и все просто работает. Что это значит для вас? Когда вы поймете,

00:16:46.160 --> 00:16:49.500
как эти элементы сочетаются, сетевая инфраструктура Azure станет предсказуемой.

00:16:49.640 --> 00:16:54.060
Вы не гадаете, вы проектируете, и если что-то ломается, вы точно знаете, где искать,

00:16:54.180 --> 00:16:57.860
потому что понимаете систему. Итак, вот что я хочу, чтобы вы вынесли из этого эпизода.

00:16:57.860 --> 00:17:01.600
Во-первых, самый важный шаг, который вы можете сделать. Создайте виртуальную сеть с хорошо

00:17:01.600 --> 00:17:04.860
спланированным адресным пространством до того, как что-либо развертывать. Это единственное решение

00:17:04.860 --> 00:17:08.460
влияет на все, что последует за ним. Во-вторых, используйте подсети для разделения уровней

00:17:08.460 --> 00:17:12.420
вашего приложения. Веб-серверы, серверы приложений, базы данных выделите для каждого свое место.

00:17:12.580 --> 00:17:17.720
И в-третьих, начните с NSG. Они бесплатны, они эффективны и значительно улучшают вашу безопасность

00:17:17.720 --> 00:17:22.200
с первого дня. Ваша виртуальная сеть – это фундамент всего, что вы строите в Azure. Сделайте ее правильно,

00:17:22.200 --> 00:17:26.580
и все остальное станет проще. Сделайте ошибку, и вы будете тратить все свое время на борьбу с сетью.

00:17:26.720 --> 00:17:29.400
Подпишитесь на своей любимой платформе для подкастов и поделитесь этим с тем,

00:17:29.520 --> 00:17:32.900
кто только начинает свой путь в Azure. Оставьте комментарий, если вы что-то для себя открыли.

00:17:33.060 --> 00:17:34.420
Увидимся в следующем эпизоде.