Obiettivi

• Comprendere i concetti alla base di un modello di hub e spoke basato su VPC.
• Comprendere l'implementazione di un router firewall e di un ambiente VPC di transito.
• Comprendere l'ingresso e l'instradamento in uscita VPC.
• Identificare e, facoltativamente, risolvere i problemi di instradamento asimmetrico.
• Connetti i VPC tramite un Transit Gateway.

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,
• Una chiave SSH per connettersi ai server virtuali. Se non hai una chiave SSH, segui le istruzioni per creare una chiave per VPC.

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.

Indirizzo IP e layout di sottorete

In questo passo esegui il provisioning delle risorse di rete VPC. Pianifica attentamente progettando un piano di indirizzamento per un VPC e utilizza blocchi CIDR non sovrapposti.

È allettante dividere prima lo spazio CIDR da VPC, ma questo complica l'instradamento. Invece, pensa a una zona di disponibilità come a un singolo blocco CIDR e ogni VPC ne consuma una parte.

Questo diagramma mostra solo la zona 1 in modo più dettagliato. Le dimensioni della sottorete e il layout sono identici nelle altre zone:

Sopra l'azienda si trova a sinistra e IBM Cloud a destra. In IBM Cloud per semplicità viene rappresentata una singola zona per il VPC di transito e Spoke 0. Tieni presente che i blocchi CIDR non si sovrappongono e che i VPC utilizzano tutti un blocco CIDR in ogni zona:

• Il CIDR in loco è 192.168.0.0/16.
• Le zone in questa regione multizona sono 10.*.0.0/16. La seconda cifra: 1, 2, 3 è il numero della zona (indicato per Dallas/us-sud):
  • 10.10.1.0.0/16, zona 1, Dallas 1, us-south-1.
  • 10.10.2.0.0/16, zona 2, Dallas 2, us-south-2.
  • 10.10.3.0.0/16, zona 3, Dallas 3, us-south-3.
• Il VPC di transito utilizza i CIDR 10.*.15.0/24:
  • 10.1.15.0/24, zona 1.
  • 10.2.15.0/24, zona 2.
  • 10.3.15.0/24, zona 3.
• Spoke 0 utilizza 10.*.0.0/24 o CIDR:
  • 10.1.0.0/24, zona 1.
  • 10.2.0.0/24, zona 2.
  • 10.3.0.0/24, zona 3.
• I CIDR della sottorete dividono ulteriormente il /24 in /26.

Le sottoreti nel transito e nel spoke sono per tipi di risorsa differenti:

• Istanze VPC, programmi di bilanciamento del carico, Red Hat OpenShift, ecc. Le istanze VPC sono illustrate in questa esercitazione.
• dns - Dispositivi di ubicazione DNS Services utilizzati nella seconda parte.
• vpe - VPE for VPC utilizzato nella seconda parte.
• Istanze VPC fw - firewall - router (solo in transito).

Esegui il provisioning delle risorse di rete VPC

1. Il GitHub Repository ha i file di origine per implementare l'architettura. In una shell desktop clonare il repository:

   git clone https://github.com/IBM-Cloud/vpc-transit
   cd vpc-transit
   

2. La directory config_tf contiene le variabili di configurazione che è necessario configurare.

   cp config_tf/template.terraform.tfvars config_tf/terraform.tfvars
   

3. Modifica config_tf/terraform.tfvars e utilizza i commenti in tale file come guida.

4. Poiché è importante che ogni livello sia installato nell'ordine corretto e che alcuni passi in questa esercitazione installino più livelli, viene fornito un comando shell ./apply.sh. Di seguito viene visualizzata la guida:

   ./apply.sh
   

5. È possibile applicare tutti i livelli configurati eseguendo ./apply.sh : :. I due punti sono abbreviati per primo (o config_tf) e ultimo (power_tf). -p stampa i layer:

   ./apply.sh -p : :
   

   Sarà qualcosa di simile a:

   directories: config_tf enterprise_tf transit_tf spokes_tf transit_spoke_tgw_tf test_instances_tf test_lbs_tf enterprise_link_tf firewall_tf transit_ingress_tf spokes_egress_tf all_firewall_tf all_firewall_asym_tf dns_tf vpe_transit_tf vpe_spokes_tf power_tf
   

6. Se non ne avete già una, ottenete una chiave API della piattaforma ed esportate la chiave API per l'uso da parte di Terraform:

   export IBMCLOUD_API_KEY=YourAPIKEy
   

7. In questo primo passo si applicano config_tf, enterprise_tf, transit_tf, portavoce tf e transit_spoke_tgw_tf:

   ./apply.sh : transit_spoke_tgw_tf
   

I VPC e le sottoreti sono stati creati. I VPC di transito e spoke sono stati collegati tramite un Transit Gatewaydi cui è stato eseguito il provisioning. Apri Virtual Private Clouds nel browser. Apri il VPC di transito e prendi nota dei blocchi CIDR per i prefissi di indirizzo e le sottoreti. Esaminare anche i VPC enterprise e spoke. Apri Transit Gateway e fai clic sul gateway di transito per vedere la connessione tra i VPC di transito e spoke.

Crea istanze di test

Le VSI (Virtual Server Instance) VPC vengono fornite per verificare la connettività di rete. Un'istanza di test verrà aggiunta a ognuna delle sottoreti del nodo di lavoro (una per zona) nell'azienda, nel transito e in ciascuno dei raggi. Se viene utilizzata la configurazione predefinita di 3 zone e 2 raggi, verrà eseguito il provisioning di 12 istanze.

1. Crea le istanze di test

   ./apply.sh test_instances_tf
   

Può essere illuminante esplorare le risorse create in ogni passo della console IBM Cloud. Facoltativamente, apri Virtual Private Clouds. Sulla sinistra fai clic su Virtual server instances e nota le istanze che sono state create.

Esecuzione di test

Questa esercitazione aggiungerà percorsi di comunicazione un livello alla volta. Una suite di test pytest verrà utilizzata per verificare in modo esaustivo i percorsi di comunicazione. Alla fine dell'esercitazione si prevede che tutti i test vengano superati.

Non è richiesto che il lettore utilizzi pytest per verificare i risultati. Seguire l'esercitazione, applicare i livelli e considerare attendibili i risultati descritti nell'esercitazione. Il lettore può ancora esplorare le risorse VPC come le VSI, le sottoreti e le tabelle di instradamento dopo che sono state create.

Ogni test pytest eseguirà l'SSH su una delle istanze ed eseguirà un tipo di test di connettività, come l'eseguire un comando curl su una delle altre istanze. L'ambiente SSH predefinito viene utilizzato per accedere alle istanze. Se vedi risultati di test non previsti, prova la sezione pytest troubleshooting.

1. Eseguire i test di zona 1 curl nella suite utilizzando l'indicatore -m (indicatori). Scegli i test contrassegnati con curl, lz1 (zona sinistra 1) e rz1 (zona destra 1).

   I risultati previsti sono: la connettività all'interno di un VPC, come enterprise < -> enterprise sarà PASSATO. La connettività tra transito e raggi sarà Passato. Cross VPC da enterprise -> transito o raggi sarà NON RIUSCITO.

   pytest -m "curl and lz1 and rz1"
   

   Di seguito è riportato un esempio di output:

   root@ea28970e0897:/usr/src/app# pytest -m "curl and lz1 and rz1"
   ===================================================== test session starts ======================================================
   platform linux -- Python 3.12.3, pytest-8.1.1, pluggy-1.4.0 -- /usr/local/bin/python
   cachedir: .pytest_cache
   rootdir: /usr/src/app
   configfile: pytest.ini
   testpaths: py
   plugins: xdist-3.5.0
   collected 36 items / 20 deselected / 16 selected
   
   py/test_transit.py::test_curl[l-enterprise-z1-worker -> r-enterprise-z1-worker] PASSED                                   [  6%]
   py/test_transit.py::test_curl[l-enterprise-z1-worker -> r-transit-z1-worker] FAILED                                      [ 12%]
   py/test_transit.py::test_curl[l-enterprise-z1-worker -> r-spoke0-z1-worker] FAILED                                       [ 18%]
   py/test_transit.py::test_curl[l-enterprise-z1-worker -> r-spoke1-z1-worker] FAILED                                       [ 25%]
   py/test_transit.py::test_curl[l-transit-z1-worker -> r-enterprise-z1-worker] FAILED                                      [ 31%]
   py/test_transit.py::test_curl[l-transit-z1-worker -> r-transit-z1-worker] PASSED                                         [ 37%]
   py/test_transit.py::test_curl[l-transit-z1-worker -> r-spoke0-z1-worker] PASSED                                          [ 43%]
   py/test_transit.py::test_curl[l-transit-z1-worker -> r-spoke1-z1-worker] PASSED                                          [ 50%]
   py/test_transit.py::test_curl[l-spoke0-z1-worker -> r-enterprise-z1-worker] FAILED                                       [ 56%]
   py/test_transit.py::test_curl[l-spoke0-z1-worker -> r-transit-z1-worker] PASSED                                          [ 62%]
   py/test_transit.py::test_curl[l-spoke0-z1-worker -> r-spoke0-z1-worker] PASSED                                           [ 68%]
   py/test_transit.py::test_curl[l-spoke0-z1-worker -> r-spoke1-z1-worker] PASSED                                           [ 75%]
   py/test_transit.py::test_curl[l-spoke1-z1-worker -> r-enterprise-z1-worker] FAILED                                       [ 81%]
   py/test_transit.py::test_curl[l-spoke1-z1-worker -> r-transit-z1-worker] PASSED                                          [ 87%]
   py/test_transit.py::test_curl[l-spoke1-z1-worker -> r-spoke0-z1-worker] PASSED                                           [ 93%]
   py/test_transit.py::test_curl[l-spoke1-z1-worker -> r-spoke1-z1-worker] PASSED                                           [100%]
   
   =================================================== short test summary info ====================================================
   FAILED py/test_transit.py::test_curl[l-enterprise-z1-worker -> r-transit-z1-worker] - assert False
   FAILED py/test_transit.py::test_curl[l-enterprise-z1-worker -> r-spoke0-z1-worker] - assert False
   FAILED py/test_transit.py::test_curl[l-enterprise-z1-worker -> r-spoke1-z1-worker] - assert False
   FAILED py/test_transit.py::test_curl[l-transit-z1-worker -> r-enterprise-z1-worker] - assert False
   FAILED py/test_transit.py::test_curl[l-spoke0-z1-worker -> r-enterprise-z1-worker] - assert False
   FAILED py/test_transit.py::test_curl[l-spoke1-z1-worker -> r-enterprise-z1-worker] - assert False
   ========================================= 6 failed, 10 passed, 20 deselected in 38.76s =========================================
   

Una modifica alla configurazione di rete può richiedere un paio di esecuzioni di test affinché il sistema di rete VPC sottostante diventi coerente. Se non vengono visualizzati i risultati previsti, è necessario eseguire nuovamente il test un paio di volte.

r e l - stanno per r ight e l eft. La parte centrale del nome identifica enterprise, transit, spoke0, spoke1, ... z1, z2, ... identificano la zona. Il test sarà SSH sull'istanza di sinistra. Sull'istanza di sinistra viene tentata la connettività all'istanza di destra. test_curl esegue una connettività curl sull'istanza di sinistra all'istanza di destra.

In sintesi, il test test_curl[l-enterprise-z1 -> r-transit-z1] :

1. SSH a un'istanza di test nella zona aziendale 1.
2. Eseguire un curl nella zona di transito 1.
3. La stringa di ritorno contiene l'ID della zona di transito 1 da contrassegnare come riuscita o non riuscita.

Il file README.md nel GitHub Repository ha ulteriori dettagli e il codice sorgente.

Connetti Enterprise a Transit tramite Direct Link e Transit Gateway

Eseguire il provisioning di IBM Cloud® Direct Link utilizzando Transit Gateway.

IBM Cloud® Direct Link è un percorso dati sicuro ad alta velocità per la connessione di un'azienda a IBM Cloud. In questa esercitazione Transit Gateway viene utilizzato per la distribuzione. L'utilizzo di Transit Gateway è facoltativo per una connessione in loco.

L'azienda in questa esercitazione viene simulata con un'altro VPC. La connessione di questa azienda simulata (in realtà un altro VPC) tramite Transit Gateway garantirà un'esperienza molto simile a quella che avresti con un Direct Link.

1. Applicare il livello enterprise_link_tf:

   ./apply.sh enterprise_link_tf
   

2. Eseguire i test curl della zona 1 nella suite utilizzando l'indicatore -m (contrassegni). Scegli i test contrassegnati con curl, lz1 (zona sinistra 1) e rz1 (zona destra 1).

   I risultati previsti sono: la connettività all'interno di un VPC, transito < -> spoke, azienda < -> transito, spoke < -> spoke pass ma enterprise < -> spoke non riesce.

   pytest -m "curl and lz1 and rz1"
   

Connetti Enterprise a Spoke (s) tramite Transit NFV Firewall - Router

L'incentivo per un VPC di transito per il traffico cloud < -> aziendale è in genere instradare, ispezionare, monitorare e registrare il traffico di rete. In questo passo verrà installata un'applicazione router firewall in ogni zona del VPC di transito.

Router NFV

Eseguire il provisioning delle applicazioni firewall - router. Una tabella di instradamento Ingress per Transit Gateway è stata aggiunta al VPC di transito come indicato dalle linee tratteggiate. È stata creata una sottorete in ciascuna delle zone del VPC di transito per contenere il router firewall.

La connettività dall'azienda a un spoke viene raggiunta tramite un'istanza firewall - router NFV di Network Function Virtualization nel VPC di transito. In produzione è possibile sceglierne uno dal catalogo o portarne uno proprio. Questa dimostrazione utilizzerà un'immagine stock Ubuntu con kernel iptables impostato per inoltrare tutti i pacchetti dall'origine alla destinazione. In questa esercitazione, non viene eseguito alcun controllo firewall.

La configurazione Terraform configurerà l'istanza firewall - router con allow_ip_spoofing. È necessario abilitare i controlli di spoofing IP prima di continuare.

1. Applicare il livello firewall_tf:

   ./apply.sh firewall_tf
   

2. Eseguire la suite di test.

   I risultati previsti sono: la connettività all'interno di un passaggio di zona VPC, enterprise -> transit, enterprise < -> spoke. Ma tutti i transiti -> spoke, tutti i transiti -> enterprise falliscono a causa di problemi di instradamento asimmetrici.

   pytest -m "curl and lz1 and (rz1 or rz2)"
   

   La parte due di questa esercitazione instraderà tutto il traffico VPC < -> differente attraverso il router firewall e risolverà questi problemi. Ma prima è importante capire cosa sta succedendo.

Rimozione del firewall per il traffico di destinazione del transito

IBM Cloud VPC utilizza l'instradamento basato sullo stato standard del settore per la traccia della connessione TCP sicura. Richiede che le connessioni TCP utilizzino lo stesso percorso di uscita. Un'eccezione è Direct Server Return utilizzato dai router come Network Load Balancer. Consente alle connessioni in entrata dall'enterprise di passare attraverso il firewall all'istanza di test del transito e quindi tornare direttamente al mittente.

Ciò non aiuta con il traffico che ha origine nell'istanza di test del transito che passa attraverso Transit Gateway quindi di nuovo attraverso l'instradamento in ingresso al router del firewall. Questa connessione si blocca sul firewall - router (3) e non verrà inoltrata nuovamente al nodo di lavoro come mostrato in rosso di seguito. Transito del traffico -> impresa e transito -> spoke stanno fallendo.

Una possibile soluzione è quella di interrompere l'invio del traffico destinato al VPC di transito al router firewall. Gli ampi instradamenti di ingresso per il transito stanno attualmente instradando il traffico al router firewall. È possibile aggiungere instradamenti più specifici per il transito a Delega al comportamento predefinito - inviare direttamente alla destinazione prevista invece che al router firewall.

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

1. enterprise < -> transito
2. transito < -> spoke
3. spoke < -> spoke
4. enterprise <--transit firewall-router--> spoke

Questo instradamento può essere ottenuto aggiungendo questi instradamenti alla tabella di instradamento di ingresso di transito:

1. Per osservare il valore corrente della tabella di instradamento in ingresso, visita la console Routing tables for VPC nella console IBM Cloud. Seleziona il VPC transit dal menu a discesa e seleziona quindi la tabella di instradamento tgw - ingress.

2. Apportare le modifiche alla tabella di instradamento applicando il livello transit_ingress:

./apply.sh transit_ingress_tf

1. Aggiornare la visualizzazione del browser della tabella di instradamento per osservare i nuovi instradamenti.

2. Eseguire la suite di test.

   I risultati previsti sono: Tutti i test risulteranno in SUPERATO.

   pytest -m "curl and lz1 and (rz1 or rz2)"
   

È interessante notare come il traffico tra zone scorra tra l'azienda e gli spoke nella configurazione. Enterprise invia il traffico alla zona corretta e attraverso il firewall - router tramite l'instradamento in ingresso nel VPC di transito. Transit Gateway ha appreso che 192.168.0.0/16 è disponibile in tutte le zone e verrà instradato al VPC di transito utilizzando le rotte aziendali pubblicizzate nella stessa zona del spoke come mostrato nel diagramma riportato di seguito:

Riepilogo instradamento

L'instradamento di base è completo:

• enterprise < -> transito
• transito < -> spoke (s)
• enterprise < -- (router - firewall di transito)--> spoke

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.0.0.0/10, 10.64.0.0/10, 10.128.0.0/10 per conservare lo spazio di indirizzo. Lo spazio di indirizzo per i nodi di lavoro potrebbe essere espanso a scapito dello spazio firewall, DNS e 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 identificato le zone di disponibilità richieste per l'architettura e creato una serie di sottoreti nei VPC. Hai creato un router firewall VPC di transito in ciascuna zona per l'inoltro del traffico. Le istanze di test sono state utilizzate per verificare la connettività e identificare potenziali problemi. Gli instradamenti della tabella di instradamento sono stati utilizzati per identificare i percorsi di traffico richiesti.

Rimuovi le risorse

Non è necessario rimuovere le risorse se si intende continuare con la seconda parte di questa esercitazione.

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

./apply.sh -d : spokes_egress_tf

Espandi l'esercitazione

Ti invitiamo a passare alla parte due di questa esercitazione in cui tutto il traffico tra VPC viene instradato tramite il router firewall, VPE for VPC e DNS vengono esaminati.

La tua architettura sarà probabilmente diversa da quella presentata, ma sarà probabilmente costruita dai componenti fondamentali discussi qui. Idee per espandere questa esercitazione:

• Integra l'accesso Internet pubblico in entrata utilizzando IBM Cloud® Internet Services.
• Aggiungere flow log 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