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 de l'adresse IP de destination d'un paquet. Vous pouvez également mettre en correspondance le trafic par protocole et 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), les passerelles VPN et les interconnexions
- Sélectionner des instances de VM dans le VPC à l'aide de tags réseau
- 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 dans le même réseau VPC que la route basée sur des règles.
Par défaut, les équilibreurs de charge réseau internes utilisent le hachage symétrique afin que le trafic puisse atteindre le même dispositif sur les chemins sortants et renvoyés 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, 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 règle unique 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 être appliquées qu'à une seule connexion Cloud Interconnect.
Le transfert IP doit être activé sur les instances de VM qui reçoivent le trafic provenant d'une route basée sur des règles.
Remarques concernant la PBR
Une configuration spéciale est nécessaire pour utiliser les routages basés sur des règles des manières suivantes.
Par exemple, en utilisant PBR avec GKE, PSC ou avec PGA/PSA.
Pour en savoir plus sur la PBR avec GKE, cliquez ici. Pour en savoir plus sur les limites générales de la PBR, cliquez ici.
Points abordés
- Configurer des routes basées sur des règles
Prérequis
- Connaissances sur le déploiement d'instances et la configuration de composants réseau
- Connaissances sur la configuration des pare-feu VPC
2. Environnement de test
Cet atelier de programmation utilisera un seul VPC. Cet environnement comprendra deux ressources de calcul, clienta et clientb, qui enverront des paquets à une autre ressource de serveur. À l'aide de PBR et de filtres, nous forcerons le trafic de clienta à passer par une autre ressource de calcul pour l'application du pare-feu, tandis que le trafic de clientb ira directement au serveur. Le schéma ci-dessous illustre le chemin d'accès.
Dans le schéma ci-dessus, il devrait techniquement y avoir un équilibreur de charge interne (ILB, internal load balancer) pour les chemins PBR. Cette étape a été omise 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 codelab-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 permettre à IAP de 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 être accessible à l'aide d'IAP.
- Autorise le trafic entrant à partir de la plage d'adresses IP 35.235.240.0/20. Cette plage contient toutes les adresses IP qu'IAP utilise 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 avec le tag réseau "server"
- Autorise l'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 pare-feu à recevoir des paquets, autorisez une entrée sur tous les protocoles et ports.
- S'applique aux ressources avec le tag réseau "fw"
- Autorise le trafic entrant provenant des 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 de l'état
- S'applique aux ressources avec le tag réseau "fw"
- Autorise l'entrée à partir 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 de calcul
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 créées récemment et vérifiez la connectivité des deux clients au serveur.
Depuis cloudshell1, connectez-vous à 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 pings et les requêtes curl devraient fonctionner.
Résultat :
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 onglet Cloud Shell supplémentaire en cliquant sur le signe +.
Dans 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
Depuis cloudshell2, connectez-vous en SSH à 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 pings et les requêtes curl devraient fonctionner.
Résultat :
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 VM de pare-feu.
Depuis Cloud Shell :
gcloud compute instance-groups unmanaged create pbr-uig --zone=$zone
Ajoutez l'instance fw 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 acheminera 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 l'adresse IP de destination est 10.10.10.0/24.
Cela signifie que clienta correspondra à PBR, mais pas à 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 acheminera 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. L'instance "fw" est configurée avec iptables pour refuser les requêtes destinées au serveur. Si le PBR fonctionne, les requêtes qui fonctionnaient auparavant sur clienta échoueront désormais, tandis que clientb réussira toujours.
Connectez-vous en SSH à une VM de calcul 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
Résultat :
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
Étant donné que les requêtes ont échoué, nous pouvons confirmer que le PBR achemine activement le trafic pour clienta vers l'instance de pare-feu 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
Résultat :
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 au serveur ont abouti. En effet, les requêtes ne correspondent pas à une règle PBR pour l'adresse IP source.
16. [Facultatif] Valider avec des captures sur le pare-feu
Dans cette section facultative, vous pouvez valider le PBR en effectuant des captures de paquets sur la VM du pare-feu.
Vous devriez toujours disposer d'une connexion SSH dans cloudshell1 et cloudshell2 à clienta et clientb.
Ouvrez un onglet Cloud Shell supplémentaire en cliquant sur le signe +.
Dans 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 à fw en SSH :
gcloud compute ssh fw --zone=$zone --tunnel-through-iap
Exécutez la commande suivante sur fw (cloudshell3) :
sudo tcpdump -i any icmp -nn
À partir de clienta (cloudshell1), exécutez le test ping :
ping 10.10.10.200 -c 5
À partir de clientb (cloudshell2), exécutez le test ping :
ping 10.10.10.200 -c 5
Sortie sur 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
Vous ne verrez aucun paquet sur le tcpdump du client B (10.10.10.11), car la 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, le NAT, le routeur Cloud Router 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