Codelab sulle route basate su criteri (PBR)

1. Introduzione

Route basate su criteri

Le route basate su criteri ti consentono di scegliere un hop successivo in base a più di un indirizzo IP di destinazione di un pacchetto. Puoi anche abbinare il traffico per protocollo e indirizzo IP di origine. Il traffico corrispondente viene reindirizzato a un bilanciatore del carico di rete interno. In questo modo puoi inserire appliance come i firewall nel percorso del traffico di rete.

Quando crei una route basata su criteri, puoi selezionare le risorse che possono elaborare il traffico dalla route. Il percorso può essere applicato a:

  • L'intera rete: tutte le istanze di macchine virtuali (VM), i gateway VPN e le interconnessioni
  • Utilizzo dei tag di rete: selezione delle istanze VM nel VPC
  • Regione Interconnect: tutto il traffico che entra nella rete VPC tramite collegamenti VLAN per la regione

L'hop successivo di una route basata su criteri deve essere un bilanciatore del carico di rete interno valido che si trova nella stessa rete VPC della route basata su criteri.

I bilanciatori del carico di rete interni utilizzano l'hashing simmetrico per impostazione predefinita, in modo che il traffico possa raggiungere la stessa appliance sui percorsi di uscita e di ritorno senza configurare il NAT di origine.

Le route basate su criteri hanno una priorità più elevata rispetto agli altri tipi di route, ad eccezione dei percorsi di ritorno speciali.

Se due route basate su criteri hanno la stessa priorità, Google Cloud utilizza un algoritmo interno deterministico per selezionare una singola route basata su criteri, ignorando le altre route con la stessa priorità. Le route basate su criteri non utilizzano la corrispondenza con prefisso più lungo e selezionano solo la route con priorità più alta.

Puoi creare un'unica regola per il traffico unidirezionale o più regole per gestire il traffico bidirezionale.

Per utilizzare le route basate su criteri con Cloud Interconnect, la route deve essere applicata a tutte le connessioni Cloud Interconnect in un'intera regione. Le route basate su criteri non possono essere applicate solo a una singola connessione Cloud Interconnect.

Le istanze VM che ricevono traffico da una route basata su criteri devono avere l'inoltro IP abilitato.

Considerazioni relative a PBR

Per utilizzare le route basate su criteri nei modi indicati di seguito, è necessaria una configurazione speciale.

ad esempio utilizzando PBR con GKE, PSC o con PGA/PSA.

Maggiori dettagli su PBR con GKE sono disponibili qui e la sezione sulle limitazioni generali di PBR qui.

Obiettivi didattici

  • Come configurare route basate su criteri

Che cosa ti serve

  • Conoscenza della distribuzione delle istanze e della configurazione dei componenti di networking
  • Conoscenza della configurazione del firewall VPC

2. Ambiente di test

Questo codelab sfrutterà un singolo VPC. In questo ambiente ci saranno due risorse di computing, clienta e clientb, che invieranno i pacchetti a un'altra risorsa server. Utilizzando PBR e filtri, forzeremo il traffico da clienta a un'altra risorsa di computing per l'applicazione del firewall, mentre il traffico clientb va direttamente al server. Il diagramma seguente illustra il percorso.

bff32b01ada8e9ad.png

Nel diagramma riportato sopra, tecnicamente dovrebbe essere presente un bilanciatore del carico interno di rete (ILB) per i percorsi PBR. Questa opzione è stata omessa per semplicità del diagramma.

3. Prima di iniziare

Il codelab richiede un singolo progetto.

Da Cloudshell:

export project_id=`gcloud config list --format="value(core.project)"`
export region=us-central1
export zone=us-central1-a
export prefix=codelab-pbr

4. Abilita API

Se non lo hai già fatto, abilita le API per utilizzare i prodotti

Da Cloudshell:

gcloud services enable compute.googleapis.com
gcloud services enable networkconnectivity.googleapis.com

5. Crea rete e subnet VPC

Rete VPC

Crea VPC codelab-pbr-vpc:

Da Cloudshell:

gcloud compute networks create $prefix-vpc --subnet-mode=custom 

Subnet

Crea le rispettive subnet nella regione selezionata:

Da Cloudshell:

gcloud compute networks subnets create $prefix-vpc-subnet \
   --range=10.10.10.0/24 --network=$prefix-vpc --region=${region}

6. Crea regole firewall

Per consentire a IAP di connettersi alle tue istanze VM, crea una regola firewall che:

  • Si applica a tutte le istanze VM a cui vuoi rendere accessibile tramite IAP.
  • Consente il traffico in entrata dall'intervallo IP 35.235.240.0/20. Questo intervallo contiene tutti gli indirizzi IP utilizzati da IAP per l'inoltro TCP.

Da Cloudshell:

gcloud compute firewall-rules create $prefix-allow-iap-proxy \
--direction=INGRESS \
--priority=1000 \
--network=$prefix-vpc \
--action=ALLOW \
--rules=tcp:22 \
--source-ranges=35.235.240.0/20

Per autorizzare la porta HTTP standard (TCP 80) e il protocollo ICMP al server:

  • Si applica alle risorse con tag di rete "server"
  • Consente il traffico in entrata da tutte le origini

Da Cloudshell:

gcloud compute firewall-rules create $prefix-allow-http-icmp \
--direction=INGRESS \
--priority=1000 \
--network=$prefix-vpc \
--action=ALLOW \
--rules=tcp:80,icmp \
--source-ranges=0.0.0.0/0 \
--target-tags=server

Per consentire al firmware di ricevere i pacchetti, consenti un traffico in entrata su tutti i protocolli e le porte.

  • Si applica alle risorse con tag di rete "fw"
  • Consente il traffico in entrata da origini 10.10.10.0/24

Da Cloudshell:

gcloud compute firewall-rules create $prefix-fw-allow-ingress \
--direction=INGRESS \
--priority=1000 \
--network=$prefix-vpc \
--action=ALLOW \
--rules=all \
--source-ranges=10.10.10.0/24 \
--target-tags=fw

consentire i probe dei controlli di integrità

  • Si applica alle risorse con il tag di rete "fw"
  • Consente il traffico in entrata da intervalli di controlli di integrità

Da Cloudshell:

gcloud compute firewall-rules create $prefix-allow-hc-ingress \
--direction=INGRESS \
--priority=1000 \
--network=$prefix-vpc \
--action=ALLOW \
--rules=tcp:80 \
--source-ranges=130.211.0.0/22,35.191.0.0/16 \
--target-tags=fw

7. Creazione di router Cloud e Cloud NAT

Questa sezione ha lo scopo di permettere alle macchine virtuali private di scaricare i pacchetti software appropriati da internet.

Crea router Cloud

Da Cloudshell:

gcloud compute routers create ${prefix}-cr \
--region=${region} \
--network=${prefix}-vpc

Crea gateway Cloud NAT

Da Cloudshell:

gcloud compute routers nats create ${prefix}-nat-gw-${region} \
--router=${prefix}-cr \
--router-region=${region} \
--auto-allocate-nat-external-ips \
--nat-all-subnet-ip-ranges

8. Creazione di istanze di calcolo

Crea le istanze di calcolo ClientA, ClientB, FW e Server:

Da Cloudshell:

gcloud compute instances create clienta \
   --subnet=$prefix-vpc-subnet \
   --no-address \
   --private-network-ip=10.10.10.10 \
   --zone $zone \
   --tags client \
   --metadata startup-script='#! /bin/bash
apt-get update'

Da Cloudshell:

gcloud compute instances create clientb \
   --subnet=$prefix-vpc-subnet \
   --no-address \
   --private-network-ip=10.10.10.11 \
   --zone $zone \
   --tags client \
   --metadata startup-script='#! /bin/bash
apt-get update'

Da Cloudshell:

gcloud compute instances create server \
   --subnet=$prefix-vpc-subnet \
   --no-address \
   --private-network-ip=10.10.10.200 \
   --zone $zone \
   --tags server \
   --metadata startup-script='#! /bin/bash
sudo su
apt-get update
apt-get -y install tcpdump
apt-get -y install nginx
cat > /var/www/html/index.html << EOF
<html><body><p>Server</p></body></html>
EOF'

Da Cloudshell:

gcloud compute instances create fw \
   --subnet=$prefix-vpc-subnet \
   --can-ip-forward \
   --no-address \
   --private-network-ip=10.10.10.75 \
   --zone $zone \
   --tags fw \
   --metadata startup-script='#! /bin/bash
apt-get update
sudo apt-get -y install tcpdump
sudo apt-get -y install nginx
sudo sysctl -w net.ipv4.ip_forward=1
sudo iptables -I FORWARD -d 10.10.10.200 -j REJECT'

9. Testa la connettività senza PBR

Accedi tramite SSH alle VM di computing client che abbiamo creato di recente e verifica la connettività da entrambi i client al server.

Da cloudshell1, accedi a clienta:

gcloud compute ssh clienta --zone=$zone --tunnel-through-iap

Esegui questi comandi:

ping 10.10.10.200 -c 5
curl 10.10.10.200/index.html

I ping e le richieste curl dovrebbero riuscire.

Output:

root@clienta:~$ ping 10.10.10.200 -c 5
PING 10.10.10.200 (10.10.10.200) 56(84) bytes of data.
64 bytes from 10.10.10.200: icmp_seq=1 ttl=64 time=1.346 ms
64 bytes from 10.10.10.200: icmp_seq=2 ttl=64 time=0.249 ms
64 bytes from 10.10.10.200: icmp_seq=3 ttl=64 time=0.305 ms
64 bytes from 10.10.10.200: icmp_seq=4 ttl=64 time=0.329 ms
64 bytes from 10.10.10.200: icmp_seq=5 ttl=64 time=0.240 ms
root@clienta:~$ curl 10.10.10.200/index.html
<html><body><p>Server</p></body></html>

Apri un'altra scheda di Cloudshell facendo clic sul segno +.

3722d8574c3812b1.png

Da cloudshell2 imposta le variabili da utilizzare:

export project_id=`gcloud config list --format="value(core.project)"`
export region=us-central1
export zone=us-central1-a
export prefix=codelab-pbr

Da SSH di cloudshell2 a clientb:

gcloud compute ssh clientb --zone=$zone --tunnel-through-iap

Esegui questi comandi:

ping 10.10.10.200 -c 5
curl 10.10.10.200/index.html

I ping e le richieste curl dovrebbero riuscire.

Output:

root@clientb:~$ ping 10.10.10.200 -c 5
PING 10.10.10.200 (10.10.10.200) 56(84) bytes of data.
64 bytes from 10.10.10.200: icmp_seq=1 ttl=64 time=1.346 ms
64 bytes from 10.10.10.200: icmp_seq=2 ttl=64 time=0.249 ms
64 bytes from 10.10.10.200: icmp_seq=3 ttl=64 time=0.305 ms
64 bytes from 10.10.10.200: icmp_seq=4 ttl=64 time=0.329 ms
64 bytes from 10.10.10.200: icmp_seq=5 ttl=64 time=0.240 ms
root@clientb:~$ curl 10.10.10.200/index.html
<html><body><p>Server</p></body></html>

Ora esci dal terminale VM e torna a Cloud Shell.

10. Crea un gruppo di istanze

Crea un gruppo di istanze non gestite per la tua VM fw.

Da Cloudshell:

gcloud compute instance-groups unmanaged create pbr-uig --zone=$zone

Aggiungi l'istanza fw al gruppo di istanze non gestite.

Da Cloudshell:

gcloud compute instance-groups unmanaged add-instances pbr-uig --instances=fw --zone=$zone

11. Crea un controllo di integrità

Creare un controllo di integrità per il servizio di backend. Eseguiremo un semplice controllo di integrità della porta TCP 80.

Da Cloudshell:

gcloud compute health-checks create tcp $prefix-hc-tcp-80 --region=$region --port 80

12. Crea un servizio di backend

Crea un servizio di backend da collegare alla regola di forwarding.

Da Cloudshell:

gcloud compute backend-services create be-pbr --load-balancing-scheme=internal --protocol=tcp --region=$region --health-checks=$prefix-hc-tcp-80 --health-checks-region=$region

Ora aggiungi il gruppo di istanze al servizio di backend.

Da Cloudshell:

gcloud compute backend-services add-backend be-pbr --region=$region --instance-group=pbr-uig --instance-group-zone=$zone

13. Creare una regola di forwarding

Da Cloudshell:

gcloud compute forwarding-rules create fr-pbr --region=$region --load-balancing-scheme=internal --network=$prefix-vpc --subnet=$prefix-vpc-subnet --ip-protocol=TCP --ports=ALL --backend-service=be-pbr --backend-service-region=$region --address=10.10.10.25 --network-tier=PREMIUM

14. Crea regola PBR

Questa regola PBR si applica ai clienti. Tutto il traffico IPv4 verrà instradato alla regola di forwarding 10.10.10.25 se l'IP di origine è 10.10.10.10/32 (indirizzo di clienta) e l'IP di destinazione è 10.10.10.0/24.

Ciò significa che clienta corrisponderà a PBR e non a clientb.

Da Cloudshell:

gcloud network-connectivity policy-based-routes create pbr-client \
   --network=projects/$project_id/global/networks/$prefix-vpc \
   --next-hop-ilb-ip=10.10.10.25 \
   --source-range=10.10.10.10/32 \
   --destination-range=10.10.10.0/24 \
   --protocol-version=IPv4 \
   --priority=1000 \
   --tags=client

Questa regola PBR si applica al server. Tutto il traffico IPv4 verrà instradato alla regola di forwarding 10.10.10.25 se l'IP di origine è 10.10.10.200/32 e l'IP di destinazione è 10.10.10.10/32.

Da Cloudshell:

gcloud network-connectivity policy-based-routes create pbr-server \
   --network=projects/$project_id/global/networks/$prefix-vpc \
   --next-hop-ilb-ip=10.10.10.25 \
   --source-range=10.10.10.200/32 \
   --destination-range=10.10.10.10/32 \
   --protocol-version=IPv4 \
   --priority=2000 \
   --tags=server

15. Testa la connettività con PBR

Ora verificheremo la funzionalità PBR. La "fw" l'istanza è configurata con iptables per rifiutare le richieste destinate al server. Se PBR è funzionale, le richieste che funzionavano in precedenza su Clienta ora non andranno a buon fine, mentre Clientb continua a funzionare.

Accedi tramite SSH alla VM di computing client ed esegui gli stessi test.

Da cloudshell1:

gcloud compute ssh clienta --zone=$zone --tunnel-through-iap

Esegui questi comandi:

ping 10.10.10.200 -c 5
curl 10.10.10.200/index.html

Output:

root@clienta:~$ ping 10.10.10.200 -c 5
PING 10.10.10.200 (10.10.10.200) 56(84) bytes of data.
From 10.10.10.75 icmp_seq=1 Destination Port Unreachable
From 10.10.10.75 icmp_seq=2 Destination Port Unreachable
From 10.10.10.75 icmp_seq=3 Destination Port Unreachable
From 10.10.10.75 icmp_seq=4 Destination Port Unreachable
From 10.10.10.75 icmp_seq=5 Destination Port Unreachable
root@clienta:~$ curl 10.10.10.200/index.html
curl: (7) Failed to connect to 10.10.10.200 port 80: Connection refused

Poiché le richieste non sono andate a buon fine, possiamo confermare che PBR sta instradando attivamente il traffico per clienta all'istanza fw configurata per bloccare questo traffico.

Accedi tramite SSH a clientb ed esegui lo stesso test di connettività.

Da cloudshell2:

gcloud compute ssh clientb --zone=$zone --tunnel-through-iap

Esegui questi comandi:

ping 10.10.10.200 -c 5
curl 10.10.10.200/index.html

Output:

root@clientb:~$ ping 10.10.10.200 -c 5
PING 10.10.10.200 (10.10.10.200) 56(84) bytes of data.
64 bytes from 10.10.10.200: icmp_seq=1 ttl=63 time=0.361 ms
64 bytes from 10.10.10.200: icmp_seq=2 ttl=63 time=0.475 ms
64 bytes from 10.10.10.200: icmp_seq=3 ttl=63 time=0.379 ms
root@clientb:~$ curl 10.10.10.200
<html><body><p>Server</p></body></html>

Come puoi vedere, le richieste da clientb a server hanno esito positivo. Questo perché le richieste non corrispondono a una regola PBR per l'IP di origine.

16. [Facoltativo] Convalida con acquisizioni sul firewall

In questa sezione facoltativa, hai la possibilità di convalidare il PBR tramite acquisizioni di pacchetti sulla VM firewall.

Dovresti comunque avere una connessione SSH in cloudshell1 e cloudshell2 a clienta e clientb.

Apri un'altra scheda di Cloudshell facendo clic sul segno +.

5eb3a9956f7e41a2.png

Da cloudshell3, imposta le variabili:

export project_id=`gcloud config list --format="value(core.project)"`
export region=us-central1
export zone=us-central1-a
export prefix=codelab-pbr

Accedi tramite SSH a fw:

gcloud compute ssh fw --zone=$zone --tunnel-through-iap

Esegui questo comando su fw (cloudshell3):

sudo tcpdump -i any icmp -nn

Da clienta (cloudshell1) esegui il test ping:

ping 10.10.10.200 -c 5

Da clientb (cloudshell2) esegui il test ping:

ping 10.10.10.200 -c 5

Output su fw (cloudshell 3):

root@fw:~$ sudo tcpdump -i any icmp -nn
tcpdump: data link type LINUX_SLL2
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on any, link-type LINUX_SLL2 (Linux cooked v2), snapshot length 262144 bytes
17:07:42.215297 ens4  In  IP 10.10.10.10 > 10.10.10.200: ICMP echo request, id 25362, seq 1, length 64
17:07:42.215338 ens4  Out IP 10.10.10.75 > 10.10.10.10: ICMP 10.10.10.200 protocol 1 port 51064 unreachable, length 92
17:07:43.216122 ens4  In  IP 10.10.10.10 > 10.10.10.200: ICMP echo request, id 25362, seq 2, length 64
17:07:43.216158 ens4  Out IP 10.10.10.75 > 10.10.10.10: ICMP 10.10.10.200 protocol 1 port 30835 unreachable, length 92
17:07:44.219064 ens4  In  IP 10.10.10.10 > 10.10.10.200: ICMP echo request, id 25362, seq 3, length 64
17:07:44.219101 ens4  Out IP 10.10.10.75 > 10.10.10.10: ICMP 10.10.10.200 protocol 1 port 2407 unreachable, length 92

Non vedrai alcun pacchetto sul tcpdump da clientb (10.10.10.11) poiché PBR non è applicabile.

Torna a Cloud Shell per eseguire la pulizia delle risorse.

17. Passaggi per la pulizia

Da Cloud Shell, rimuovi la regola PBR, la regola di forwarding, il servizio di backend, il controllo di integrità, il gruppo di istanze, le istanze di calcolo, NAT, router Cloud e regole firewall.

gcloud -q network-connectivity policy-based-routes delete pbr-client

gcloud -q network-connectivity policy-based-routes delete pbr-server

gcloud -q compute forwarding-rules delete fr-pbr --region=$region

gcloud -q compute backend-services delete be-pbr --region=$region

gcloud -q compute health-checks delete $prefix-hc-tcp-80 --region=$region

gcloud -q compute instance-groups unmanaged delete pbr-uig --zone=$zone

gcloud -q compute instances delete clienta --zone=$zone
gcloud -q compute instances delete clientb --zone=$zone
gcloud -q compute instances delete server --zone=$zone
gcloud -q compute instances delete fw --zone=$zone


gcloud -q compute routers nats delete ${prefix}-nat-gw-${region} \
--router=$prefix-cr --router-region=$region

gcloud -q compute routers delete $prefix-cr --region=$region

gcloud -q compute firewall-rules delete $prefix-allow-iap-proxy
gcloud -q compute firewall-rules delete $prefix-allow-http-icmp
gcloud -q compute firewall-rules delete $prefix-fw-allow-ingress
gcloud -q compute firewall-rules delete $prefix-allow-hc-ingress

Rimuovi la subnet e i VPC:

gcloud -q compute networks subnets delete $prefix-vpc-subnet \
    --region $region

gcloud -q compute networks delete $prefix-vpc

18. Complimenti

Complimenti per aver completato il codelab.

Argomenti trattati

  • Route basate su criteri