Що таке віртуальна мережа Azure? Більшість людей, почувши цей термін, думають, що це просто чергове налаштування при розгортанні віртуальної машини, яке ви обираєте і одразу забуваєте. Але ось у чому правда. Віртуальна мережа Azure – це не просто налаштування. Це основа всього, що ви будуєте в Azure. Кожна віртуальна машина, кожна база даних, кожен сервіс додатків, кожна функція, яку ви розгортаєте, усе це розміщується всередині неї. І якщо ви не розумієте, як вони працюють, ви дієте на осліп. До кінця цього епізоду ви зрозумієте, що таке в нет насправді, як вона працює і чому кожен ваш ресурс залежить від неї. Ми розглянемо, що таке в нет, як працюють IP-адреси, підмережі, безпека, маршрутизація та як з'єднувати мережі в нет між собою. Беріть каву і почнемо. Що таке в нет? Приватна хмарна мережа. Почнемо з найпростішого визначення. Віртуальна мережа Azure або скорочено в нет – це ваша власна приватна мережа всередині Azure.

Уявіть її як приватний офісний будинок. Тільки ті, кому ви дозволили, можуть увійти. Ви контролюєте, хто входить, хто має доступ до певного поверху і кому вхід заборонено взагалі. До появи в нет усе було інакше. Розгортаючи віртуальну машину в хмарі, ви фактично виставляли її на огляд інтернету за замовчуванням. Без приватної мережі навколо неї. Будь-хто, хто знав IP-адресу, міг спробувати підключитися. Це був справжній кошмар для безпеки. Що змінилося? Azure дала вам можливість створювати ізольовані приватні мережеві простори. Ви самі визначаєте межі. Ви вирішуєте, що буде всередині. Ніщо за межами цього кордону не зможе потрапити всередину, якщо ви явно це не дозволите. Варто відразу зазначити, що ваша в нет існує в межах конкретного регіону Azure. Вона не є глобальною. Створивши в нет у Західній Європі, вона там і залишається. Ресурси з іншого регіону не можуть просто підключитися до неї.

Їм знадобиться власна в нет, або вам доведеться з'єднувати їх пізніше. Коли ви створюєте в нет, ви самі визначаєте простір IP-адрес. Azure не обирає його за вас. Ви самі вирішуєте діапазон IP-адрес, які використовуватимуть ваші ресурси. Це велика відповідальність, і ми поговоримо про те, як зробити це правильно в наступному розділі. Ось головний висновок. В нет – це фундамент. Кожна віртуальна машина, кожна база даних, кожна функція Azure, яку ви розгортаєте, знаходиться всередині такої мережі. Без в нет ваші ресурси не мають контексту приватної мережі. Вони просто плавають у хмарі без кордонів, без ізоляції та без безпеки. То що це означає для вас? Якщо ви створюєте щось в Azure, почніть спочатку з в нет, не після розгортання ресурсів, а до нього. Ваша в нет – це земельна ділянка, на якій ви будуєте. Ви ж не будете будувати будинок, не купивши спочатку землю, правда? Тут така сама ідея.

IP-адреса C&A та CIDR – вибір адресного простору. Отже, давайте заглибимося. Коли ви створюєте в нет, першим важливим рішенням є вибір IP-діапазону. Це робиться за допомогою нотації CIDR. CIDR – це скорочення від Classless IntedomainRoutine, що по суті означає «мені потрібно стільки IP-адрес». Чому це важливо? Тому що обраний діапазон визначає, скільки ресурсів можна розмістити у віртуальній мережі. Ось як це працює. CIDR використовує скісну риску та число як от 16 або 24. Це число вказує на розмір адресного простору. Значення 16-тьох дає вам близько 65 000 IP-адрес. Це дуже багато. Значення 24 дає близько 250, що ідеально для невеликої команди або одного рівня застосунку. Тож при проєктуванні в нет потрібно думати, скільки ресурсів у вас буде і як ви хочете їх групувати. Тепер ви не можете вибрати будь-який IP-діапазон. Azure дотримується стандарту RFC 1918, який резервує приватні IP-діапазони для внутрішніх мереж.

У вас є три варіанти. Діапазон 10XXX – найбільший, він дає багато простору для зростання. Діапазон 172-16XX – дещо менший, але теж корисний. А діапазон 192-168XX – той, який у вас, ймовірно, вдома на роутері. Ось у чому справа. Адресний простір вашої в нет не повинен перекриватися з жодною іншою мережею, до якої ви плануєте підключатися. Це поширена помилка. Багато хто обирає звичний діапазон, лише щоб пізніше виявити конфлікт із корпоративною мережею. Тож, якщо офісна мережа вашої компанії використовує 10.0.0.0 коса риска 16, не використовуйте такий самий діапазон вежур. Якщо ви спробуєте з'єднати їх пізніше, вони конфліктуватимуть, і трафік не знатиме, куди йти. Дозвольте навести конкретний приклад. Уявіть, що ви будуєте гібридну конфігурацію, де ежур підключається до вашого локального дата-центру, а він використовує 10.0.0.0 коса риска 16. Якщо ви створите в нет з таким самим діапазоном, матимете дві мережі, що змагаються за однакові IP.

Подумайте про це. Дві мережі, що використовують один IP-діапазон, не можуть повноцінно спілкуватися. Це як два будинки з однаковою адресою. Пошта плутається. Це проблема, яку ви не захочете вирішувати постфактум. Тож, плануйте заздалегідь і вибирайте унікальний діапазон. І ось порада щодо планування. Обирайте більший діапазон, ніж, на вашу думку, вам потрібно. Можливо, ви думаєте, що зараз вам достатньо маски 24, але з розвитком програми ви пошкодуєте, що не взяли 16. Змінити це пізніше буде непросто.

Простір для розвитку. Що це означає для вас? Уявіть адресний простір вашої внет як купівлю земельної ділянки. Беріть достатньо для майбутнього росту. Якщо вважаєте, що потрібна мала ділянка, купуйте середню. Ви подякуєте собі пізніше. Це головний висновок. Плануйте адресний простір із розрахунком на майбутнє. Підмережі. Поділ вашої мережі. Отже, у вас є внет і ви обрали адресний простір. Що далі? Не можна просто звалити все в одну купу. Ось тут і з'являються підмережі. Підмережі. Це один із фундаментальних блоків вашої внет. Вони дозволяють організовувати та захищати ваші ресурси. Підмережа. Це менша частина адресного простору вашої внет. Якщо внет – це будівля, то підмережі – це окремі кімнати. Ви ж не розмістили б сервер, стіл реєстрації та кімнату відпочинку в одному відкритому просторі. Тут та сама ідея. Це проста концепція, але вона кардинально змінює управління мережею. Різні ресурси розміщуються в різних підмережах.

Веб-сервери – в одній підмережі, бази даних – в іншій, а логіка за стосунку – в третій. Чому? Дві причини – безпека та організація. Почнімо з безпеки, бо це зазвичай найважливіше. Безпека понад усе. Якщо хтось зламає ваш веб-сервер, ви не хочете, щоб він отримав прямий доступ до бази даних. Окремі підмережі створюють природний бар'єр. Зловмиснику доведеться перетнути цей кордон, і ви можете контролювати, що саме його перетинає. Ви також можете використовувати групи мережової безпеки для контролю трафіку між підмережами. Це тема для іншого відео, але важливо знати, що підмережі є основою цієї безпеки. Друге – організація. Коли все має своє місце, керувати цим простіше. Ви знаєте, яка підмережа містить інтерфейсні ресурси, а яка – серверні дані. Ви можете застосовувати політики та правила до всієї підмережі одразу, замість налаштування кожного ресурсу окремо. Це економить час і зменшує кількість помилок.

Тепер деталь, яка часто стає несподіванкою. Azure резервує 5 IP-адрес у кожній підмережі для внутрішніх потреб, таких як маршрутизація та DNS. Тож, якщо ви створите підмережу з діапазоном 24, що дає 256 адрес, ви отримаєте лише 251 корисну. Це поширена пастка. Ви плануєте на 256, а отримуєте лише 251. Тож, завжди додавайте трохи запасу, коли визначаєте розмір підмереж. Хороша новина в тому, що підмережі можна додавати після створення віртуальної мережі. Ви не обмежені тими, що налаштували під час створення. Тож, якщо зрозумієте, що потрібна окрема підмережа для інструментів керування чи моніторингу, додасте пізніше. Це не проблема. Але все ж краще спланувати їх заздалегідь. Додавати підмережі згодом можна, але доведеться переміщати ресурси, а це може спричинити збої. Але ось найкраща практика. Використовуйте окремі підмережі для різних рівнів вашого застосунку від самого початку. Подумайте про архітектуру свого застосунку.

Зазвичай є фронтенд для запитів користувачів, бекенд для бізнес-логіки та рівень даних для їх зберігання. Кожен із них повинен мати власну підмережу. Не чекайте виходу в продакшні, щоб зрозуміти, що все треба розділяти. Це значно складніше, коли ресурси вже розгорнуті. Що це означає для вас? Підмережі – це спосіб зробити мережу впорядкованою та безпечною. Це наче кімнати у вашій будівлі. Плануйте їх заздалегідь і надайте кожному рівню застосунку власний простір. Так ви забезпечите чистоту та безпеку своєї мережі. Публічні та приватні IP-адреси. Хто і що може бачити? Поговоримо про IP-адреси, бо вони не всі однакові. Коли ви розгортаєте ресурс у віртуальній мережі, він типово отримує приватну IP-адресу. Це адреса для зв'язку з іншими ресурсами всередині віртуальної мережі. Уявіть це як внутрішній номер телефону. Його можуть набрати лише ті, хто в будівлі. Приватні IP доступні лише зсередини віртуальної мережі або з підключених до неї мереж.

Якщо ви вдома з ноутбуком, ви не отримаєте доступу до приватної IP-адреси Azure. Її немає в інтернеті. Вона всередині вашої приватної мережі. Тож як зробити ресурс доступним з інтернету? Ви надаєте йому публічну IP-адресу. Це адреса, видима зовнішньому світу, ніби публічний номер телефону замість внутрішнього номера. Ось ключовий момент. Публічні IP – це опціонально. Ви призначаєте їх явно, бо Azure ніколи не дає ресурсів публічну IP, доки ви не попросите. Так і задумано. Типово все має бути приватним, а публічним – лише за свідомим вибором. І саме тут багато новачків припускаються помилки. Вони призначають публічні IP усім ресурсам. Веб-сервер, база даних, бекендарі – усе отримує таку адресу. Це ризик для безпеки. Ваша база даних не має бути доступною з інтернету, як і ваш бекендарі. Лише зовнішні ресурси, з якими безпосередньо взаємодіють користувачі, повинні мати публічні IP-адреси. Публічні IP-адреси бувають двох типів – статичні та динамічні.

Статична публічна IP-адреса залишається незмінною, навіть якщо ви зупиняєте та перезапускаєте ресурс. Динамічна публічна IP-адреса може змінюватися. Якщо ви запускаєте робочий додаток, вам, швидше за все, потрібні статичні IP, щоб користувачі завжди могли вас знайти. Якщо ви щось тестуєте, динамічної IP може бути достатньо. Ви також можете використовувати так званий префікс публічних IP, який дозволяє резервувати блок-адрес. Замість створення по одній, ви резервуєте діапазон, а потім призначаєте окремі адреси з цього діапазону. Це корисно, якщо ви знаєте, що для проєкту знадобиться багато публічних IP-адрес. Що це означає для вас? Приватні IP-адреси – це безпечний варіант за замовчуванням. Вони як внутрішній телефонний номер. Публічні IP – це свідомий вибір, який ви робите лише тоді, коли ресурс має бути доступним ззовні. І коли вони вам потрібні, подумайте, чи потрібні вам статичні або динамічні адреси і чи доцільно використовувати префікс.

Групи мережевої безпеки контролюють трафік. Отже, ви розібралися зі своєю віртуальною мережею, внет, під мережами та IP-адресами. Але як насправді контролювати, який трафік дозволено, а який – ні? Саме для цього існують групи мережевої безпеки – NSD. NSD – це охоронець, який контролює трафік, що входить до ваших ресурсів і виходить із них. Уявіться, як вишибало в клубі, він перевіряє посвідчення, звіряється зі списком гостей і не пускає тих, кого там не повинно бути. Будь-який трафік, що намагається потрапити до вашого ресурсу, спочатку має пройти через цього вишибалу. NSD працюють на основі правил. Кожне правило дозволяє або забороняє доступ на основі чотирьох параметрів – вихідна IP-адреса, цільова IP-адреса, номер порту та протокол. Наприклад, можна дозволити трафік з IP-адреси офісу на порт 443 або заборонити весь інтернет-трафік на порт 22. Ось такий рівень контролю. А ось і потужна функція.

Ви можете приєднати NSD до підмережі або безпосередньо до мережового інтерфейсу окремої віртуальної машини. Якщо ви приєднуєте NSD до підмережі, вона застосовується до всього, що знаходиться всередині. До кожної віртуальної машини, кожної бази даних, кожного ресурсу. Це загальна політика для всіх. Якщо ви приєднуєте її до інтерфейсу конкретної віртуальної машини, вона діє лише на цей пристрій. Можна зробити навіть і те, і інше. NSD на рівні підмережі для загальних правил і NSD на рівні мережової карти для винятків. Правила за замовчуванням, які створює Azure, досить розумні. Вони дозволяють увесь трафік усередині в нет, щоб ваші ресурси могли взаємодіяти і блокують увесь трафік з інтернету, тому нічого ззовні не потрапить до ваших ресурсів, доки ви явно це не дозволите. Це хороший початок. Дозвольте навести поширений приклад. Припустимо, ви керуєте віртуальною машиною Linux, і вам потрібно підключитися до неї через SSH.

Ви створите правило NSD, яке дозволяє вхідний трафік через порт 22, але ви ж не хочете дозволяти SSH звідусіль. Це просити біди. Тому ви обмежуєте доступ лише до власної IP-адреси, щоб тільки ви могли підключитися через SSH, а решта були заблоковані. Те саме стосується RDP через порт 3389 для машин на Windows. Що це означає для вас? NSD – це ваш перший рубіж оборони і найприємніше те, що вони безкоштовні. За їх використання немає додаткової плати, тож немає причин їх не налаштовувати. Кожна підмережа, кожен ресурс повинні мати підключено NSD. Починайте з правила «Заборонити все» і відкривайте лише те, що потрібно. Таблиці маршрутизації та маршрутизація – спрямування трафіку. Тепер поговоримо про маршрутизацію, адже коли ви вирішили, який трафік дозволено, потрібно вирішити, куди саме він йде. Річ у тім, що Azure автоматично створює системні маршрути для кожної підмережі. Вам не потрібно нічого робити.

Уявіть це як навігатор за замовчуванням, який знає основні шляхи. Трафік усередині в нет, трафік до пірингових в нет, трафік до інтернету. Усе це працює з коробки, але іноді стандартний навігатор не веде вас туди, куди потрібно. Саме тоді вам потрібні визначені користувачем маршрути або UDR. Вони дозволяють перекрити системні маршрути Azure і взяти під контроль шлях, яким йде трафік. Як це працює? Ви створюєте таблицю маршрутизації. Ви додаєте свої власні маршрути. Потім ви пов'язуєте цю таблицю маршрутизації з підмережею. З цього моменту трафік, що залишає підмережу, слідує вашим правилам замість стандартних. Дозвольте навести конкретний приклад. Скажімо, ви хочете, щоб увесь інтернет-трафік з вашої в нет спочатку проходив через BrandMauer. Можливо, вам потрібно перевірити його, записати в журнал або заблокувати шкідливі сайти. Стандартний системний маршрут відправляє інтернет-трафік безпосередньо назовні.

Це не те, що вам потрібно, тому ви створюєте маршрут, який вказує, що будь-який трафік на 0.0.0.0, тобто будь-куди в інтернеті, має йти через BrandMauer. Це і є визначений користувачем маршрут. Таблиці маршрутизації використовують поняття «Наступний перехід». Це пункт призначення, куди трафік відправляється далі. У вас є кілька варіантів. Ви можете надіслати його на віртуальний пристрій, наприклад, BrandMauer. Ви можете надіслати його на шлюз віртуальної мережі, за допомогою якого ви підключаєтеся до локальних мереж. Ви можете спрямувати його прямо в інтернет або на NAN, що фактично відкидає трафік. Головне, що варто зрозуміти, маршрутизація – це спосіб контролю шляху трафіку у вашій мережі. Системні маршрути – це гарний варіант за замовчуванням, але вони не завжди підходять для вашої ситуації. Якщо вам потрібно, щоб трафік проходив через пункт перевірки, певний шлюз або був заблокований, вам потрібні визначені користувачем маршрути.

Що це означає для вас? Маршрутизація – це спосіб вказати трафіку шлях, і ви можете перевизначити налаштування Azure, коли це необхідно. Почніть із системних маршрутів, зрозумійте їхню роботу, а потім додавайте власні, коли цього вимагає архітектура. Peering внет – з'єднання мереж. Досі ми говорили про одну внет, одна будівля, одна приватна мережа. Але що робити, коли у вас є кілька внет? Можливо, одна для продуктового середовища, інша для тестування, або ж ви запускаєте застосунки в різних регіонах Azure. За замовчуванням, ці внет повністю ізольовані. Вони не можуть взаємодіяти одна з одною. Вони як окремі будівлі без доріг між ними. Ось тут і стає в пригоді Peering внет. Він дозволяє з'єднати дві внет приватно, і я маю на увазі справді приватно. Трафік між піренговими внет залишається в магістральній мережі Microsoft. Він ніколи не виходить у публічний інтернет. Це означає низьку затримку, високу пропускну здатність і відсутність зовнішніх загроз.

Ось що дивує багатьох. Peering працює і між регіонами. Це називається глобальним Peeringом. Ви можете об'єднати внет у Західній Європі з внет у Південно-Східній Азії, і трафік між ними залишиться в приватній мережі Microsoft. Жодних VPN-шлюзів, жодних публічних IP, лише пряме приватне з'єднання. Але є правило, яке ви не можете порушити. Внет у Peeringу повинні мати адреси, що не перетинаються. Якщо обидві внет намагаються використати діапазон 10.0.0.0 Коса Риска 16, їх не можна об'єднати. Виникне конфлікт IP-адрес, і Ажур не знатиме, якій мережі належить пакет. Пам'ятаєте пораду про ретельне планування адресного простору? Ось чому це важливо. Якщо плануєте Peering у майбутньому, переконайтеся, що їхні діапазони не перетинаються з самого початку. А ось деталь, на якій багато хто помиляється. Peering не є транзитивним. Що це означає? Припустимо, Внет-Ай з'єднана з Внет-Бі, а Внет-Бі з Внет-Сі Внет-Ай не отримує автоматичного доступу до Внет-Сі, через Бі вони не з'єднані.

Кожен Peering – це пряме посилання рівно між двома Внет. Якщо ви хочете, щоб взаємоді ЛСС, потрібен окремий Peering між ними. Як же керувати цим у великих масштабах? Ви використовуєте архітектуру Hub і Spoki, Hub & Spoke. Одна центральна віртуальна мережа – VNT, Hub, з'єднується з багатьма іншими Внет-Периферійними мережами – Spokes. Hub може містити спільні сервіси, такі як BrandMoware, VPN-шлюз або інструменти моніторингу. Периферійні мережі містять ваші окремі робочі навантаження. Кожна периферійна мережа з'єднується безпосередньо з Hub, але не з'єднується з іншими периферійними мережами. Якщо периферійній мережі потрібно звернутися до іншої, трафік проходить через Hub. Це впорядковує систему та надає центральне місце для застосування політик безпеки. Що це означає для вас? Піренг – це спосіб побудови мереж, що охоплюють декілька VNT і регіонів. Це міст між вашими будівлями. Плануйте адресні простори так, щоб вони не перетиналися.

Пам'ятайте, що піренг не є транзитивним, і розгляньте топологію «Зірка», коли почнете виходити за межі однієї VNT. Як все це з'єднується – загальна картина. Отже, зробимо крок назад і подивимося, як ці частини насправді поєднуються. Саме в цьому полягає справжня потужність. Ви починаєте з VNT. Це ваш приватний простір Vžur. Уявіть це як вашу земельну ділянку. На цій ділянці ви створюєте підмережі. Це ваші кімнати. Одна для веб-серверів, одна для баз даних, одна для інструментів керування. Кожна підмережа отримує власний блок-адрес, виділений з адресного простору VNT. Потім ви додаєте безпеку. Групи безпеки мережі підключаються до ваших підмереж. Вони контролюють, який трафік дозволено впускати та випускати. Ваша веб-підмережа дозволяє трафік з інтернету через порт 443. Ваша підмережа баз даних дозволяє трафік лише з веб-підмережі через порт 1433. Вишибала біля кожного входу точно знає, кому дозволено зайти.

Далі ви налаштовуєте маршрути за цію. Можливо, ви хочете, щоб весь вихідний інтернет-трафік проходив через BrandMauer для перевірки. Ви створюєте таблицю маршрутів, додаєте власний маршрут і пов'язуєте його з підмережами. Тепер трафік йде за розробленим вами шляхом, а не за стандартним шляхом ажур. І нарешті ви з'єднуєте все разом. Ви з'єднуєте свою VNT з іншими, можливо, з хабом, де розміщені ваш BrandMauer та спільні сервіси. Тепер ваш додаток охоплює кілька мереж, але працює як єдина підключена система. Ось момент еврики. Жоден із цих елементів не працює ізольовано. VNT без підмереж – це просто порожній простір. Підмережі без груп безпеки NSG абсолютно відкриті. Маршрут і зація без чіткого плану спрямовує трафік не туди. Pering без планування створює конфлікти адрес. Вони є єдиною системою. Кожна частина залежить від інших. Дозвольте навести конкретний приклад. Уявіть веб-додаток. Ваші веб-сервери знаходяться в публічній підмережі з NSG, що дозволяє HTTPS трафік з інтернету.

Ваші сервери додатків знаходяться в приватній підмережі, яка приймає трафік лише з веб-підмережі. Ваша база даних знаходиться в іншій приватній підмережі, яка приймає трафік лише з підмережі за стосунку. Таблиця маршрутизації спрямовує весь вихідний трафік через BrandMaware у мережі Hub в нет для реєстрації та перевірки. І все це об'єднано пірингом з вашою корпоративною мережею, щоб ваша внутрішня команда могла керувати нею. У цьому справжня цінність, а не в якійсь окремій функції. Це те, як вони працюють разом. 20 років тому ви купували окремі сервери, налаштувували фізичні маршрутизатори та керували BrandMaware'ами для кожного пристрою. Все було вручну, повільно та дорого. Azure надає вам усе це як послугу. Ви визначаєте це кількома кліками або скриптом, і воно просто працює. Що це означає для вас? Коли ви побачите, як ці елементи поєднуються, мережа Azure стане передбачуваною. Ви не вгадуєте, ви проектуєте.

І коли щось ламається, ви точно знаєте, де шукати, тому що розумієте систему. Отже, ось що я хочу, щоб ви винесли з цього епізоду. По-перше, найважливіший крок, який ви можете зробити. Створіть внет із добре спланованим адресним простором перш ніж щось розгортати. Це єдине рішення впливає на все подальше. По-друге, використовуйте підмережі для розділення рівнів вашого застосунку. Веб-сервери, сервери застосунків, бази даних, дайте кожному своє місце. І по-третє, почніть із груп безпеки мережі NSG. Вони безкоштовні. Вони потужні та суттєво покращують вашу безпеку з першого дня. Ваша внет – це фундамент усього, що ви будуєте в Вежур. Зробіть це правильно, і все інше стане простішим. Зробіть неправильно, і ви витратите весь свій час на боротьбу з мережею. Підписуйтесь на улюбленій подкаст-платформі та поділіться цим з кимось, хто розпочинає свій шлях в Вежур. Залиште коментар, якщо щось стало зрозумілим.

Побачимось у наступному епізоді.