VPC Peering et routage

1) Pourquoi Peering et quand il est approprié

• la séparation des environnements et des domaines (prod/stage/dev) avec une connectivité privée commune ;
• Mise en place de plates-formes communes (logging, KMS/Vault, artefacts) sur le réseau partagé ;
• accès depuis les applications aux PaaS gérées par des voies privées (via hubs/endpoint's).

Quand il est préférable de ne pas peering, mais hub : plus de 10-20 réseaux, la nécessité d'un routage de transit, egress centralisé, interconnexion, → utiliser Transit Gateway/Virtual WAN/Cloud Router.

2) Modèles et limites

2. 1 Types de peering

L'intra-région peering - à l'intérieur de la région, des retards et des coûts minimes.
Inter-région peering - entre les régions, le trafic interrégional est généralement payé.
Cross-project/account - piring entre différents comptes/projets (avec délégation).

2. 2 Transit et NAT

Le VPC/VNet Peering classique n'est pas transitif : un réseau de A↔B et de B↔C ne signifie pas A↔C.
NAT via un réseau intermédiaire pour le transit - anti-modèle (brise l'IP source, l'audit complexe).
Pour le transit - hub bus : AWS Transit Gateway (TGW), Azure Virtual WAN/Hub, GCP Cloud Router/HA VPN/Peering Router.

2. 3 Overlapping CIDR

• Réacheminement des adresses (meilleure option) ;
• Les domaines NAT/Proxy VPC avec des schémas unidirectionnels (en tenant compte de l'audit et du logage) ;
• Pour les PaaS spécifiques - PrivateLink/PSC sans accès L3.

3) Conception de l'adressage et des itinéraires

3. 1 Planification du CIDR

Un surnom unique (par exemple, '10. 0. 0. 0/8 ') → nous divisons par' région/bou/vpc '.
Réservez les plages pour les futurs VPC/tenants (growth-buffers).
IPv6 est un plan préalable : '/56 'sur VPC, '/64' sur le sous-réseau.

3. 2 Routage

Tables de route : sur chaque VPC/sous-réseau, des itinéraires explicites sur peer/hub.
Priorités : un préfixe plus spécifique gagne ; éviter le catch-all via le peering.
Blackhole-protection : les routes en double/obsolètes sont marquées et nettoyées.

3. 3 Domaines et rôles

Spoke (applications) ↔ Hub (services partagés, egress, inspection).
Les fêtes ne sont que spoke↔hub ; spoke↔spoke - par le biais des habits (segmentation et contrôle).

4) Modèles de topologies

4. 1 « Simple » mesh (≤5 VPC)

Pin-tu-pin-pin (A↔B, A↔C...). Avantages : un minimum de composants ; inconvénients : O (N ²) liens et règles.

4. 2 Hub-and-Spoke

Tous les spoke piquent avec Hub VPC/VNet ; dans le hub - TGW/Virtual WAN/Cloud Router, NAT/egress, inspection. Évolutif, simple à gérer.

4. 3 Multi-régions

Les maisons locales dans chaque région ; entre les pôles est inter-région peering ou autoroute (TGW-to-TGW/VWAN-to-VWAN).

5) Sécurité et segmentation

Stateful sur l'hôte : SG/NSG est la barrière principale ; NACL/sous-réseau ACL - clôture grossière/feuilles de deny.
L7 politiques dans mesh/proxy (Istio/Envoy/NGINX) - autorisation sur mTLS/JWT/clims.
Contrôle egress : spoke ne doit pas « voir » Internet directement - seulement via la passerelle egress/PrivateLink.
Flow Logs et inspection au hub (GWLB, IDS/IPS) pour le trafic inter-VPC.

6) DNS и split-horizon

Chaque zone privée est visible sur les VPC souhaités (Zones privées hébergées/DNS/Zones privées).
Pour PaaS via PrivateLink/PSC - enregistrements privés sur IP privé endpoint's.
Conditional forwarding между on-prem ↔ cloud и region ↔ region.
Nom : 'svc. env. region. internal. corp '- sans PII ; Fixer la TTL (30-120c) sous le faussaire.

7) Observabilité et tests

Métriques : acceptées/refusées sur SG/NSG, bytes per peer, RTT/jitter entre les régions, top-talkers.
Logs : VPC Flow Logs/NSG Flow Logs dans SIEM, trace avec 'trace _ id' pour la corulation L7↔L3.
Tests d'accessibilité : ports TCP/443/DB synthétiques de différents sous-réseaux/AZ/régions ; reachability analyzer.
Réseau Chaos : retards/pertes entre peer/hub ; vérification du délai d'expiration/rétroactivité/idempotence.

8) Performance et coût

L'inter-région est presque toujours tarifiée ; comptez egress à l'avance (chère aux logs/backups).
MTU/PMTUD : au sein du fournisseur, MTU standard, mais aux frontières (VPN, FW, NAT-T), tenez compte du MSS-clamp.
Mise à l'échelle horizontale de l'inspection (GWLB/scale sets) sans goulets d'étranglement ; ECMP pour les hubs.
Cache/edge et SWR réduisent le trafic interrégional.

9) Caractéristiques et exemples du cloud

9. 1 AWS (VPC Peering / Transit Gateway)

VPC Peering : nous créons une connexion peering, nous ajoutons des itinéraires dans les tables de sous-réseaux.
Pas de transit par peering normal. Pour le transit et le modèle centralisé - 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 (y compris global) : drapeaux de trafic forwarded Allow, Use remote gateway pour les schémas habs.
Pour les hubs et le transit - Virtual WAN/Hub c Routes Tables et Politiques.

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 sans transit ; pour le centre - Cloud Router + HA VPN/Peering Router.
Hierarchical FW для org-guardrails.

10) Kubernetes dans les réseaux peer-to-peer

Cluster dans spoke, services partagés (logging/stockage/artefacts) - dans hub ; accès à des adresses privées.
NetworkPolicy « deny-all » et egress explicite sur hub/PrivateLink.
Ne pas « traîner » le Pod CIDR entre les VPC ; Routez Node CIDR et utilisez Ingress/Gateway.

11) Trablshuting (triche)

1. Les CIDR ne se chevauchent pas ? Vérifier les supersets/anciens sous-réseaux.
2. Tables d'itinéraire : y a-t-il un chemin dans les deux sens ? N'y a-t-il pas un itinéraire plus spécifique pour intercepter le trafic ?
3. SG/NSG/NACL : le stateful-in/out correspond-il ? L'ACL sous-réseau ne bloque-t-elle pas le trafic inverse ?
4. DNS : les bons enregistrements privés/forwarders ? Vérifiez 'dig + short' à partir des deux réseaux.
5. MTU/MSS/PMTUD : N'y a-t-il pas de fragmentation et de temporisation « silencieuse » ?
6. Vérification de flow logs : y a-t-il SYN/SYN-ACK/ACK ? Qui bouscule ?
7. Inter-region : quotas/limites de peering/stratégies d'organisation/balises de routage.

12) Anti-modèles

Un mesh « aléatoire » de dizaines de paires sans hub → une explosion de complications et de passes ACL.
L'overlapping du CIDR « en quelque sorte une expérience NAT'om » → une vérification/identification de bout en bout.
L'egress public dans chaque spoke → une surface et un coût incontrôlables.
Absence de split-horizon DNS → fuites de noms/résolves battues.
Itinéraires larges '0. 0. 0. 0/0 'via peer → asymétrie inattendue du trafic.
Modifications manuelles dans la console sans IaC ni révision.

13) Spécificités d'iGaming/Finance

CDE PCI et boucles de paiement - seulement via habs avec inspection ; Pas de spoke↔spoke de contournement.
Résidence de données : IPI/logs transactionnels - au sein des juridictions ; interrégional - agrégats/anonymes.
Multi-PSP : Flux privés/privés vers PSP, proxy centralisé egress via la liste FQDN et mTLS/HMAC.
Audit/WORM : flow-logs et modifications des itinéraires dans un stockage immuable, retentit selon les normes.
Coupes SLO : per region/VPC/tenant ; alerte sur la « fuite egress » et la dégradation des RTT interrégionales.

14) Chèque-liste prod-prêt

• Plan CIDR sans intersections (IPv4/IPv6), pools de croissance réservés.
• Topologie hub-and-spoke ; les fêtes ne sont que des spoke↔hub ; transit par TGW/VWAN/Cloud Router.
• Tables de route : chemins explicites, pas de catch-all via peer, contrôle blackhole.
• Les SG/NSG/NACL sont appliqués ; L7-politiques dans le mesh ; egress uniquement via hub/PrivateLink.
• Les DNS/PHZ privés sont configurés ; conditional-forwarders между on-prem/cloud/regions.
• Flow Logs inclus ; Dashboards par peer/region ; synthétique de faisabilité et tests PMTUD.
• IaC (Terraform/CLI) et Policy-as-Code (OPA/Conftest) pour les règles/itinéraires/DNS.
• Documenté runbook 'et (ajouter peer, dérouler les itinéraires, désactiver spoke).
• Exercice : Désactivation du hub/festin, mesure des RTO/RPO réels des voies du réseau.
• Pour iGaming/Finance : isolation PCI, PrivateLink à PSP, audit WORM, SLO/alerties par pays.

15) TL; DR

Utilisez VPC/VNet Peering pour une simple connectivité privée point-à-point, mais ne comptez pas sur elle pour le transit - vous avez besoin de hub (TGW/VWAN/Cloud Router). Planifiez le CIDR sans intersections, gardez les itinéraires explicites et spécifiques, appliquez stateful SG/NSG et les politiques L7 dans mesh, DNS - split-horizon. Activez les flow-logs, les synthétiques et les contrôles PMTUD. Pour iGaming/Finance - isolation PCI, canaux privés vers PSP et audit inaltérable.