1. Introduction
Routes basées sur des règles
Les routes basées sur des règles vous permettent de choisir un saut suivant en fonction d'autres paramètres que l'adresse IP de destination d'un paquet. Vous pouvez également faire correspondre le trafic par protocole et par adresse IP source. Le trafic correspondant est redirigé vers un équilibreur de charge réseau interne. Cela peut vous aider à insérer des dispositifs tels que des pare-feu dans le chemin du trafic réseau.
Lorsque vous créez une route basée sur des règles, vous sélectionnez les ressources dont le trafic peut être traité par la route. La route peut s'appliquer aux éléments suivants:
- L'ensemble du réseau: toutes les instances de machines virtuelles (VM), passerelles VPN et interconnexions
- En utilisant des tags réseau: sélectionner des instances de VM dans le VPC
- Région d'interconnexion: tout le trafic entrant dans le réseau VPC via des rattachements de VLAN pour la région
Le saut suivant d'une route basée sur des règles doit être un équilibreur de charge réseau interne valide qui se trouve sur le même réseau VPC que la route basée sur des règles.
Les équilibreurs de charge réseau internes utilisent le hachage symétrique par défaut, de sorte que le trafic peut atteindre le même dispositif sur les chemins sortant et retour sans configurer la NAT source.
Les routes basées sur des règles ont une priorité plus élevée que les autres types de routes, à l'exception des chemins de retour spéciaux.
Si deux routes basées sur des règles ont la même priorité, Google Cloud utilise un algorithme interne déterministe pour sélectionner une seule route basée sur des règles, en ignorant les autres routes ayant la même priorité. Les routes basées sur des règles n'utilisent pas la correspondance du préfixe le plus long et ne sélectionnent que la route ayant la priorité la plus élevée.
Vous pouvez créer une seule règle pour le trafic à sens unique ou plusieurs règles pour gérer le trafic bidirectionnel.
Pour utiliser des routes basées sur des règles avec Cloud Interconnect, elles doivent être appliquées à toutes les connexions Cloud Interconnect d'une région entière. Les routes basées sur des règles ne peuvent pas être appliquées uniquement à une connexion Cloud Interconnect individuelle.
Le transfert IP doit être activé pour les instances de VM qui reçoivent du trafic provenant d'une route basée sur des règles.
Remarques concernant le PBR
Une configuration spéciale est nécessaire pour utiliser les routes basées sur des règles comme suit.
Par exemple, vous pouvez utiliser PBR avec GKE, PSC ou PGA/PSA.
Pour en savoir plus sur le PBR avec GKE, cliquez ici. Pour consulter la section sur les limites générales du PBR avec GKE, cliquez ici.
Points abordés
- Configurer des routes basées sur des règles
Prérequis
- Vous disposez des connaissances nécessaires sur le déploiement d'instances et la configuration des composants réseau.
- Connaissances de la configuration des pare-feu VPC
2. Environnement de test
Cet atelier de programmation utilisera un seul VPC. Il y aura deux ressources de calcul, clienta et clientb, dans cet environnement qui enverront des paquets à une autre ressource de serveur. À l'aide de PBR et de filtres, nous allons forcer le trafic de clienta sur une autre ressource de calcul pour l'application du pare-feu, tandis que le trafic clientb va directement au serveur. Le schéma ci-dessous illustre le chemin d'accès.
Dans le schéma ci-dessus, il doit techniquement y avoir un ILB (équilibreur de charge réseau interne) pour les chemins PBR. Cet élément a été omis pour simplifier le schéma.
3. Avant de commencer
L'atelier de programmation nécessite un seul projet.
Depuis Cloud Shell:
export project_id=`gcloud config list --format="value(core.project)"` export region=us-central1 export zone=us-central1-a export prefix=codelab-pbr
4. Activer les API
Si ce n'est pas déjà fait, activez les API pour utiliser les produits
Depuis Cloud Shell:
gcloud services enable compute.googleapis.com gcloud services enable networkconnectivity.googleapis.com
5. Créer un réseau et un sous-réseau VPC
Réseau VPC
Créez le VPC workspace-pbr-vpc:
Depuis Cloud Shell:
gcloud compute networks create $prefix-vpc --subnet-mode=custom
Sous-réseau
Créez les sous-réseaux respectifs dans la région sélectionnée:
Depuis Cloud Shell:
gcloud compute networks subnets create $prefix-vpc-subnet \
--range=10.10.10.0/24 --network=$prefix-vpc --region=${region}
6. Créer des règles de pare-feu
Pour autoriser IAP à se connecter à vos instances de VM, créez une règle de pare-feu qui:
- S'applique à toutes les instances de VM auxquelles vous souhaitez rendre accessibles à l'aide d'IAP.
- Autorise le trafic entrant provenant de la plage d'adresses IP 35.235.240.0/20. Cette plage contient toutes les adresses IP utilisées par IAP pour le transfert TCP.
Depuis Cloud Shell:
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
Pour autoriser le port HTTP standard (TCP 80) et le protocole ICMP sur le serveur:
- S'applique aux ressources associées au tag réseau "server"
- Autorise le trafic d'entrée depuis toutes les sources
Depuis Cloud Shell:
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
Pour autoriser le micrologiciel à recevoir des paquets, autorisez une entrée sur tous les protocoles et ports.
- S'applique aux ressources associées au tag réseau "fw"
- Autorise le trafic d'entrée provenant de sources 10.10.10.0/24
Depuis Cloud Shell:
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
Pour autoriser les vérifications d'état
- S'applique aux ressources portant le tag réseau "fw"
- Autorise le trafic d'entrée provenant des plages de vérification de l'état
Depuis Cloud Shell:
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. Créer un routeur Cloud Router et Cloud NAT
L'objectif de cette section est de permettre aux machines virtuelles privées de télécharger les packages logiciels appropriés depuis Internet.
Créer un routeur Cloud Router
Depuis Cloud Shell:
gcloud compute routers create ${prefix}-cr \
--region=${region} \
--network=${prefix}-vpc
Créer une passerelle Cloud NAT
Depuis Cloud Shell:
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. Créer des instances Compute
Créez les instances de calcul ClientA, ClientB, FW et Server:
Depuis Cloud Shell:
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'
Depuis Cloud Shell:
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'
Depuis Cloud Shell:
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'
Depuis Cloud Shell:
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. Tester la connectivité sans PBR
Connectez-vous en SSH aux VM de calcul clientes que nous avons récemment créées et vérifiez la connectivité des deux clients au serveur.
Depuis la connexion cloudshell1 vers clienta:
gcloud compute ssh clienta --zone=$zone --tunnel-through-iap
Exécutez les commandes suivantes :
ping 10.10.10.200 -c 5
curl 10.10.10.200/index.html
Les requêtes ping et curl devraient aboutir.
Sortie :
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>
Ouvrez un autre onglet Cloud Shell en cliquant sur le signe +.
Depuis cloudshell2, définissez les variables à utiliser:
export project_id=`gcloud config list --format="value(core.project)"` export region=us-central1 export zone=us-central1-a export prefix=codelab-pbr
De cloudshell2 SSH vers clientb:
gcloud compute ssh clientb --zone=$zone --tunnel-through-iap
Exécutez les commandes suivantes :
ping 10.10.10.200 -c 5
curl 10.10.10.200/index.html
Les requêtes ping et curl devraient aboutir.
Sortie :
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>
Quittez maintenant le terminal de la VM et revenez à Cloud Shell.
10. Créer un groupe d'instances
Créez un groupe d'instances non géré pour votre nouvelle VM.
Depuis Cloud Shell:
gcloud compute instance-groups unmanaged create pbr-uig --zone=$zone
Ajoutez l'instance de micrologiciel au groupe d'instances non géré.
Depuis Cloud Shell:
gcloud compute instance-groups unmanaged add-instances pbr-uig --instances=fw --zone=$zone
11. Créer une vérification d'état
Créez une vérification d'état pour le service de backend. Nous allons effectuer une simple vérification de l'état du port TCP 80.
Depuis Cloud Shell:
gcloud compute health-checks create tcp $prefix-hc-tcp-80 --region=$region --port 80
12. Créer un service de backend
Créez un service de backend à associer à la règle de transfert.
Depuis Cloud Shell:
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
Ajoutez maintenant le groupe d'instances au service de backend.
Depuis Cloud Shell:
gcloud compute backend-services add-backend be-pbr --region=$region --instance-group=pbr-uig --instance-group-zone=$zone
13. Créer une règle de transfert
Depuis Cloud Shell:
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. Créer une règle PBR
Cette règle PBR s'applique aux clients. Il achemine tout le trafic IPv4 vers la règle de transfert 10.10.10.25 si l'adresse IP source est 10.10.10.10/32 (adresse de clienta) et que l'adresse IP de destination est 10.10.10.0/24.
Cela signifie que clienta correspondra à PBR et non à clientb.
Depuis Cloud Shell:
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
Cette règle PBR s'applique au serveur. Il achemine tout le trafic IPv4 vers la règle de transfert 10.10.10.25 si l'adresse IP source est 10.10.10.200/32 et l'adresse IP de destination est 10.10.10.10/32.
Depuis Cloud Shell:
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. Tester la connectivité avec PBR
Nous allons maintenant vérifier la fonctionnalité PBR. Le "fw" est configurée avec des règles iptables pour rejeter les requêtes destinées au serveur. Si le PBR fonctionne, les requêtes qui fonctionnaient précédemment sur clienta échoueront désormais, tandis que clientb réussit toujours.
Connectez-vous en SSH à la VM Compute cliente et exécutez les mêmes tests.
Depuis cloudshell1:
gcloud compute ssh clienta --zone=$zone --tunnel-through-iap
Exécutez les commandes suivantes :
ping 10.10.10.200 -c 5
curl 10.10.10.200/index.html
Sortie :
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
Comme les requêtes ont échoué, nous pouvons confirmer que PBR achemine activement le trafic de clienta vers l'instance du micrologiciel qui a été configurée pour bloquer ce trafic.
Connectez-vous en SSH à clientb et exécutez le même test de connectivité.
Depuis cloudshell2:
gcloud compute ssh clientb --zone=$zone --tunnel-through-iap
Exécutez les commandes suivantes :
ping 10.10.10.200 -c 5
curl 10.10.10.200/index.html
Sortie :
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>
Comme vous pouvez le voir, les requêtes de clientb vers serveur aboutissent. En effet, les requêtes ne correspondent à aucune règle PBR de l'adresse IP source.
16. [Facultatif] Valider avec des captures sur le pare-feu
Dans cette section facultative, vous avez la possibilité de valider le PBR en effectuant des captures de paquets sur la VM de pare-feu.
Vous devez toujours disposer d'une connexion SSH dans cloudshell1 et cloudshell2 vers clienta et clientb.
Ouvrez un autre onglet Cloud Shell en cliquant sur le signe +.
Depuis cloudshell3, définissez les variables:
export project_id=`gcloud config list --format="value(core.project)"` export region=us-central1 export zone=us-central1-a export prefix=codelab-pbr
Connectez-vous en SSH à fw:
gcloud compute ssh fw --zone=$zone --tunnel-through-iap
Exécutez la commande suivante sur fw (cloudshell3):
sudo tcpdump -i any icmp -nn
Depuis clienta (cloudshell1), exécutez le test ping:
ping 10.10.10.200 -c 5
Depuis clientb (cloudshell2), exécutez le test ping:
ping 10.10.10.200 -c 5
Résultat lors du transfert (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
Vous ne verrez aucun paquet de clientb (10.10.10.11) sur tcpdump, car PBR n'est pas applicable.
Quittez Cloud Shell pour nettoyer les ressources.
17. Étapes de nettoyage
Dans Cloud Shell, supprimez la règle PBR, la règle de transfert, le service de backend, la vérification de l'état, le groupe d'instances, les instances de calcul, la NAT, le routeur Cloud et les règles de pare-feu.
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
Supprimez le sous-réseau et les VPC:
gcloud -q compute networks subnets delete $prefix-vpc-subnet \
--region $region
gcloud -q compute networks delete $prefix-vpc
18. Félicitations !
Bravo ! Vous avez terminé cet atelier de programmation.
Points abordés
- Routes basées sur des règles