Модуль 2.2: Мережі GCP VPC

Складність: [COMPLEX] | Час на виконання: 3 год | Передумови: Модуль 2.1 (IAM та ієрархія ресурсів)

Чому цей модуль важливий

У березні 2021 року логістична компанія пережила каскадний збій системи відстеження замовлень, який тривав 14 годин. Причиною стала помилка в налаштуванні файрвола. Інженер додав правило, використовуючи мережеві теги, але зробив одрук у назві тегу — monitoring-target замість monitor-target. Оскільки файрволи GCP за замовчуванням забороняють увесь вхідний трафік, система моніторингу просто перестала бачити сервери. Тим часом інший інженер створив занадто широке правило для відладки, відкривши доступ усім до портів продуктових серверів.

Ця історія ілюструє дві істини про мережі GCP. По-перше, модель VPC у GCP є глобальною за замовчуванням. Одне помилкове правило може вплинути на сервери у всіх регіонах світу одночасно. По-друге, мережеві теги ненадійні — це просто рядки тексту, де будь-яка помилка призводить до мовчазної відмови системи.

У цьому модулі ви дізнаєтеся, чим VPC у GCP фундаментально відрізняється від AWS, як проєктувати масштабовані підмережі, як будувати надійні правила файрвола на основі сервісних акаунтів та як з’єднувати проєкти за допомогою Shared VPC.

Глобальні VPC vs Регіональні підмережі

Фундаментальна відмінність

Якщо ви переходите з AWS, це головний зсув мислення: у GCP мережа VPC є глобальним ресурсом. Підмережі є регіональними, але всі вони належать до однієї глобальної VPC.

Функція	AWS VPC	GCP VPC
Область дії	Регіональна	Глобальна
Зв’язок між регіонами	Потрібен піринг або Transit Gateway	Автоматично (одна мережа)
Область підмережі	Зона доступності (AZ)	Регіон (охоплює всі зони)
Файрволи	Security Groups + NACL	Глобальні правила (stateful)

Це означає, що віртуальна машина в Токіо може спілкуватися з машиною в Лондоні за внутрішньою IP-адресою без жодних додаткових налаштувань, якщо вони в одній VPC.

Правила файрвола: Теги vs Сервісні акаунти

Файрвол GCP працює на рівні всієї мережі VPC. Правила мають пріоритет (чим менше число, тим вищий пріоритет).

Проблема тегів

Мережеві теги — це просто назви, які ви прикріплюєте до ВМ. Ви можете написати правило: “дозволити порт 80 для всіх машин із тегом web”. Проблема в тому, що будь-хто з мінімальними правами може додати тег web до будь-якої машини, відкривши її всьому світу.

Правила на основі сервісних акаунтів (Найкраща практика)

Замість тегів використовуйте сервісні акаунти як цілі для файрвола. Це набагато безпечніше, бо:

Ви не можете змінити сервісний акаунт машини без спеціальних прав IAM.
Немає одруків — сервісний акаунт або існує, або ні.
Це працює між проєктами у Shared VPC.

# Приклад правила: дозволити трафік від веб-серверів до бекенда
gcloud compute firewall-rules create allow-web-to-app \
  --network=prod-vpc \
  --direction=INGRESS \
  --action=ALLOW \
  --rules=tcp:8080 \
  --source-service-accounts=web-sa@project.iam.gserviceaccount.com \
  --target-service-accounts=app-sa@project.iam.gserviceaccount.com

Shared VPC: Мережа для всієї компанії

Shared VPC — це фундамент корпоративної мережі в GCP. Вона дозволяє одному проєкту (Host Project) володіти мережею, а іншим проєктам (Service Projects) — використовувати її підмережі.

Навіщо це потрібно?

Мережева команда керує всіма IP, файрволами та VPN в одному місці.
Команди розробників створюють свої ВМ та кластери GKE у власних проєктах, але підключають їх до спільної безпечної мережі.

Cloud NAT: Вихід у світ для приватних машин

Якщо ваша віртуальна машина не має публічної IP-адреси (що є стандартом безпеки), вона не може вийти в інтернет навіть для оновлення пакетів. Cloud NAT вирішує це, дозволяючи машинам ініціювати вихідні з’єднання, не стаючи доступними ззовні.

Типові помилки

Помилка	Чому це стається	Як виправити
Використання “Auto Mode” VPC	Це дефолт, створює підмережі всюди	Завжди використовуйте “Custom Mode” для продакшну
Файрволи на тегах	Здається простішим на початку	Переходьте на правила на основі сервісних акаунтів
Відсутність Private Google Access	Приватні ВМ не бачать Google API (напр. S3/GCS)	Увімкніть `enable-private-ip-google-access` на кожній підмережі
Надто широкі правила (0.0.0.0/0)	Щоб “швидше запрацювало”	Використовуйте IAP (Identity-Aware Proxy) для SSH замість відкриття порту 22

Тест

1. Чим фундаментально відрізняється VPC у GCP від VPC в AWS?

VPC у GCP є глобальною. Одна мережа може мати підмережі в усіх регіонах світу одночасно. В AWS мережа VPC обмежена одним регіоном.

2. Чи можна з'єднати дві VPC у GCP, якщо їхні IP-діапазони (CIDR) перетинаються?

Ні. Як і в інших хмарах, при пірингу або використанні Shared VPC діапазони IP не повинні накладатися. Плануйте свою мережу заздалегідь.

Практична вправа: Створення мережі та Cloud NAT

Створіть мережу в режимі Custom:

gcloud compute networks create prod-network --subnet-mode=custom

Створіть підмережу (напр. в us-central1):

gcloud compute networks subnets create my-subnet \
  --network=prod-network --range=10.0.1.0/24 --region=us-central1

Налаштуйте Cloud NAT, щоб приватні машини мали інтернет:
- Створіть Cloud Router.
- Створіть конфігурацію NAT на цьому роутері.

Наступний модуль

Переходьте до Модуля 2.3: Compute Engine — ви навчитеся створювати віртуальні машини, використовувати Spot-екземпляри та будувати групи з автомасшабуванням.