1. Einführung
Richtlinienbasierte Routen
Mit richtlinienbasierten Routen können Sie einen nächsten Hop basierend auf mehr als der Ziel-IP-Adresse eines Pakets auswählen. Traffic lässt sich auch nach Protokoll und Quell-IP-Adresse abgleichen. Übereinstimmender Traffic wird an einen internen Netzwerk-Load-Balancer weitergeleitet. So können Sie Appliances wie Firewalls in den Pfad des Netzwerktraffics einfügen.
Wenn Sie eine richtlinienbasierte Route erstellen, wählen Sie aus, für welche Ressourcen der Traffic von der Route verarbeitet werden darf. Die Route kann für Folgendes gelten:
- Das gesamte Netzwerk: alle VM-Instanzen, VPN-Gateways und Interconnect-Verbindungen
- Mit Netzwerk-Tags: VM-Instanzen in der VPC auswählen
- Interconnect-Region: Der gesamte Traffic, der über VLAN-Anhänge für die Region in das VPC-Netzwerk eingeht
Der nächste Hop einer richtlinienbasierten Route muss ein gültiger interner Netzwerk-Load-Balancer sein, der sich im selben VPC-Netzwerk wie die richtlinienbasierte Route befindet.
Interne Netzwerk-Load-Balancer verwenden standardmäßig symmetrisches Hashing, sodass der Traffic dieselbe Appliance über die ausgehenden und Rückgabepfade erreichen kann, ohne die Quell-NAT zu konfigurieren.
Richtlinienbasierte Routen haben eine höhere Priorität als andere Routentypen, mit Ausnahme von speziellen Rückgabepfaden.
Wenn zwei richtlinienbasierte Routen dieselbe Priorität haben, verwendet Google Cloud einen deterministischen internen Algorithmus, um eine einzelne richtlinienbasierte Route auszuwählen. Andere Routen mit derselben Priorität werden ignoriert. Richtlinienbasierte Routen verwenden keinen Abgleich mit dem längsten Präfix und wählen nur die Route mit der höchsten Priorität aus.
Sie können eine einzelne Regel für Einbahnverkehr oder mehrere Regeln für den bidirektionalen Traffic erstellen.
Wenn Sie richtlinienbasierte Routen mit Cloud Interconnect verwenden möchten, muss die Route auf alle Cloud Interconnect-Verbindungen in einer gesamten Region angewendet werden. Richtlinienbasierte Routen können nicht nur auf eine einzelne Cloud Interconnect-Verbindung angewendet werden.
Für die VM-Instanzen, die Traffic von einer richtlinienbasierten Route empfangen, muss IP-Weiterleitung aktiviert sein.
Überlegungen bei der PBR
Eine spezielle Konfiguration ist erforderlich, um richtlinienbasierte Routen auf folgende Arten verwenden zu können.
Zum Beispiel die Verwendung von PBR mit GKE, PSC oder mit PGA/PSA.
Weitere Informationen zur PBR mit GKE finden Sie hier und im Abschnitt zu den allgemeinen PBR-Einschränkungen.
Lerninhalte
- Richtlinienbasierte Routen konfigurieren
Voraussetzungen
- Kenntnisse der Bereitstellung von Instanzen und der Konfiguration von Netzwerkkomponenten
- Kenntnisse zur Konfiguration von VPC-Firewalls
2. Testumgebung
In diesem Codelab wird eine einzelne VPC verwendet. In dieser Umgebung gibt es zwei Rechenressourcen, clienta und clientb, die Pakete an eine andere Serverressource senden. Mit PBR und Filtern erzwingen wir Traffic von clienta durch eine andere Rechenressource, um die Firewall zu erzwingen, während Clientb-Traffic direkt zum Server geht. Das folgende Diagramm veranschaulicht den Pfad.
Im obigen Diagramm sollte technisch gesehen ein ILB (Network Internal Load Balancer) für PBR-Pfade vorhanden sein. Dies wurde aus Gründen der Übersichtlichkeit des Diagramms weggelassen.
3. Hinweis
Für Codelab ist ein einzelnes Projekt erforderlich.
In 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. APIs aktivieren
Aktivieren Sie die APIs, um die Produkte zu verwenden, falls noch nicht geschehen
In Cloud Shell:
gcloud services enable compute.googleapis.com gcloud services enable networkconnectivity.googleapis.com
5. VPC-Netzwerk und Subnetz erstellen
VPC-Netzwerk
Erstellen Sie die VPC „codelab-pbr-vpc“:
In Cloud Shell:
gcloud compute networks create $prefix-vpc --subnet-mode=custom
Subnetz
Erstellen Sie die entsprechenden Subnetze in der ausgewählten Region:
In Cloud Shell:
gcloud compute networks subnets create $prefix-vpc-subnet \
--range=10.10.10.0/24 --network=$prefix-vpc --region=${region}
6. Firewallregeln erstellen
Damit IAP eine Verbindung zu Ihren VM-Instanzen herstellen kann, müssen Sie eine Firewallregel erstellen, die:
- Gilt für alle VM-Instanzen, die mit IAP zugänglich sein sollen.
- Lässt eingehenden Traffic aus dem IP-Bereich 35.235.240.0/20 zu. Dieser Bereich enthält alle IP-Adressen, die IAP für die TCP-Weiterleitung verwendet.
In 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
So lassen Sie den Standard-HTTP-Port (TCP 80) und das ICMP-Protokoll für den Server zu:
- Gilt für Ressourcen mit dem Netzwerktag „server“
- Lässt eingehenden Traffic von allen Quellen zu
In 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
Damit die FW Pakete empfangen kann, musst du für alle Protokolle und Ports eingehenden Traffic zulassen.
- Gilt für Ressourcen mit dem Netzwerk-Tag „fw“
- Lässt eingehenden Traffic von Quellen aus 10.10.10.0/24 zu
In 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
Um die Systemdiagnoseprüfungen zuzulassen
- Gilt für Ressourcen mit dem Netzwerk-Tag „fw“
- Lässt eingehenden Traffic aus Systemdiagnosebereichen zu
In 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. Cloud Router erstellen und Cloud NAT
Der Zweck dieses Abschnitts besteht darin, dass die privaten virtuellen Maschinen die entsprechenden Softwarepakete aus dem Internet herunterladen können.
Cloud Router erstellen
In Cloud Shell:
gcloud compute routers create ${prefix}-cr \
--region=${region} \
--network=${prefix}-vpc
Cloud NAT-Gateway erstellen
In 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. Compute-Instanzen erstellen
Erstellen Sie die Compute-Instanzen ClientA, ClientB, FW und Server:
In 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'
In 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'
In 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'
In 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. Konnektivität ohne PBR testen
Stellen Sie eine SSH-Verbindung zu Client-Compute-VMs her, die wir vor Kurzem erstellt haben, und prüfen Sie die Verbindung zwischen beiden Clients und dem Server.
Melden Sie sich über cloudshell1 bei clienta an:
gcloud compute ssh clienta --zone=$zone --tunnel-through-iap
Führen Sie folgende Befehle aus:
ping 10.10.10.200 -c 5
curl 10.10.10.200/index.html
Die Pings und curl-Anfragen sollten erfolgreich sein.
Ausgabe:
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>
Öffnen Sie einen weiteren Cloud Shell-Tab, indem Sie auf das Pluszeichen klicken.
Legen Sie in cloudshell2 Variablen zur Verwendung fest:
export project_id=`gcloud config list --format="value(core.project)"` export region=us-central1 export zone=us-central1-a export prefix=codelab-pbr
Von cloudshell2-SSH zu clientb:
gcloud compute ssh clientb --zone=$zone --tunnel-through-iap
Führen Sie folgende Befehle aus:
ping 10.10.10.200 -c 5
curl 10.10.10.200/index.html
Die Pings und curl-Anfragen sollten erfolgreich sein.
Ausgabe:
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>
Beenden Sie jetzt das VM-Terminal und kehren Sie zu Cloud Shell zurück.
10. Instanzgruppe erstellen
Erstellen Sie eine nicht verwaltete Instanzgruppe für Ihre Firmware-VM.
In Cloud Shell:
gcloud compute instance-groups unmanaged create pbr-uig --zone=$zone
Fügen Sie die Firmware-Instanz der nicht verwalteten Instanzgruppe hinzu.
In Cloud Shell:
gcloud compute instance-groups unmanaged add-instances pbr-uig --instances=fw --zone=$zone
11. Systemdiagnose erstellen
Erstellen Sie eine Systemdiagnose für den Back-End-Dienst. Wir führen eine einfache Systemdiagnose für TCP-Port 80 durch.
In Cloud Shell:
gcloud compute health-checks create tcp $prefix-hc-tcp-80 --region=$region --port 80
12. Backend-Dienst erstellen
Erstellen Sie einen Back-End-Dienst, der an die Weiterleitungsregel angehängt werden soll.
In 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
Fügen Sie nun die Instanzgruppe dem Back-End-Dienst hinzu.
In Cloud Shell:
gcloud compute backend-services add-backend be-pbr --region=$region --instance-group=pbr-uig --instance-group-zone=$zone
13. Weiterleitungsregel erstellen
In 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. PBR-Regel erstellen
Diese PBR-Regel gilt für Kunden. Sie leitet den gesamten IPv4-Traffic an die Weiterleitungsregel 10.10.10.25 weiter, wenn die Quell-IP 10.10.10.10/32 (die Adresse des Clients) und die Ziel-IP-Adresse 10.10.10.0/24 ist.
Das bedeutet, dass clienta mit PBR übereinstimmt und nicht Clientb.
In 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
Diese PBR-Regel gilt für den Server. Sie leitet den gesamten IPv4-Traffic an die Weiterleitungsregel 10.10.10.25 weiter, wenn die Quell-IP-Adresse 10.10.10.200/32 und die Ziel-IP-Adresse 10.10.10.10/32 ist.
In 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. Konnektivität mit PBR testen
Wir überprüfen nun die PBR-Funktionalität. Das „fw“ Instanz ist mit iptables konfiguriert, um an den Server gerichtete Anfragen abzulehnen. Wenn die PBR funktionsfähig ist, schlagen die Anfragen, die zuvor für „clienta“ funktioniert haben, fehl, während „clientb“ weiterhin erfolgreich ist.
Stellen Sie eine SSH-Verbindung zu einer clientseitigen Compute-VM her und führen Sie die gleichen Tests aus.
In cloudshell1:
gcloud compute ssh clienta --zone=$zone --tunnel-through-iap
Führen Sie folgende Befehle aus:
ping 10.10.10.200 -c 5
curl 10.10.10.200/index.html
Ausgabe:
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
Da die Anfragen fehlgeschlagen sind, können wir bestätigen, dass PBR den Traffic für clienta aktiv an die FW-Instanz weiterleitet, die zum Blockieren dieses Traffics konfiguriert ist.
Stellen Sie eine SSH-Verbindung zu clientb her und führen Sie den gleichen Konnektivitätstest aus.
In cloudshell2:
gcloud compute ssh clientb --zone=$zone --tunnel-through-iap
Führen Sie folgende Befehle aus:
ping 10.10.10.200 -c 5
curl 10.10.10.200/index.html
Ausgabe:
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>
Wie Sie sehen, sind Anfragen vom Clientb an den Server erfolgreich. Das liegt daran, dass die Anfragen nicht mit einer PBR-Regel für die Quell-IP übereinstimmen.
16. [Optional] Validierung mit Erfassungen in der Firewall
In diesem optionalen Abschnitt haben Sie die Möglichkeit, PBR zu validieren, indem Sie Paketerfassungen auf der Firewall-VM vornehmen.
Sie sollten immer noch eine SSH-Verbindung in cloudshell1 und cloudshell2 zu clienta und clientb haben.
Öffnen Sie einen weiteren Cloud Shell-Tab, indem Sie auf das Pluszeichen klicken.
Legen Sie in Cloud Shell3 Variablen fest:
export project_id=`gcloud config list --format="value(core.project)"` export region=us-central1 export zone=us-central1-a export prefix=codelab-pbr
SSH-Verbindung zu fw:
gcloud compute ssh fw --zone=$zone --tunnel-through-iap
Führen Sie den folgenden Befehl für fw (cloudshell3) aus:
sudo tcpdump -i any icmp -nn
Führen Sie in clienta (cloudshell1) den Ping-Test aus:
ping 10.10.10.200 -c 5
Führen Sie über clientb (cloudshell2) den Ping-Test aus:
ping 10.10.10.200 -c 5
Ausgabe mit 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
Im tcpdump werden keine Pakete von clientb (10.10.10.11) angezeigt, da PBR nicht anwendbar ist.
Kehren Sie zu Cloud Shell zurück, um Ressourcen zu bereinigen.
17. Bereinigungsschritte
Entfernen Sie in Cloud Shell die PBR-Regel, die Weiterleitungsregel, den Back-End-Dienst, die Systemdiagnose, die Instanzgruppe, Compute-Instanzen, NAT, Cloud Router und Firewallregeln.
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
Entfernen Sie das Subnetz und die VPCs:
gcloud -q compute networks subnets delete $prefix-vpc-subnet \
--region $region
gcloud -q compute networks delete $prefix-vpc
18. Glückwunsch!
Herzlichen Glückwunsch zum Abschluss des Codelabs.
Behandelte Themen
- Richtlinienbasierte Routen