WEBVTT

00:00:00.000 --> 00:00:01.780
Що таке віртуальна мережа Azure?

00:00:01.960 --> 00:00:08.560
Більшість людей, почувши цей термін, думають, що це просто чергове налаштування при розгортанні віртуальної машини, яке ви обираєте і одразу забуваєте.

00:00:08.720 --> 00:00:09.840
Але ось у чому правда.

00:00:10.120 --> 00:00:12.420
Віртуальна мережа Azure – це не просто налаштування.

00:00:12.600 --> 00:00:14.680
Це основа всього, що ви будуєте в Azure.

00:00:14.860 --> 00:00:20.240
Кожна віртуальна машина, кожна база даних, кожен сервіс додатків, кожна функція, яку ви розгортаєте, усе це розміщується всередині неї.

00:00:20.380 --> 00:00:23.540
І якщо ви не розумієте, як вони працюють, ви дієте на осліп.

00:00:23.540 --> 00:00:29.620
До кінця цього епізоду ви зрозумієте, що таке в нет насправді, як вона працює і чому кожен ваш ресурс залежить від неї.

00:00:29.740 --> 00:00:35.320
Ми розглянемо, що таке в нет, як працюють IP-адреси, підмережі, безпека, маршрутизація та як з'єднувати мережі в нет між собою.

00:00:35.460 --> 00:00:36.920
Беріть каву і почнемо.

00:00:37.060 --> 00:00:37.960
Що таке в нет?

00:00:38.120 --> 00:00:39.480
Приватна хмарна мережа.

00:00:39.600 --> 00:00:41.540
Почнемо з найпростішого визначення.

00:00:41.760 --> 00:00:46.240
Віртуальна мережа Azure або скорочено в нет – це ваша власна приватна мережа всередині Azure.

00:00:46.400 --> 00:00:48.480
Уявіть її як приватний офісний будинок.

00:00:48.480 --> 00:00:50.540
Тільки ті, кому ви дозволили, можуть увійти.

00:00:50.720 --> 00:00:54.780
Ви контролюєте, хто входить, хто має доступ до певного поверху і кому вхід заборонено взагалі.

00:00:54.940 --> 00:00:56.680
До появи в нет усе було інакше.

00:00:56.920 --> 00:01:00.940
Розгортаючи віртуальну машину в хмарі, ви фактично виставляли її на огляд інтернету за замовчуванням.

00:01:01.080 --> 00:01:02.560
Без приватної мережі навколо неї.

00:01:02.740 --> 00:01:04.820
Будь-хто, хто знав IP-адресу, міг спробувати підключитися.

00:01:04.960 --> 00:01:06.520
Це був справжній кошмар для безпеки.

00:01:06.640 --> 00:01:07.440
Що змінилося?

00:01:07.440 --> 00:01:10.420
Azure дала вам можливість створювати ізольовані приватні мережеві простори.

00:01:10.540 --> 00:01:11.820
Ви самі визначаєте межі.

00:01:11.960 --> 00:01:13.460
Ви вирішуєте, що буде всередині.

00:01:13.560 --> 00:01:16.540
Ніщо за межами цього кордону не зможе потрапити всередину, якщо ви явно це не дозволите.

00:01:16.700 --> 00:01:19.640
Варто відразу зазначити, що ваша в нет існує в межах конкретного регіону Azure.

00:01:19.820 --> 00:01:20.840
Вона не є глобальною.

00:01:21.020 --> 00:01:23.340
Створивши в нет у Західній Європі, вона там і залишається.

00:01:23.500 --> 00:01:25.840
Ресурси з іншого регіону не можуть просто підключитися до неї.

00:01:25.840 --> 00:01:28.680
Їм знадобиться власна в нет, або вам доведеться з'єднувати їх пізніше.

00:01:28.800 --> 00:01:31.520
Коли ви створюєте в нет, ви самі визначаєте простір IP-адрес.

00:01:31.660 --> 00:01:33.040
Azure не обирає його за вас.

00:01:33.200 --> 00:01:36.020
Ви самі вирішуєте діапазон IP-адрес, які використовуватимуть ваші ресурси.

00:01:36.120 --> 00:01:39.580
Це велика відповідальність, і ми поговоримо про те, як зробити це правильно в наступному розділі.

00:01:39.700 --> 00:01:40.840
Ось головний висновок.

00:01:40.960 --> 00:01:42.160
В нет – це фундамент.

00:01:42.320 --> 00:01:48.440
Кожна віртуальна машина, кожна база даних, кожна функція Azure, яку ви розгортаєте, знаходиться всередині такої мережі.

00:01:48.440 --> 00:01:51.520
Без в нет ваші ресурси не мають контексту приватної мережі.

00:01:51.660 --> 00:01:55.340
Вони просто плавають у хмарі без кордонів, без ізоляції та без безпеки.

00:01:55.460 --> 00:01:56.880
То що це означає для вас?

00:01:57.060 --> 00:02:01.540
Якщо ви створюєте щось в Azure, почніть спочатку з в нет, не після розгортання ресурсів, а до нього.

00:02:01.760 --> 00:02:03.980
Ваша в нет – це земельна ділянка, на якій ви будуєте.

00:02:04.120 --> 00:02:06.420
Ви ж не будете будувати будинок, не купивши спочатку землю, правда?

00:02:06.600 --> 00:02:07.680
Тут така сама ідея.

00:02:07.820 --> 00:02:10.580
IP-адреса C&A та CIDR – вибір адресного простору.

00:02:10.700 --> 00:02:12.140
Отже, давайте заглибимося.

00:02:12.140 --> 00:02:15.420
Коли ви створюєте в нет, першим важливим рішенням є вибір IP-діапазону.

00:02:15.540 --> 00:02:17.740
Це робиться за допомогою нотації CIDR.

00:02:18.040 --> 00:02:23.780
CIDR – це скорочення від Classless IntedomainRoutine, що по суті означає «мені потрібно стільки IP-адрес».

00:02:23.780 --> 00:02:24.820
Чому це важливо?

00:02:24.980 --> 00:02:29.580
Тому що обраний діапазон визначає, скільки ресурсів можна розмістити у віртуальній мережі.

00:02:29.720 --> 00:02:30.740
Ось як це працює.

00:02:30.920 --> 00:02:34.160
CIDR використовує скісну риску та число як от 16 або 24.

00:02:34.520 --> 00:02:36.680
Це число вказує на розмір адресного простору.

00:02:36.680 --> 00:02:40.080
Значення 16-тьох дає вам близько 65 000 IP-адрес.

00:02:40.200 --> 00:02:41.180
Це дуже багато.

00:02:41.380 --> 00:02:46.260
Значення 24 дає близько 250, що ідеально для невеликої команди або одного рівня застосунку.

00:02:46.400 --> 00:02:51.000
Тож при проєктуванні в нет потрібно думати, скільки ресурсів у вас буде і як ви хочете їх групувати.

00:02:51.200 --> 00:02:53.700
Тепер ви не можете вибрати будь-який IP-діапазон.

00:02:53.840 --> 00:02:59.140
Azure дотримується стандарту RFC 1918, який резервує приватні IP-діапазони для внутрішніх мереж.

00:02:59.280 --> 00:03:00.420
У вас є три варіанти.

00:03:00.600 --> 00:03:04.280
Діапазон 10XXX – найбільший, він дає багато простору для зростання.

00:03:04.280 --> 00:03:08.080
Діапазон 172-16XX – дещо менший, але теж корисний.

00:03:08.220 --> 00:03:12.780
А діапазон 192-168XX – той, який у вас, ймовірно, вдома на роутері.

00:03:12.880 --> 00:03:13.840
Ось у чому справа.

00:03:13.960 --> 00:03:17.960
Адресний простір вашої в нет не повинен перекриватися з жодною іншою мережею, до якої ви плануєте підключатися.

00:03:18.120 --> 00:03:19.280
Це поширена помилка.

00:03:19.500 --> 00:03:23.720
Багато хто обирає звичний діапазон, лише щоб пізніше виявити конфлікт із корпоративною мережею.

00:03:23.720 --> 00:03:29.440
Тож, якщо офісна мережа вашої компанії використовує 10.0.0.0 коса риска 16, не використовуйте такий самий діапазон вежур.

00:03:29.560 --> 00:03:33.440
Якщо ви спробуєте з'єднати їх пізніше, вони конфліктуватимуть, і трафік не знатиме, куди йти.

00:03:33.640 --> 00:03:35.360
Дозвольте навести конкретний приклад.

00:03:35.520 --> 00:03:43.640
Уявіть, що ви будуєте гібридну конфігурацію, де ежур підключається до вашого локального дата-центру, а він використовує 10.0.0.0 коса риска 16.

00:03:43.900 --> 00:03:48.300
Якщо ви створите в нет з таким самим діапазоном, матимете дві мережі, що змагаються за однакові IP.

00:03:48.300 --> 00:03:52.880
Подумайте про це. Дві мережі, що використовують один IP-діапазон, не можуть повноцінно спілкуватися.

00:03:53.040 --> 00:03:54.920
Це як два будинки з однаковою адресою.

00:03:55.080 --> 00:03:58.340
Пошта плутається. Це проблема, яку ви не захочете вирішувати постфактум.

00:03:58.460 --> 00:04:00.440
Тож, плануйте заздалегідь і вибирайте унікальний діапазон.

00:04:00.560 --> 00:04:04.140
І ось порада щодо планування. Обирайте більший діапазон, ніж, на вашу думку, вам потрібно.

00:04:04.280 --> 00:04:08.520
Можливо, ви думаєте, що зараз вам достатньо маски 24, але з розвитком програми ви пошкодуєте, що не взяли 16.

00:04:08.920 --> 00:04:10.580
Змінити це пізніше буде непросто.

00:04:18.300 --> 00:04:20.660
Простір для розвитку. Що це означає для вас?

00:04:20.780 --> 00:04:23.000
Уявіть адресний простір вашої внет як купівлю земельної ділянки.

00:04:23.180 --> 00:04:24.600
Беріть достатньо для майбутнього росту.

00:04:24.760 --> 00:04:27.000
Якщо вважаєте, що потрібна мала ділянка, купуйте середню.

00:04:27.140 --> 00:04:28.460
Ви подякуєте собі пізніше.

00:04:28.620 --> 00:04:29.720
Це головний висновок.

00:04:29.880 --> 00:04:32.520
Плануйте адресний простір із розрахунком на майбутнє.

00:04:32.760 --> 00:04:34.520
Підмережі. Поділ вашої мережі.

00:04:34.640 --> 00:04:37.140
Отже, у вас є внет і ви обрали адресний простір.

00:04:37.140 --> 00:04:39.860
Що далі? Не можна просто звалити все в одну купу.

00:04:39.980 --> 00:04:41.420
Ось тут і з'являються підмережі.

00:04:41.420 --> 00:04:44.000
Підмережі. Це один із фундаментальних блоків вашої внет.

00:04:44.180 --> 00:04:46.780
Вони дозволяють організовувати та захищати ваші ресурси.

00:04:46.900 --> 00:04:49.840
Підмережа. Це менша частина адресного простору вашої внет.

00:04:50.020 --> 00:04:52.960
Якщо внет – це будівля, то підмережі – це окремі кімнати.

00:04:53.180 --> 00:04:57.440
Ви ж не розмістили б сервер, стіл реєстрації та кімнату відпочинку в одному відкритому просторі.

00:04:57.560 --> 00:04:58.620
Тут та сама ідея.

00:04:58.620 --> 00:05:02.000
Це проста концепція, але вона кардинально змінює управління мережею.

00:05:02.120 --> 00:05:04.420
Різні ресурси розміщуються в різних підмережах.

00:05:04.420 --> 00:05:09.000
Веб-сервери – в одній підмережі, бази даних – в іншій, а логіка за стосунку – в третій.

00:05:09.140 --> 00:05:12.160
Чому? Дві причини – безпека та організація.

00:05:12.300 --> 00:05:14.900
Почнімо з безпеки, бо це зазвичай найважливіше.

00:05:15.080 --> 00:05:16.280
Безпека понад усе.

00:05:16.420 --> 00:05:20.340
Якщо хтось зламає ваш веб-сервер, ви не хочете, щоб він отримав прямий доступ до бази даних.

00:05:20.340 --> 00:05:22.520
Окремі підмережі створюють природний бар'єр.

00:05:22.620 --> 00:05:26.200
Зловмиснику доведеться перетнути цей кордон, і ви можете контролювати, що саме його перетинає.

00:05:26.360 --> 00:05:29.920
Ви також можете використовувати групи мережової безпеки для контролю трафіку між підмережами.

00:05:30.060 --> 00:05:34.480
Це тема для іншого відео, але важливо знати, що підмережі є основою цієї безпеки.

00:05:34.680 --> 00:05:36.000
Друге – організація.

00:05:36.180 --> 00:05:38.760
Коли все має своє місце, керувати цим простіше.

00:05:38.960 --> 00:05:43.080
Ви знаєте, яка підмережа містить інтерфейсні ресурси, а яка – серверні дані.

00:05:43.080 --> 00:05:48.640
Ви можете застосовувати політики та правила до всієї підмережі одразу, замість налаштування кожного ресурсу окремо.

00:05:48.760 --> 00:05:51.060
Це економить час і зменшує кількість помилок.

00:05:51.060 --> 00:05:53.480
Тепер деталь, яка часто стає несподіванкою.

00:05:53.620 --> 00:05:58.360
Azure резервує 5 IP-адрес у кожній підмережі для внутрішніх потреб, таких як маршрутизація та DNS.

00:05:58.560 --> 00:06:04.300
Тож, якщо ви створите підмережу з діапазоном 24, що дає 256 адрес, ви отримаєте лише 251 корисну.

00:06:04.440 --> 00:06:05.500
Це поширена пастка.

00:06:05.680 --> 00:06:08.160
Ви плануєте на 256, а отримуєте лише 251.

00:06:08.160 --> 00:06:10.760
Тож, завжди додавайте трохи запасу, коли визначаєте розмір підмереж.

00:06:10.860 --> 00:06:13.880
Хороша новина в тому, що підмережі можна додавати після створення віртуальної мережі.

00:06:13.880 --> 00:06:16.400
Ви не обмежені тими, що налаштували під час створення.

00:06:16.540 --> 00:06:21.160
Тож, якщо зрозумієте, що потрібна окрема підмережа для інструментів керування чи моніторингу, додасте пізніше.

00:06:21.320 --> 00:06:22.120
Це не проблема.

00:06:22.340 --> 00:06:23.880
Але все ж краще спланувати їх заздалегідь.

00:06:24.580 --> 00:06:28.660
Додавати підмережі згодом можна, але доведеться переміщати ресурси, а це може спричинити збої.

00:06:28.800 --> 00:06:30.160
Але ось найкраща практика.

00:06:30.340 --> 00:06:33.520
Використовуйте окремі підмережі для різних рівнів вашого застосунку від самого початку.

00:06:33.660 --> 00:06:35.760
Подумайте про архітектуру свого застосунку.

00:06:35.760 --> 00:06:42.040
Зазвичай є фронтенд для запитів користувачів, бекенд для бізнес-логіки та рівень даних для їх зберігання.

00:06:42.220 --> 00:06:44.420
Кожен із них повинен мати власну підмережу.

00:06:44.560 --> 00:06:47.500
Не чекайте виходу в продакшні, щоб зрозуміти, що все треба розділяти.

00:06:47.660 --> 00:06:49.940
Це значно складніше, коли ресурси вже розгорнуті.

00:06:50.120 --> 00:06:51.320
Що це означає для вас?

00:06:51.440 --> 00:06:54.000
Підмережі – це спосіб зробити мережу впорядкованою та безпечною.

00:06:54.120 --> 00:06:55.600
Це наче кімнати у вашій будівлі.

00:06:55.600 --> 00:06:58.480
Плануйте їх заздалегідь і надайте кожному рівню застосунку власний простір.

00:06:58.480 --> 00:07:00.840
Так ви забезпечите чистоту та безпеку своєї мережі.

00:07:00.940 --> 00:07:02.700
Публічні та приватні IP-адреси.

00:07:02.860 --> 00:07:04.140
Хто і що може бачити?

00:07:04.320 --> 00:07:07.140
Поговоримо про IP-адреси, бо вони не всі однакові.

00:07:07.300 --> 00:07:11.500
Коли ви розгортаєте ресурс у віртуальній мережі, він типово отримує приватну IP-адресу.

00:07:11.640 --> 00:07:15.000
Це адреса для зв'язку з іншими ресурсами всередині віртуальної мережі.

00:07:15.140 --> 00:07:17.120
Уявіть це як внутрішній номер телефону.

00:07:17.120 --> 00:07:19.260
Його можуть набрати лише ті, хто в будівлі.

00:07:19.260 --> 00:07:23.260
Приватні IP доступні лише зсередини віртуальної мережі або з підключених до неї мереж.

00:07:23.380 --> 00:07:26.920
Якщо ви вдома з ноутбуком, ви не отримаєте доступу до приватної IP-адреси Azure.

00:07:27.160 --> 00:07:28.340
Її немає в інтернеті.

00:07:28.520 --> 00:07:30.360
Вона всередині вашої приватної мережі.

00:07:30.460 --> 00:07:32.600
Тож як зробити ресурс доступним з інтернету?

00:07:32.720 --> 00:07:34.620
Ви надаєте йому публічну IP-адресу.

00:07:34.760 --> 00:07:39.060
Це адреса, видима зовнішньому світу, ніби публічний номер телефону замість внутрішнього номера.

00:07:39.220 --> 00:07:40.240
Ось ключовий момент.

00:07:40.440 --> 00:07:42.080
Публічні IP – це опціонально.

00:07:42.080 --> 00:07:46.680
Ви призначаєте їх явно, бо Azure ніколи не дає ресурсів публічну IP, доки ви не попросите.

00:07:46.800 --> 00:07:47.640
Так і задумано.

00:07:47.800 --> 00:07:50.580
Типово все має бути приватним, а публічним – лише за свідомим вибором.

00:07:50.680 --> 00:07:52.640
І саме тут багато новачків припускаються помилки.

00:07:52.820 --> 00:07:54.800
Вони призначають публічні IP усім ресурсам.

00:07:54.940 --> 00:07:57.760
Веб-сервер, база даних, бекендарі – усе отримує таку адресу.

00:07:57.880 --> 00:07:59.140
Це ризик для безпеки.

00:07:59.300 --> 00:08:02.840
Ваша база даних не має бути доступною з інтернету, як і ваш бекендарі.

00:08:02.840 --> 00:08:07.460
Лише зовнішні ресурси, з якими безпосередньо взаємодіють користувачі, повинні мати публічні IP-адреси.

00:08:07.600 --> 00:08:10.460
Публічні IP-адреси бувають двох типів – статичні та динамічні.

00:08:10.620 --> 00:08:14.260
Статична публічна IP-адреса залишається незмінною, навіть якщо ви зупиняєте та перезапускаєте ресурс.

00:08:14.360 --> 00:08:16.380
Динамічна публічна IP-адреса може змінюватися.

00:08:16.540 --> 00:08:20.840
Якщо ви запускаєте робочий додаток, вам, швидше за все, потрібні статичні IP, щоб користувачі завжди могли вас знайти.

00:08:20.840 --> 00:08:23.720
Якщо ви щось тестуєте, динамічної IP може бути достатньо.

00:08:23.840 --> 00:08:28.260
Ви також можете використовувати так званий префікс публічних IP, який дозволяє резервувати блок-адрес.

00:08:28.420 --> 00:08:33.640
Замість створення по одній, ви резервуєте діапазон, а потім призначаєте окремі адреси з цього діапазону.

00:08:33.760 --> 00:08:37.520
Це корисно, якщо ви знаєте, що для проєкту знадобиться багато публічних IP-адрес.

00:08:37.660 --> 00:08:38.900
Що це означає для вас?

00:08:39.040 --> 00:08:41.180
Приватні IP-адреси – це безпечний варіант за замовчуванням.

00:08:41.280 --> 00:08:42.740
Вони як внутрішній телефонний номер.

00:08:42.740 --> 00:08:46.660
Публічні IP – це свідомий вибір, який ви робите лише тоді, коли ресурс має бути доступним ззовні.

00:08:46.780 --> 00:08:51.640
І коли вони вам потрібні, подумайте, чи потрібні вам статичні або динамічні адреси і чи доцільно використовувати префікс.

00:08:51.740 --> 00:08:53.900
Групи мережевої безпеки контролюють трафік.

00:08:54.000 --> 00:08:57.560
Отже, ви розібралися зі своєю віртуальною мережею, внет, під мережами та IP-адресами.

00:08:57.680 --> 00:09:00.460
Але як насправді контролювати, який трафік дозволено, а який – ні?

00:09:00.620 --> 00:09:03.020
Саме для цього існують групи мережевої безпеки – NSD.

00:09:03.020 --> 00:09:07.140
NSD – це охоронець, який контролює трафік, що входить до ваших ресурсів і виходить із них.

00:09:07.260 --> 00:09:13.100
Уявіться, як вишибало в клубі, він перевіряє посвідчення, звіряється зі списком гостей і не пускає тих, кого там не повинно бути.

00:09:13.280 --> 00:09:17.840
Будь-який трафік, що намагається потрапити до вашого ресурсу, спочатку має пройти через цього вишибалу.

00:09:17.940 --> 00:09:19.740
NSD працюють на основі правил.

00:09:19.900 --> 00:09:27.320
Кожне правило дозволяє або забороняє доступ на основі чотирьох параметрів – вихідна IP-адреса, цільова IP-адреса, номер порту та протокол.

00:09:27.320 --> 00:09:34.380
Наприклад, можна дозволити трафік з IP-адреси офісу на порт 443 або заборонити весь інтернет-трафік на порт 22.

00:09:34.620 --> 00:09:35.960
Ось такий рівень контролю.

00:09:36.080 --> 00:09:37.440
А ось і потужна функція.

00:09:37.600 --> 00:09:41.860
Ви можете приєднати NSD до підмережі або безпосередньо до мережового інтерфейсу окремої віртуальної машини.

00:09:41.860 --> 00:09:45.420
Якщо ви приєднуєте NSD до підмережі, вона застосовується до всього, що знаходиться всередині.

00:09:45.520 --> 00:09:47.900
До кожної віртуальної машини, кожної бази даних, кожного ресурсу.

00:09:47.980 --> 00:09:49.400
Це загальна політика для всіх.

00:09:49.400 --> 00:09:53.420
Якщо ви приєднуєте її до інтерфейсу конкретної віртуальної машини, вона діє лише на цей пристрій.

00:09:53.600 --> 00:09:55.340
Можна зробити навіть і те, і інше.

00:09:55.480 --> 00:09:59.840
NSD на рівні підмережі для загальних правил і NSD на рівні мережової карти для винятків.

00:09:59.980 --> 00:10:02.940
Правила за замовчуванням, які створює Azure, досить розумні.

00:10:02.940 --> 00:10:08.440
Вони дозволяють увесь трафік усередині в нет, щоб ваші ресурси могли взаємодіяти і блокують увесь трафік з інтернету,

00:10:08.500 --> 00:10:11.860
тому нічого ззовні не потрапить до ваших ресурсів, доки ви явно це не дозволите.

00:10:12.040 --> 00:10:13.220
Це хороший початок.

00:10:13.220 --> 00:10:14.940
Дозвольте навести поширений приклад.

00:10:15.060 --> 00:10:18.440
Припустимо, ви керуєте віртуальною машиною Linux, і вам потрібно підключитися до неї через SSH.

00:10:18.600 --> 00:10:23.620
Ви створите правило NSD, яке дозволяє вхідний трафік через порт 22, але ви ж не хочете дозволяти SSH звідусіль.

00:10:23.740 --> 00:10:24.760
Це просити біди.

00:10:24.760 --> 00:10:29.820
Тому ви обмежуєте доступ лише до власної IP-адреси, щоб тільки ви могли підключитися через SSH, а решта були заблоковані.

00:10:29.920 --> 00:10:33.400
Те саме стосується RDP через порт 3389 для машин на Windows.

00:10:33.620 --> 00:10:34.860
Що це означає для вас?

00:10:34.860 --> 00:10:38.140
NSD – це ваш перший рубіж оборони і найприємніше те, що вони безкоштовні.

00:10:38.280 --> 00:10:41.380
За їх використання немає додаткової плати, тож немає причин їх не налаштовувати.

00:10:41.580 --> 00:10:44.180
Кожна підмережа, кожен ресурс повинні мати підключено NSD.

00:10:44.320 --> 00:10:47.140
Починайте з правила «Заборонити все» і відкривайте лише те, що потрібно.

00:10:47.140 --> 00:10:50.000
Таблиці маршрутизації та маршрутизація – спрямування трафіку.

00:10:50.120 --> 00:10:54.940
Тепер поговоримо про маршрутизацію, адже коли ви вирішили, який трафік дозволено, потрібно вирішити, куди саме він йде.

00:10:54.940 --> 00:10:58.560
Річ у тім, що Azure автоматично створює системні маршрути для кожної підмережі.

00:10:58.680 --> 00:11:00.100
Вам не потрібно нічого робити.

00:11:00.280 --> 00:11:03.420
Уявіть це як навігатор за замовчуванням, який знає основні шляхи.

00:11:03.540 --> 00:11:07.240
Трафік усередині в нет, трафік до пірингових в нет, трафік до інтернету.

00:11:07.240 --> 00:11:11.520
Усе це працює з коробки, але іноді стандартний навігатор не веде вас туди, куди потрібно.

00:11:11.680 --> 00:11:14.480
Саме тоді вам потрібні визначені користувачем маршрути або UDR.

00:11:14.660 --> 00:11:18.200
Вони дозволяють перекрити системні маршрути Azure і взяти під контроль шлях, яким йде трафік.

00:11:18.200 --> 00:11:19.080
Як це працює?

00:11:19.220 --> 00:11:20.720
Ви створюєте таблицю маршрутизації.

00:11:20.880 --> 00:11:22.240
Ви додаєте свої власні маршрути.

00:11:22.360 --> 00:11:24.540
Потім ви пов'язуєте цю таблицю маршрутизації з підмережею.

00:11:24.680 --> 00:11:27.920
З цього моменту трафік, що залишає підмережу, слідує вашим правилам замість стандартних.

00:11:28.080 --> 00:11:29.680
Дозвольте навести конкретний приклад.

00:11:29.680 --> 00:11:33.240
Скажімо, ви хочете, щоб увесь інтернет-трафік з вашої в нет спочатку проходив через BrandMauer.

00:11:33.420 --> 00:11:36.520
Можливо, вам потрібно перевірити його, записати в журнал або заблокувати шкідливі сайти.

00:11:36.520 --> 00:11:39.780
Стандартний системний маршрут відправляє інтернет-трафік безпосередньо назовні.

00:11:39.900 --> 00:11:42.680
Це не те, що вам потрібно, тому ви створюєте маршрут, який вказує,

00:11:42.840 --> 00:11:47.620
що будь-який трафік на 0.0.0.0, тобто будь-куди в інтернеті, має йти через BrandMauer.

00:11:47.800 --> 00:11:49.580
Це і є визначений користувачем маршрут.

00:11:49.580 --> 00:11:52.320
Таблиці маршрутизації використовують поняття «Наступний перехід».

00:11:52.320 --> 00:11:54.500
Це пункт призначення, куди трафік відправляється далі.

00:11:54.600 --> 00:11:55.780
У вас є кілька варіантів.

00:11:55.920 --> 00:11:58.520
Ви можете надіслати його на віртуальний пристрій, наприклад, BrandMauer.

00:11:58.520 --> 00:12:00.720
Ви можете надіслати його на шлюз віртуальної мережі,

00:12:00.820 --> 00:12:03.120
за допомогою якого ви підключаєтеся до локальних мереж.

00:12:03.240 --> 00:12:06.140
Ви можете спрямувати його прямо в інтернет або на NAN,

00:12:06.320 --> 00:12:07.900
що фактично відкидає трафік.

00:12:08.040 --> 00:12:10.600
Головне, що варто зрозуміти, маршрутизація –

00:12:10.600 --> 00:12:13.080
це спосіб контролю шляху трафіку у вашій мережі.

00:12:13.240 --> 00:12:15.380
Системні маршрути – це гарний варіант за замовчуванням,

00:12:15.440 --> 00:12:17.320
але вони не завжди підходять для вашої ситуації.

00:12:17.520 --> 00:12:19.920
Якщо вам потрібно, щоб трафік проходив через пункт перевірки,

00:12:20.020 --> 00:12:21.340
певний шлюз або був заблокований,

00:12:21.340 --> 00:12:23.280
вам потрібні визначені користувачем маршрути.

00:12:23.440 --> 00:12:24.820
Що це означає для вас?

00:12:25.240 --> 00:12:27.320
Маршрутизація – це спосіб вказати трафіку шлях,

00:12:27.400 --> 00:12:30.300
і ви можете перевизначити налаштування Azure, коли це необхідно.

00:12:30.420 --> 00:12:33.240
Почніть із системних маршрутів, зрозумійте їхню роботу,

00:12:33.320 --> 00:12:36.220
а потім додавайте власні, коли цього вимагає архітектура.

00:12:36.380 --> 00:12:38.200
Peering внет – з'єднання мереж.

00:12:38.340 --> 00:12:41.920
Досі ми говорили про одну внет, одна будівля, одна приватна мережа.

00:12:42.040 --> 00:12:44.080
Але що робити, коли у вас є кілька внет?

00:12:44.240 --> 00:12:47.160
Можливо, одна для продуктового середовища, інша для тестування,

00:12:47.160 --> 00:12:49.640
або ж ви запускаєте застосунки в різних регіонах Azure.

00:12:49.800 --> 00:12:51.880
За замовчуванням, ці внет повністю ізольовані.

00:12:52.020 --> 00:12:53.760
Вони не можуть взаємодіяти одна з одною.

00:12:53.900 --> 00:12:55.640
Вони як окремі будівлі без доріг між ними.

00:12:55.820 --> 00:12:57.420
Ось тут і стає в пригоді Peering внет.

00:12:57.560 --> 00:12:59.100
Він дозволяє з'єднати дві внет приватно,

00:12:59.160 --> 00:13:00.520
і я маю на увазі справді приватно.

00:13:00.640 --> 00:13:03.520
Трафік між піренговими внет залишається в магістральній мережі Microsoft.

00:13:03.800 --> 00:13:05.600
Він ніколи не виходить у публічний інтернет.

00:13:05.600 --> 00:13:08.060
Це означає низьку затримку, високу пропускну здатність

00:13:08.060 --> 00:13:09.280
і відсутність зовнішніх загроз.

00:13:09.400 --> 00:13:10.740
Ось що дивує багатьох.

00:13:10.860 --> 00:13:12.620
Peering працює і між регіонами.

00:13:12.780 --> 00:13:14.520
Це називається глобальним Peeringом.

00:13:14.700 --> 00:13:16.500
Ви можете об'єднати внет у Західній Європі

00:13:16.500 --> 00:13:17.820
з внет у Південно-Східній Азії,

00:13:17.920 --> 00:13:20.140
і трафік між ними залишиться в приватній мережі Microsoft.

00:13:20.360 --> 00:13:22.280
Жодних VPN-шлюзів, жодних публічних IP,

00:13:22.480 --> 00:13:23.640
лише пряме приватне з'єднання.

00:13:23.780 --> 00:13:25.740
Але є правило, яке ви не можете порушити.

00:13:25.740 --> 00:13:28.660
Внет у Peeringу повинні мати адреси, що не перетинаються.

00:13:28.660 --> 00:13:30.840
Якщо обидві внет намагаються використати діапазон

00:13:30.840 --> 00:13:34.480
10.0.0.0 Коса Риска 16, їх не можна об'єднати.

00:13:34.620 --> 00:13:37.240
Виникне конфлікт IP-адрес, і Ажур не знатиме,

00:13:37.340 --> 00:13:38.740
якій мережі належить пакет.

00:13:38.980 --> 00:13:42.260
Пам'ятаєте пораду про ретельне планування адресного простору?

00:13:42.400 --> 00:13:43.460
Ось чому це важливо.

00:13:43.660 --> 00:13:45.740
Якщо плануєте Peering у майбутньому, переконайтеся,

00:13:45.740 --> 00:13:47.980
що їхні діапазони не перетинаються з самого початку.

00:13:48.120 --> 00:13:50.120
А ось деталь, на якій багато хто помиляється.

00:13:50.240 --> 00:13:51.560
Peering не є транзитивним.

00:13:51.740 --> 00:13:52.760
Що це означає?

00:13:52.760 --> 00:13:54.800
Припустимо, Внет-Ай з'єднана з Внет-Бі,

00:13:54.900 --> 00:13:58.620
а Внет-Бі з Внет-Сі Внет-Ай не отримує автоматичного доступу до Внет-Сі,

00:13:58.720 --> 00:13:59.980
через Бі вони не з'єднані.

00:14:00.120 --> 00:14:02.660
Кожен Peering – це пряме посилання рівно між двома Внет.

00:14:02.820 --> 00:14:05.740
Якщо ви хочете, щоб взаємоді ЛСС, потрібен окремий Peering між ними.

00:14:05.940 --> 00:14:07.520
Як же керувати цим у великих масштабах?

00:14:07.620 --> 00:14:09.600
Ви використовуєте архітектуру Hub і Spoki, Hub & Spoke.

00:14:09.600 --> 00:14:11.240
Одна центральна віртуальна мережа – VNT, Hub,

00:14:11.240 --> 00:14:13.500
з'єднується з багатьма іншими Внет-Периферійними мережами – Spokes.

00:14:13.660 --> 00:14:17.060
Hub може містити спільні сервіси, такі як BrandMoware, VPN-шлюз або інструменти моніторингу.

00:14:17.180 --> 00:14:19.460
Периферійні мережі містять ваші окремі робочі навантаження.

00:14:19.600 --> 00:14:21.300
Кожна периферійна мережа з'єднується безпосередньо з Hub,

00:14:21.400 --> 00:14:22.960
але не з'єднується з іншими периферійними мережами.

00:14:23.100 --> 00:14:25.080
Якщо периферійній мережі потрібно звернутися до іншої,

00:14:25.180 --> 00:14:26.140
трафік проходить через Hub.

00:14:26.140 --> 00:14:29.800
Це впорядковує систему та надає центральне місце для застосування політик безпеки.

00:14:29.960 --> 00:14:31.240
Що це означає для вас?

00:14:31.360 --> 00:14:34.740
Піренг – це спосіб побудови мереж, що охоплюють декілька VNT і регіонів.

00:14:34.800 --> 00:14:36.220
Це міст між вашими будівлями.

00:14:36.360 --> 00:14:38.860
Плануйте адресні простори так, щоб вони не перетиналися.

00:14:39.000 --> 00:14:40.640
Пам'ятайте, що піренг не є транзитивним,

00:14:40.720 --> 00:14:44.020
і розгляньте топологію «Зірка», коли почнете виходити за межі однієї VNT.

00:14:44.020 --> 00:14:46.160
Як все це з'єднується – загальна картина.

00:14:46.280 --> 00:14:48.860
Отже, зробимо крок назад і подивимося, як ці частини насправді поєднуються.

00:14:49.020 --> 00:14:50.520
Саме в цьому полягає справжня потужність.

00:14:50.640 --> 00:14:51.640
Ви починаєте з VNT.

00:14:51.880 --> 00:14:53.140
Це ваш приватний простір Vžur.

00:14:53.280 --> 00:14:54.700
Уявіть це як вашу земельну ділянку.

00:14:54.860 --> 00:14:56.500
На цій ділянці ви створюєте підмережі.

00:14:56.620 --> 00:14:57.580
Це ваші кімнати.

00:14:57.740 --> 00:15:00.600
Одна для веб-серверів, одна для баз даних, одна для інструментів керування.

00:15:00.760 --> 00:15:02.540
Кожна підмережа отримує власний блок-адрес,

00:15:02.540 --> 00:15:04.120
виділений з адресного простору VNT.

00:15:04.320 --> 00:15:05.700
Потім ви додаєте безпеку.

00:15:05.700 --> 00:15:08.140
Групи безпеки мережі підключаються до ваших підмереж.

00:15:08.280 --> 00:15:10.860
Вони контролюють, який трафік дозволено впускати та випускати.

00:15:11.060 --> 00:15:14.140
Ваша веб-підмережа дозволяє трафік з інтернету через порт 443.

00:15:14.320 --> 00:15:17.940
Ваша підмережа баз даних дозволяє трафік лише з веб-підмережі через порт 1433.

00:15:18.240 --> 00:15:20.680
Вишибала біля кожного входу точно знає, кому дозволено зайти.

00:15:20.680 --> 00:15:22.540
Далі ви налаштовуєте маршрути за цію.

00:15:22.660 --> 00:15:26.180
Можливо, ви хочете, щоб весь вихідний інтернет-трафік проходив через BrandMauer для перевірки.

00:15:26.180 --> 00:15:29.820
Ви створюєте таблицю маршрутів, додаєте власний маршрут і пов'язуєте його з підмережами.

00:15:29.960 --> 00:15:33.340
Тепер трафік йде за розробленим вами шляхом, а не за стандартним шляхом ажур.

00:15:33.460 --> 00:15:35.360
І нарешті ви з'єднуєте все разом.

00:15:35.500 --> 00:15:40.480
Ви з'єднуєте свою VNT з іншими, можливо, з хабом, де розміщені ваш BrandMauer та спільні сервіси.

00:15:40.480 --> 00:15:45.160
Тепер ваш додаток охоплює кілька мереж, але працює як єдина підключена система.

00:15:45.360 --> 00:15:46.460
Ось момент еврики.

00:15:46.640 --> 00:15:48.560
Жоден із цих елементів не працює ізольовано.

00:15:48.560 --> 00:15:50.620
VNT без підмереж – це просто порожній простір.

00:15:50.740 --> 00:15:52.860
Підмережі без груп безпеки NSG абсолютно відкриті.

00:15:53.000 --> 00:15:55.360
Маршрут і зація без чіткого плану спрямовує трафік не туди.

00:15:55.520 --> 00:15:57.540
Pering без планування створює конфлікти адрес.

00:15:57.680 --> 00:15:58.900
Вони є єдиною системою.

00:15:59.060 --> 00:16:00.560
Кожна частина залежить від інших.

00:16:00.740 --> 00:16:02.340
Дозвольте навести конкретний приклад.

00:16:02.480 --> 00:16:03.540
Уявіть веб-додаток.

00:16:03.540 --> 00:16:08.220
Ваші веб-сервери знаходяться в публічній підмережі з NSG, що дозволяє HTTPS трафік з інтернету.

00:16:08.220 --> 00:16:12.680
Ваші сервери додатків знаходяться в приватній підмережі, яка приймає трафік лише з веб-підмережі.

00:16:12.820 --> 00:16:17.280
Ваша база даних знаходиться в іншій приватній підмережі, яка приймає трафік лише з підмережі за стосунку.

00:16:17.420 --> 00:16:22.100
Таблиця маршрутизації спрямовує весь вихідний трафік через BrandMaware у мережі Hub в нет для реєстрації та перевірки.

00:16:22.100 --> 00:16:26.260
І все це об'єднано пірингом з вашою корпоративною мережею, щоб ваша внутрішня команда могла керувати нею.

00:16:26.400 --> 00:16:28.740
У цьому справжня цінність, а не в якійсь окремій функції.

00:16:28.740 --> 00:16:30.480
Це те, як вони працюють разом.

00:16:30.640 --> 00:16:36.220
20 років тому ви купували окремі сервери, налаштувували фізичні маршрутизатори та керували BrandMaware'ами для кожного пристрою.

00:16:36.400 --> 00:16:38.220
Все було вручну, повільно та дорого.

00:16:38.420 --> 00:16:40.320
Azure надає вам усе це як послугу.

00:16:40.320 --> 00:16:43.800
Ви визначаєте це кількома кліками або скриптом, і воно просто працює.

00:16:43.940 --> 00:16:45.340
Що це означає для вас?

00:16:45.480 --> 00:16:49.300
Коли ви побачите, як ці елементи поєднуються, мережа Azure стане передбачуваною.

00:16:49.480 --> 00:16:51.480
Ви не вгадуєте, ви проектуєте.

00:16:51.640 --> 00:16:55.280
І коли щось ламається, ви точно знаєте, де шукати, тому що розумієте систему.

00:16:55.280 --> 00:16:57.860
Отже, ось що я хочу, щоб ви винесли з цього епізоду.

00:16:57.980 --> 00:17:00.400
По-перше, найважливіший крок, який ви можете зробити.

00:17:00.560 --> 00:17:03.860
Створіть внет із добре спланованим адресним простором перш ніж щось розгортати.

00:17:04.020 --> 00:17:06.040
Це єдине рішення впливає на все подальше.

00:17:06.040 --> 00:17:09.140
По-друге, використовуйте підмережі для розділення рівнів вашого застосунку.

00:17:09.300 --> 00:17:12.120
Веб-сервери, сервери застосунків, бази даних, дайте кожному своє місце.

00:17:12.240 --> 00:17:14.200
І по-третє, почніть із груп безпеки мережі NSG.

00:17:14.360 --> 00:17:15.300
Вони безкоштовні.

00:17:15.300 --> 00:17:18.360
Вони потужні та суттєво покращують вашу безпеку з першого дня.

00:17:18.560 --> 00:17:21.140
Ваша внет – це фундамент усього, що ви будуєте в Вежур.

00:17:21.280 --> 00:17:23.600
Зробіть це правильно, і все інше стане простішим.

00:17:23.760 --> 00:17:26.560
Зробіть неправильно, і ви витратите весь свій час на боротьбу з мережею.

00:17:26.700 --> 00:17:29.240
Підписуйтесь на улюбленій подкаст-платформі та поділіться цим з кимось,

00:17:29.340 --> 00:17:30.520
хто розпочинає свій шлях в Вежур.

00:17:30.660 --> 00:17:32.720
Залиште коментар, якщо щось стало зрозумілим.

00:17:32.880 --> 00:17:34.440
Побачимось у наступному епізоді.