Routing e routing VPC

1) Perché Peering e quando è appropriato

• Separazione tra ambienti e domini (prod/stage/dave) con connettività privata condivisa
• introduzione di piattaforme condivise (loging, KMS/Vault, artefatti) in una rete shared
• accesso da applicazioni a percorsi privati gestiti (tramite hub/endpoint ').

Quando è meglio non peering, ma hab: più di 10-20 reti, necessità di routing in transito, egress centralizzato, interconnessioni → utilizzare Transit Gateway/Virtual WAN/Cloud Router.

2) Modelli e vincoli

2. 1 Tipi di piringa

Intra-region peering - all'interno della regione, ritardi minimi e costo.
inter-region peering - tra le regioni, solitamente pagato traffico interregionale.
Cross-project/account è un piring tra account/progetti diversi (con delega).

2. 2 Transito e NAT

Il classico VPC/VNet Peering non è transitivo: una rete di A↔B e B↔C non significa A↔C.
NAT tramite la rete intermedia di transito - anti-pattern (rompe IP di origine, controllo complesso).
Per il transito, hab-bus: AWS Transit Gateway (TGW), Azure Virtual WAN/Hub, GCP Cloud Router/HA VPN/Peering Router.

2. 3 Overlapping CIDR

• Sovrappeso indirizzi (opzione migliore)
• Domini NAT/Proxy VPC con schemi unilaterali (basati su verifiche e loging)
• Per le PaaS specifiche, PrivateLink/PSC senza accesso L3.

3) Progettazione di indirizzi e percorsi

3. 1 Pianificazione CIDR

Un unico supernet (es. '10. 0. 0. 0/8 ') → in «region/eng/vpc».
Riservare gli intervalli ai futuri VPC/tenanti (growth-buffers).
Il piano IPv6 è in anticipo: '/56 'su VPC, '/64' su subnet.

3. 2 Routing

Route table: su ogni VPC/subnet percorsi espliciti su peer/hub.
Priorità: un prefisso più specifico vince; evitare catch-all attraverso il piring.
Protezione Blackhole: contrassegnare e pulire i percorsi duplicati/obsoleti.

3. 3 Domini e ruoli

Spoke (applicazioni) ↔ Hub (servizi comuni, egress, ispezione).
I banchi sono solo spoke↔hub; spoke↔spoke - attraverso hab (segmentazione e controllo).

4) Pattern topologie

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

Pin-to-pin diretto (A↔B, A↔C...). Più: minimo di componenti; meno: O (N m2) collegamenti e regole.

4. 2 Hub-and-Spoke

Tutti gli spoke con Hub VPC/VNet; nell'hub - TGW/Virtual WAN/Cloud Router, NAT/egress, ispezione. Scalabile, semplice da gestire.

4. 3 Regione Multi

Hub locali in ogni regione; tra gli hub - inter-region peering o autostrada (TGW-to-TGW/VWAN-to-VWAN).

5) Sicurezza e segmentazione

Stateful sull'host: SG/NSG - la barriera principale; Le ACL NASL/subnet sono una recinzione ruvida/fogli deny.
L7 criteri in mesh/proxy (Istio/Avvoy/NGINX) - Autorizzazione per mTLS/JWT/claims.
Egress Control: spoke non deve «vedere» direttamente Internet - solo tramite il gateway egress/Private Link.
Flow Logs e ispezione nell'hub (GWLB, IDS/IPS) per traffico MJ-VPC.

6) DNS и split-horizon

Ogni zona privata è visibile su VPC (Private Hosted Zone/Private DNS/Zone).
Ci sono registrazioni private su IP endpoint'o private.
Conditional forwarding между on-prem ↔ cloud и region ↔ region.
Denominazione: 'svc. env. region. internal. corp' - senza PII; Fissare TTL (30-120s) come faulover.

7) Osservabilità e test

Metriche: accetted/denied su SG/NSG, byts per peer, RTT/jitter tra le regioni, top talkers.
Logi: VPC Flow Logs/NSG Flow Logs in SIEM, traccia con «trace _ id» per la corellazione del L7↔L3.
Test di fattibilità: sintetico TCP/443/DB-porte provenienti da sottoassiemi/AZ/regioni; reachability analyzer.
Rete Chaos: ritardi/perdite tra peer/hub; controllo timeout/retrai/idipotenza.

8) Prestazioni e costi

inter-region è quasi sempre tariffato; Leggi l'egress in anticipo (prezioso per logi/bacapi).
MTU/PMTUD: MTU standard all'interno del provider, ma ai confini (VPN, FW, NAT-T) tenere conto di MSS-clamp.
Ridimensionamento orizzontale dell'ispezione (GWLB/scale set) senza colli di bottiglia; ECMP per gli hub.
Cache/edge e SWR riducono il traffico interregionale.

9) Caratteristiche cloud e esempi

9. 1 AWS (VPC Peering / Transit Gateway)

VPC Peering - Crea peering connection e aggiungi percorsi nelle tabelle delle selezioni.
Non c'è transito attraverso il solito peering. Per il transito e il modello centralizzato - 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 (incluso il globale): flag Allow forwarded traffic, Use remote gateway per diagrammi hab.
Per hub e transito - Virtual WAN/Hub con Route Table e 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 senza transito; per il centro - Cloud Router + HA VPN/Peering Router.
Hierarchical FW для org-guardrails.

10) Kubernets nelle reti di piring

Cluster spoke, servizi condivisi (loging/archiviazione/manufatti) - in hub; Accesso privato.
«deny-all» e egress esplicito su hub/Private Link.
Non «trascinare» Pod CIDR tra VPC; Routare Node CODR e utilizzare Ingress/Gateway.

11) Trablshuting (tacca)

1. I CIDR non si intersecano? Controlla i super set/le vecchie reti.
2. Tabelle rotte - C'è un percorso in entrambe le direzioni? C'è un percorso più specifico che intercetta il traffico?
3. SG/NSG/NACL: stateful-in/out corrispondono? L'ACL subnet non blocca il traffico inverso?
4. DNS: voci private/forwarders corrette? Controlla dì dean + short "da entrambe le reti.
5. MTU/MSS/PMTUD: nessuna frammentazione e timeout silenziosi?
6. Controllo flow logs: esiste SYN/SYN-ACK/ACK? Chi sta drappando?
7. inter-region: quote/limiti di piringa/regole di organizzazione/tag di routing.

12) Antipattern

Un mesh casuale di dozzine di banchi senza hub ha fatto esplodere le complicazioni e i pass dell'ACL.
L'overlapping CIDR «in qualche modo ripercorreremo il NAT».
Egress pubblici in ogni spoke → una superficie incontrollabile e il costo.
Assenza di split-horizon DNS per la fuoriuscita di nomi/risvolti a bit.
Le rotte sono ampie '0. 0. 0. 0/0 'attraverso il peer c'è un'asimmetria inaspettata del traffico.
Modifiche manuali nella console senza IaC o revisione.

13) Specificità iGaming/finanza

PCI CDE e tracciati di pagamento - solo tramite hab con ispezione; Non c'è nessun controllo.
Data residency: logici di transazione PII - all'interno delle giurisdizioni; interregionale - aggregati/anonimi.
Multi-PSP: Private Link/canali PSP, proxy centralizzato per allowlist FQDN e mTLS/HMAC.
Controllo/WORM: flow-logs e modifiche alle rotte dello storage invariato, retensioni secondo le norme.
Tagli SLO: per region/VPC/tenant; gli alert per la fuga di egress e il degrado della RTT interregionale.

14) Foglio di assegno prod

• Piano CIDR senza intersezioni (IPv4/IPv6), pool di crescita riservati.
• Topologia hub-and-spoke; I banchi sono solo spoke↔hub; transito su TGW/VWAN/Cloud Router.
• Route table: percorsi chiari, nessun catch-all attraverso peer, controllo blackhole.
• SG/NSG/NACL applicati; Regole L7 in mesh; egress solo tramite hab/Private Link.
• Private DNS/PHZ configurati; conditional-forwarders между on-prem/cloud/regions.
• Flow Logs abilitati dashboard peer/region; sintetico di raggiungibilità e test PMTUD.
• IaC (Terraform/CLI) e Policy-as-Code (OPA/Conftest) per le regole/rotte/DNS.
• Sono stati documentati runbook 'e (aggiungi peer, disattiva le rotte, disattiva spoke).
• Esercitazione: disattivazione dell'hub/banchetto, misurazione dei percorsi di rete effettivi RTO/RPO.
• Per iGaming/Finanza: isolamento PCI, controllo PSP, controllo WORM, SLO/alert per giurisdizione.

15) TL; DR

Utilizzare VPC/VNet Peering per una semplice connettività punto-a-punto, ma non fare affidamento su di esso per il transito, che richiede un hub (TGW/VWAN/Cloud Router). Pianificare la CIDR senza intersezioni, mantenere i percorsi evidenti e specifici, applicare la stateful SG/NSG e le regole L7 in mesh, DNS - split-horizon. Attivare i controlli flow, sintetici e PMTUD. Per iGaming/Finanza, isolamento PCI, canali PSP privati e controllo invariato.