Obiettivi

• Comprendi i concetti alla base di un modello di hub e spoke basato su VPC per la gestione di tutto il traffico VPC - VPC.
• Comprendere l'ingresso e l'instradamento in uscita VPC.
• Identificare e, facoltativamente, risolvere i problemi di instradamento asimmetrico.
• Comprendere l'utilizzo di un Network Load Balancer per un router firewall altamente disponibile e scalabile.
• Utilizza le regole di instradamento e inoltro del servizio DNS per creare un sistema di risoluzione dei nomi architetturalmente solido.

Prima di iniziare

Questa esercitazione richiede:

• terraform per utilizzare IaS (Infrastructure as Code) per il provisioning delle risorse,
• python per eseguire facoltativamente i comandi pytest,
• L'implementazione di un router firewall richiederà di abilitare i controlli di spoofing IP,

Vedi i prerequisiti per alcune opzioni, incluso un Dockerfile, per creare facilmente l'ambiente prerequisito.

Inoltre:

• Controlla le autorizzazioni utente. Assicurati che il tuo account utente abbia autorizzazioni sufficienti per creare e gestire tutte le risorse in questa esercitazione. Vedere l'elenco di:
  • autorizzazioni richieste per VPC.
  • autorizzazioni richieste per la creazione di Transit Gateway.
  • autorizzazioni richieste per i controlli di spoofing IP.
  • autorizzazioni richieste per gestire le autorizzazioni.

Sintesi della prima parte

Nella parte uno di questa esercitazione, abbiamo pianificato attentamente lo spazio di indirizzo dei VPC di transito e di parlato. L'architettura basata sulla zona è mostrata di seguito:

Questo diagramma mostra il flusso di traffico. Solo l'enterprise < -> spoke sta passando attraverso il firewall:

Ciò è stato realizzato con Direct Link, Transit Gateway e l'instradamento VPC. Tutte le zone sono configurate in maniera simile e il seguente diagramma mostra i dettagli della zona 1:

Il CIDR 10.1.0.0/16 copre il transito e gli spoke e viene passato attraverso Direct Link all'azienda come rotta pubblicizzata. Analogamente, il CIDR 192.168.0.0/24 copre l'azienda ed è passato attraverso Transit Gateway ai raggi come rotta pubblicizzata.

Gli instradamenti in uscita nei raggi instradano il traffico al router firewall. Instradamenti Ingress nell'enterprise di instradamento del transito < -> traffico spoke attraverso il router firewall.

Esegui il provisioning delle risorse VPC iniziali instradando tutto il traffico interno VPC attraverso il firewall - router

Spesso un'azienda utilizza un VPC di transito per monitorare il traffico con il router firewall. Nella parte 1, solo il traffico enterprise < -> spoke scorreva attraverso il router firewall di transito. Questa sezione riguarda l'instradamento di tutto il traffico VPC a VPC tramite firewall - router.

Questo diagramma mostra il flusso di traffico implementato in questa fase:

Tutto il traffico tra i VPC passerà attraverso il router firewall:

• enterprise < -> spoke.
• enterprise < -> transito.
• transiti < ->.
• spoke < -> spoke in un VPC differente.

Il traffico all'interno di un VPC non scorrerà attraverso il firewall.

Se si continua dalla prima parte, prendere nota della configurazione in terraform.tfvars: all_firewall = true.

Correggi instradamento tra zone

Come accennato in precedenza per un sistema per essere resiliente tra i guasti zonali, è meglio eliminare il traffico tra zone. Se è richiesto il supporto tra zone, è possibile aggiungere ulteriori instradamenti in uscita. Il problema per il traffico spoke 0 a spoke 1 è mostrato in questo diagramma:

Il percorso verde è un esempio di instradamento del mittente 0 zona 2 10.2.0.4 a 1 zona 1 10.1.1.4. L'instradamento in uscita corrispondente è:

Zona	Destinazione	hop successivo
Dallas10.0.0.0/810.2.15.196

Viene selezionato lo spostamento da sinistra a destra del router firewall nella zona centrale, zona 2, del diagramma. Sul percorso di ritorno è selezionata la zona 1.

Per risolvere questo problema, è necessario aggiungere alcuni instradamenti più specifici per forzare l'instradamento delle zone con un numero più alto ai firewall con un numero di zone più basso quando viene specificata una destinazione con un numero di zone più basso. Quando si fa riferimento a una zona con numero uguale o superiore, continuare l'instradamento al firewall nella stessa zona.

Percorsi nella tabella di routing in uscita predefinita di ogni spoke (mostrato per Dallas/us-sud):

Zona	Destinazione	hop successivo
Dallas10.1.0.0/1610.1.15.196
Dallas10.1.0.0/1610.1.15.196
Dallas10.2.0.0/1610.2.15.196

Questi instradamenti correggono anche un problema di instradamento asimmetrico tra zone di transito < --> simile. Considera l'operatore di transito 10.1.15.4-> spoke 10.2.0.4. Il traffico dall'operatore di transito nella zona 1 sceglierà il router firewall nella zona 1 (stessa zona). Nel viaggio di ritorno invece di firewall - router nella zona 2 (stessa zona) ora verrà utilizzato firewall - router nella zona 1.

1. Applicare il livello all_firewall_asym:

   ./apply.sh all_firewall_asym_tf
   

2. Eseguire la suite di test.

   I risultati attesi sono: tutti i test PASSATI, eseguirli in parallelo (-n 10):

   pytest -n 10 -m curl
   

Tutto il traffico tra VPC è ora instradato attraverso i router firewall.

Firewall HA (High Performance High Availability)- Router

Per evitare che un firewall - router diventi il collo di bottiglia delle prestazioni o un singolo punto di errore, è possibile aggiungere un VPC Network Load Balancer per distribuire il traffico ai router firewall zonali per creare un router firewall altamente disponibile, HA. Controllare la propria documentazione firewall - router per verificare che supporti questa architettura.

Questo diagramma mostra una zona singola con un NLB (Network Load Balancer) configurato in modalità di instradamento di fronte a due router firewall. Per visualizzare questa struttura è necessario modificare la configurazione e applicarla di nuovo.

1. Modificare le seguenti due variabili in config_tf/terraform.tfvars:

   firewall_nlb                 = true
   number_of_firewalls_per_zone = 2
   

   Questa modifica comporta la modifica dell'indirizzo IP del router firewall dall'istanza router firewall utilizzata in precedenza all'indirizzo IP dell'NLB. La modifica dell'indirizzo IP deve essere applicata a un numero di instradamenti della tabella di instradamento VPC nei VPC di transito e spoke. Si consiglia di applicare tutti i livelli precedentemente applicati:

2. Applicare tutti i livelli tramite il livello all_firewall_asym_tf:

   ./apply.sh : all_firewall_asym_tf
   

Osservare le modifiche apportate:

1. Apri i programmi di bilanciamento del carico per VPC.
2. Selezionare il bilanciatore di carico nella zona 1 (Dallas 1/us-south-1) con il suffisso fw-z1-s3.
3. Nota gli IP privati.

Confrontare gli IP privati con quelli nella tabella di instradamento ingresso VPC di transito:

1. Apri Virtual Private Clouds.
2. Selezionare il VPC di transito.
3. Fare clic su Gestisci tabelle di instradamento.
4. Fai clic sulla tabella di instradamento tgw - ingress. Si noti che l'indirizzo IP Next hop corrisponde a uno degli IP privati NLB

Verifica resilienza:

1. Eseguire i test della zona 1 dello spoke:

   pytest -k r-spoke0-z1 -m curl
   

2. Apri le istanze del server virtuale per VPC
3. Arrestare il traffico verso l'istanza del firewall 0 specificando un gruppo di protezione che non consentirà la porta in entrata 80. Individuare l'istanza con il suffisso fw-z1-s3-0 e aprire la vista dei dettagli:
   1. Scorri verso il basso e premi la modifica della matita accanto a Network Interface
   2. Deselezionare x - fw - inall - outall
   3. Controllare x-fw-in22-outall
   4. Fai clic su Save
4. Eseguire nuovamente il pytest. Indicherà gli errori. Ci vorranno alcuni minuti perché l'NLB arresti l'instradamento del traffico all'istanza che non risponde, a quel punto tutti i test avranno esito positivo. Continuare ad attendere ed eseguire pytest fino a quando tutti i test non hanno esito positivo.

Il firewall NLB non è più richiesto. Rimuovere il firewall NLB:

1. Modificare le seguenti due variabili in config_tf/terraform.tfvars:

   firewall_nlb                 = false
   number_of_firewalls_per_zone = 1
   

2. Applicare tutti i livelli tramite il livello all_firewall_asym_tf:

   ./apply.sh : all_firewall_asym_tf
   

Nota su NLB configurato in modalità di instradamento

La modalità di instradamento NLB riscriverà le voci della tabella di instradamento - mantenendo sempre l'indirizzo IP del dispositivo NLB attivo nella tabella di instradamento durante un failover. Ma ciò viene fatto solo per le rotte nel VPC di transito che contengono l'NLB. Il spoke ha instradamenti in uscita che sono state inizializzate con uno degli IP dell'appliance NLB. L'hop successivo spoke non verrà aggiornato sul failover del dispositivo NLB.

Sarà necessario mantenere un instradamento in ingresso nel VPC di transito che verrà riscritto dall'NLB per riflettere il dispositivo attivo. L'instradamento di uscita spoke consegnerà i pacchetti nella zona corretta del VPC di transito. L'instradamento all'interno della zona VPC di transito troverà la regola di ingresso corrispondente che conterrà l'applicazione attiva.

Di seguito è riportata la tabella di instradamento dell'ingresso VPC di transito discussa in precedenza. L'hop successivo verrà mantenuto aggiornato con il dispositivo NLB attivo. Si noti che Dallas 3 ha una modifica scritta dal servizio NLB route mode per riflettere l'appliance attiva.

L'NLB richiede la creazione di un'autorizzazione IAM che consenta all'NLB di scrivere nel VPC. Questa autorizzazione è stata creata dallo script apply.sh. Consultare creazione di un programma di bilanciamento del carico di rete con modalità di instradamento per ulteriori dettagli sulla configurazione eseguita dallo script.

Il pool NLB della modalità di instradamento deve essere configurato con Tipo di persistenza sessione impostato su null.

DNS

Il servizio IBM Cloud DNS Services è utilizzato per convertire nomi in indirizzi IP. In questo esempio viene creato un servizio DNS nel cloud. Viene creata la zona DNS cloud.example.com e il VPC di transito viene aggiunto come rete consentita. I record DNS per le istanze cloud vengono aggiunti a cloud.example.com. Ad esempio, viene creato un record A per il nodo di lavoro spoke 0 nella zona 1 con il nome completo spoke0-z1-worker.cloud.example.com.

Esamina la condivisione DNS per i gateway VPE. Il VPC di transito è abilitato come hub DNS. Ogni VPC spoke è configurato con il bind della risoluzione DNS all'hub VPC di transito. Ciò configurerà le impostazioni DHCP VPC spoke per i server DNS in modo che siano i resolver personalizzati VPC di transito.

./apply.sh dns_tf

pytest -n 10 -m dns

gateway endpoint privato virtuale

VPC consente l'accesso privato ai servizi IBM Cloud tramite Virtual Private Endpoint (VPE) for VPC. I gateway VPE consentono il controllo dell'accesso alla rete granulare tramite controlli IBM Cloud VPC standard:

• Security Groups.
• ACL(Network Access Control List)VPC
• Instradamento di tabelle e instradamenti.

Viene creata una zona DNS per ogni gateway VPC VPE. La zona DNS viene automaticamente aggiunta al servizio DNS privato associato al VPC. Ogni VPC spoke ha una configurazione DNS bound per il VPC di transito. Ciò consente alla zona DNS VPE spoke di essere condivisa con il VPC di transito.

1. Crea un'istanza IBM Cloud Databases for PostgreSQL e i VPE per il transito e ciascuno dei VPC spoke, applicando i livelli vpe_transit_tf e vpe_portavoce tf:

   ./apply.sh vpe_transit_tf vpe_spokes_tf
   

2. Esiste una serie di test vpe e vpedns disponibili nello script pytest. Il test vpedns verificherà che il nome DNS di un'istanza Databases for PostgreSQL si trovi all'interno del blocco CIDR privato del VPC di inclusione. Il test di vpe eseguirà un comando psql per accedere all'istanza Databases for PostgreSQL in remoto. Test vpe e vpedns da spoke 0 zone 1:

   • Risultati previsti: tutti i test sono stati superati

   pytest -m 'vpe or vpedns' -k spoke0-z1
   

Tutti i test in questa esercitazione dovrebbero ora avere esito positivo. Ce ne sono parecchi. Eseguirli in parallelo:

pytest -n 10

Note di produzione e conclusioni

L' architettura di riferimento VPC per IBM Cloud for Financial Services ha molti più dettagli sulla protezione dei carichi di lavoro in IBM Cloud.

Alcune ovvie modifiche da apportare:

• I blocchi CIDR sono stati scelti per chiarezza e facilità di spiegazione. Le zone di disponibilità nella regione multizona potrebbero essere 10.1.0.0/10, 10.64.0.0/10, 10.128.0.0/10 per conservare lo spazio di indirizzo. Allo stesso modo, lo spazio di indirizzo per i nodi di lavoro potrebbe essere espanso a spese di firewall, DNS e spazio VPE.
• I gruppi di sicurezza per ciascuna delle interfacce di rete per le VSI del nodo di lavoro, i gateway endpoint privati virtuali, le ubicazioni DNS e i firewall devono essere attentamente considerati.
• Gli elenchi di controllo dell'accesso di rete per ogni sottorete devono essere attentamente considerati.
• Gli IP mobili sono stati collegati a tutte le istanze di test per supportare i test di connettività tramite SSH. Questo non è richiesto o desiderabile in produzione.
• Implementare le regole di restrizioni basate sul contesto per controllare ulteriormente l'accesso a tutte le risorse.

In questa esercitazione hai creato un VPC hub e una serie di VPC spoke. Hai instradato tutto il traffico tra VPC attraverso un router firewall VPC di transito. È stato creato un servizio DNS per l'hub VPC di transito e ogni VPC spoke era collegato al VPC di transito.

Rimuovi le risorse

Eseguire terraform destroy in tutte le directory in ordine inverso utilizzando il comando ./apply.sh :

./apply.sh -d : :

Espandi l'esercitazione

La tua architettura potrebbe non essere la stessa di quella presentata, ma probabilmente sarà costruita dai componenti fondamentali discussi qui. Idee per espandere questa esercitazione:

• Integra l'accesso Internet pubblico in entrata utilizzando IBM Cloud® Internet Services.
• Aggiungi Flow Logs for VPC capture nel transito.
• Inserisci ciascuno degli spokes in un account separato in un' azienda.
• Forzare parte del traffico spoke a spoke attraverso il firewall e alcuni non attraverso il firewall.
• Sostituisci le VSI del nodo di lavoro con Red Hat OpenShift on IBM Cloud e il programma di bilanciamento del carico VPC.
• Forza tutto il traffico collegato in uscita attraverso il firewall nel VPC di transito e tramite gateway pubblici.

Contenuto correlato

• IBM Cloud per i servizi finanziari
• Come distribuire i carichi di lavoro isolati in più ubicazioni e regioni
• Front end pubblico e backend privato in un Virtual Private Cloud,
• Network Function Virtualization
• Hub privato e spoke con traffico VNF e spoke trasparente