VPC Peering и маршрутизация

1) Зачем Peering и когда он уместен

• разделение сред и доменов (prod/stage/dev) при общей приватной связности;
• вынесение общих платформ (логирование, KMS/Vault, артефакты) в shared-сети;
• доступ из приложений к управляемым PaaS по приватным путям (через хабы/endpoint’ы).

Когда лучше не peering, а хаб: более 10–20 сетей, необходимость транзитной маршрутизации, централизованный egress, межоблачные связи → используйте Transit Gateway / Virtual WAN / Cloud Router.

2) Модели и ограничения

2.1 Виды пиринга

Intra-region peering — внутри региона, минимальные задержки и стоимость.
Inter-region peering — между регионами, обычно оплачивается межрегиональный трафик.
Cross-project/account — пиринг между разными аккаунтами/проектами (с делегированием).

2.2 Транзит и NAT

Классический VPC/VNet Peering не транзитивен: сеть A↔B и B↔C не означает A↔C.
NAT через промежуточную сеть для транзита — анти-паттерн (ломает исходные IP, сложный аудит).
Для транзита — хаб-шина: AWS Transit Gateway (TGW), Azure Virtual WAN/Hub, GCP Cloud Router/HA VPN/Peering Router.

2.3 Overlapping CIDR

• Переплан адресов (лучший вариант);
• NAT-домены/Proxy VPC с односторонними схемами (с учетом аудита и логирования);
• Для специфических PaaS — PrivateLink/PSC без L3-доступа.

3) Дизайн адресации и маршрутов

3.1 Планирование CIDR

Единый супернет (например, `10.0.0.0/8`) → делим по `region/env/vpc`.
Резервируйте диапазоны под будущие VPC/тенанты (growth-buffers).
IPv6 — план заранее: `/56` на VPC, `/64` на подсети.

3.2 Маршрутизация

Route tables: на каждом VPC/подсети явные маршруты на peer/hub.
Приоритеты: более специфичный префикс выигрывает; избегайте catch-all через пиринг.
Blackhole-защита: дублирующие/устаревшие маршруты помечайте и чистите.

3.3 Домены и роли

Spoke (приложения) ↔ Hub (общие сервисы, egress, инспекция).
Пиры только spoke↔hub; spoke↔spoke — через хаб (сегментация и контроль).

4) Паттерны топологий

4.1 «Простой» mesh (≤5 VPC)

Прямые пин-ту-пин пиры (A↔B, A↔C...). Плюсы: минимум компонентов; минусы: O(N²) связей и правил.

4.2 Hub-and-Spoke

Все spoke пирятся с Hub VPC/VNet; в хабе — TGW/Virtual WAN/Cloud Router, NAT/egress, инспекция. Масштабируемо, просто управлять.

4.3 Мульти-регион

Локальные хабы в каждом регионе; между хабами — inter-region peering или магистраль (TGW-to-TGW / VWAN-to-VWAN).

5) Безопасность и сегментация

Stateful на хосте: SG/NSG — основной барьер; NACL/подсетевые ACL — грубое ограждение/deny-листы.
L7 политики в mesh/proxy (Istio/Envoy/NGINX) — авторизация по mTLS/JWT/claims.
Egress-контроль: spoke не должен «видеть» интернет напрямую — только через egress-шлюз/PrivateLink.
Flow Logs и инспекция в хабе (GWLB, IDS/IPS) для меж-VPC трафика.

6) DNS и split-horizon

Каждой приватной зоне — видимость на нужных VPC (Private Hosted Zones/Private DNS/Zones).
Для PaaS через PrivateLink/PSC — частные записи на приватные IP endpoint’ов.
Conditional forwarding между on-prem ↔ cloud и region ↔ region.
Именование: `svc.env.region.internal.corp` — без PII; фиксируйте TTL (30–120с) под фейловер.

7) Наблюдаемость и тестирование

Метрики: accepted/denied на SG/NSG, bytes per peer, RTT/jitter между регионами, top-talkers.
Логи: VPC Flow Logs/NSG Flow Logs в SIEM, трассировка с `trace_id` для кореляции L7↔L3.
Тесты достижимости: синтетика TCP/443/DB-порты из разных подсетей/AZ/регионов; reachability analyzer.
Chaos-сеть: задержки/потери между peer/hub; проверка таймаутов/ретраев/идемпотентности.

8) Производительность и стоимость

Inter-region почти всегда тарифицируется; считайте egress заранее (дорожает при логах/бэкапах).
MTU/PMTUD: в пределах провайдера стандартная MTU, но на границах (VPN, FW, NAT-T) учитывайте MSS-clamp.
Горизонтальное масштабирование инспекции (GWLB/scale sets) без узких мест; ECMP для хабов.
Кэш/edge и SWR уменьшают межрегиональный трафик.

9) Облачные особенности и примеры

9.1 AWS (VPC Peering / Transit Gateway)

VPC Peering: создаем peering connection, добавляем маршруты в таблицах подсетей.
Нет транзита через обычный peering. Для транзита и централизованной модели — Transit Gateway.

hcl resource "aws_vpc_peering_connection" "a_b" {
vpc_id    = aws_vpc. a. id peer_vpc_id  = aws_vpc. b. id peer_owner_id = var. peer_account_id auto_accept  = false tags = { Name = "a-b", env = var. env }
}

resource "aws_route" "a_to_b" {
route_table_id     = aws_route_table. a_rt. id destination_cidr_block = aws_vpc. b. cidr_block vpc_peering_connection_id = aws_vpc_peering_connection. a_b. id
}

9.2 Azure (VNet Peering / Virtual WAN)

VNet Peering (включая глобальный): флаги Allow forwarded traffic, Use remote gateway для хаб-схем.
Для хабов и транзита — Virtual WAN / Hub c Route Tables и Policies.

bash az network vnet peering create \
--name spokeA-to-hub --vnet-name spokeA --remote-vnet hub \
--resource-group rg --allow-vnet-access --allow-forwarded-traffic

9.3 GCP (VPC Peering / Cloud Router)

VPC Peering без транзита; для центра — Cloud Router + HA VPN/Peering Router.
Hierarchical FW для org-guardrails.

10) Kubernetes в пиринговых сетях

Кластер в spoke, общие сервисы (логирование/хранилище/артефакты) — в hub; доступ по приватным адресам.
NetworkPolicy «deny-all» и явные egress на хаб/PrivateLink.
Не «таскайте» Pod CIDR между VPC; маршрутизируйте Node CIDR и пользуйтесь Ingress/Gateway.

11) Траблшутинг (шпаргалка)

1. CIDR не пересекаются? Проверить суперсеты/старые подсети.
2. Таблицы маршрутов: есть ли путь в обе стороны? Нет ли более специфичного маршрута, перехватывающего трафик?
3. SG/NSG/NACL: stateful-ин/аут соответствуют? Не блокирует ли подсетевой ACL обратный трафик?
4. DNS: правильные приватные записи/forwarders? Проверить `dig +short` из обеих сетей.
5. MTU/MSS/PMTUD: нет ли фрагментации и «молчаливых» таймаутов?
6. Проверка flow logs: есть ли SYN/SYN-ACK/ACK? Кто дропает?
7. Inter-region: квоты/лимиты пиринга/политики организации/теги маршрутизации.

12) Антипаттерны

«Случайный» mesh из десятков пиров без хаба → взрыв сложностей и пропусков ACL.
Overlapping CIDR «как-нибудь пережмем NAT’ом» → ломается аудит/сквозная идентификация.
Публичные egress в каждом spoke → неконтролируемая поверхность и стоимость.
Отсутствие split-horizon DNS → утечки имен/битые резолвы.
Широкие маршруты `0.0.0.0/0` через peer → неожиданная асимметрия трафика.
Ручные правки в консоли без IaC и ревизии.

13) Специфика iGaming/финансов

PCI CDE и платежные контуры — только через хаб с инспекцией; никакого spoke↔spoke в обход.
Data residency: PII/транзакционные логи — внутри юрисдикций; межрегионально — агрегаты/аноним.
Multi-PSP: PrivateLink/приватные каналы к PSP, централизованный egress-прокси по allowlist FQDN и mTLS/HMAC.
Аудит/WORM: flow-логи и изменения маршрутов в неизменяемом хранилище, ретеншн по нормам.
SLO разрезы: per region/VPC/tenant; алерты на «утечку egress» и деградацию межрегиональных RTT.

14) Чек-лист prod-готовности

• План CIDR без пересечений (IPv4/IPv6), зарезервированы пулы роста.
• Топология hub-and-spoke; пиры — только spoke↔hub; транзит через TGW/VWAN/Cloud Router.
• Route tables: явные пути, нет catch-all через peer, контроль blackhole.
• SG/NSG/NACL применены; L7-политики в mesh; egress только через хаб/PrivateLink.
• Private DNS/PHZ настроены; conditional-forwarders между on-prem/cloud/regions.
• Flow Logs включены; дашборды по peer/region; синтетика достижимости и PMTUD-тесты.
• IaC (Terraform/CLI) и Policy-as-Code (OPA/Conftest) для правил/маршрутов/DNS.
• Документированы runbook’и (добавить peer, раскатать маршруты, отключить spoke).
• Учения: отключение хаба/пира, измерение фактических RTO/RPO сетевых путей.
• Для iGaming/финансов: изоляция PCI, PrivateLink к PSP, WORM-аудит, SLO/алерты по юрисдикциям.

15) TL;DR

Используйте VPC/VNet Peering для простой приватной связности «точка-к-точке», но не полагайтесь на него для транзита — для этого нужен хаб (TGW/VWAN/Cloud Router). Планируйте CIDR без пересечений, держите маршруты явными и специфичными, применяйте stateful SG/NSG и L7-политики в mesh, DNS — split-horizon. Включите flow-логи, синтетику и PMTUD-проверки. Для iGaming/финансов — изоляция PCI, приватные каналы к PSP и неизменяемый аудит.