1. Einführung
Richtlinienbasierte Routen
Mit richtlinienbasierten Routen können Sie einen nächsten Hop anhand von mehr als der Ziel-IP-Adresse eines Pakets auswählen. Sie können den Traffic auch mit dem Protokoll und der Quell-IP-Adresse abgleichen. Übereinstimmender Traffic wird an einen internen Network Load Balancer weitergeleitet. Auf diese Weise können Sie Appliances wie Firewalls in den Pfad des Netzwerktraffics einfügen.
Wenn Sie eine richtlinienbasierte Route erstellen, wählen Sie aus, welche Ressourcen von der Route verarbeitet werden können. Die Route kann für Folgendes gelten:
- Das gesamte Netzwerk: alle VM-Instanzen, VPN-Gateways und Interconnects
- Netzwerk-Tags verwenden: 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 eintritt
Der nächste Hop einer richtlinienbasierten Route muss ein gültiger interner Network 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 auf den ausgehenden und zurückgegebenen Pfaden die gleiche Appliance erreichen kann, ohne dass die Quell-NAT konfiguriert werden muss.
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, wobei andere Routen mit derselben Priorität ignoriert werden. 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 unidirektionalen Traffic oder mehrere Regeln zur Verarbeitung von bidirektionalem 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 die IP-Weiterleitung aktiviert sein.
Hinweise zu PBR
Für die Verwendung richtlinienbasierter Routen ist eine spezielle Konfiguration erforderlich, und zwar auf folgende Weise.
Beispielsweise mit PBR mit GKE, PSC oder mit PGA/PSA.
Weitere Informationen zu PBR mit GKE finden Sie hier und zum Abschnitt zu allgemeinen PBR-Einschränkungen hier.
Lerninhalte
- Richtlinienbasierte Routen konfigurieren
Voraussetzungen
- Kenntnisse in der Bereitstellung von Instanzen und der Konfiguration von Netzwerkkomponenten
- Kenntnisse der VPC-Firewallkonfiguration
2. Testumgebung
In diesem Codelab wird eine einzelne VPC verwendet. In dieser Umgebung gibt es zwei Computeressourcen, „clienta“ und „clientb“, die Pakete an eine andere Serverressource senden. Mithilfe von PBR und Filtern leiten wir den Traffic von „clienta“ über eine andere Compute-Ressource zur Durchsetzung der Firewall weiter, während der Traffic von „clientb“ direkt zum Server geleitet wird. Das folgende Diagramm veranschaulicht den Pfad.
Im obigen Diagramm sollte es für PBR-Pfade eigentlich einen ILB (Network Internal Load Balancer) geben. Aus Gründen der Übersichtlichkeit wurde dies im Diagramm weggelassen.
3. Hinweis
Für das Codelab ist ein einzelnes Projekt erforderlich.
Über 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.
Über 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“:
Über Cloud Shell:
gcloud compute networks create $prefix-vpc --subnet-mode=custom
Subnetz
Erstellen Sie die entsprechenden Subnetze in der ausgewählten Region:
Über 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, erstellen Sie eine Firewallregel, die:
- Gilt für alle VM-Instanzen, die über 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.
Über 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 Netzwerk-Tag „server“
- Eingehender Traffic von allen Quellen ist zulässig
Über 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 Firewall Pakete empfangen kann, müssen Sie eingehende Verbindungen für alle Protokolle und Ports zulassen.
- Gilt für Ressourcen mit dem Netzwerk-Tag „fw“
- Eingehender Traffic von Quellen aus dem Bereich 10.10.10.0/24 ist zulässig.
Über 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
Systemdiagnoseprüfungen zulassen
- Gilt für Ressourcen mit dem Netzwerk-Tag „fw“
- Eingehender Traffic aus Systemdiagnosebereichen zulassen
Über 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 und Cloud NAT erstellen
In diesem Abschnitt wird beschrieben, wie die privaten VMs die entsprechenden Softwarepakete aus dem Internet herunterladen können.
Cloud Router erstellen
Über Cloud Shell:
gcloud compute routers create ${prefix}-cr \
--region=${region} \
--network=${prefix}-vpc
Cloud NAT-Gateway erstellen
Über 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:
Über 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'
Über 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'
Über 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'
Über 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. Verbindung ohne PBR testen
Stellen Sie eine SSH-Verbindung zu den Client-Compute-VMs her, die wir kürzlich erstellt haben, und prüfen Sie die Konnektivität von beiden Clients zum Server.
Melden Sie sich von 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 zusätzlichen Cloud Shell-Tab, indem Sie auf das Pluszeichen (+) klicken.
Legen Sie in cloudshell2 Variablen für die 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
Stellen Sie von cloudshell2 aus eine SSH-Verbindung zu clientb her:
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 nun das VM-Terminal und kehren Sie zu Cloud Shell zurück.
10. Instanzgruppe erstellen
Erstellen Sie eine nicht verwaltete Instanzgruppe für Ihre Firewall-VM.
Über Cloud Shell:
gcloud compute instance-groups unmanaged create pbr-uig --zone=$zone
Fügen Sie die Firewall-Instanz der nicht verwalteten Instanzgruppe hinzu.
Über 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 Backend-Dienst. Wir führen eine einfache TCP-Systemdiagnose für Port 80 durch.
Über Cloud Shell:
gcloud compute health-checks create tcp $prefix-hc-tcp-80 --region=$region --port 80
12. Backend-Dienst erstellen
Erstellen Sie einen Backend-Dienst, der an die Weiterleitungsregel angehängt werden soll.
Über 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 die Instanzgruppe dem Backend-Dienst hinzu.
Über Cloud Shell:
gcloud compute backend-services add-backend be-pbr --region=$region --instance-group=pbr-uig --instance-group-zone=$zone
13. Weiterleitungsregel erstellen
Über 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 Clients. Der gesamte IPv4-Traffic wird an die Weiterleitungsregel 10.10.10.25 weitergeleitet, wenn die Quell-IP 10.10.10.10/32 (die Adresse von clienta) und die Ziel-IP 10.10.10.0/24 ist.
Das bedeutet, dass „clienta“ mit PBR übereinstimmt, nicht aber „clientb“.
Über 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. Der gesamte IPv4-Traffic wird an die Weiterleitungsregel 10.10.10.25 weitergeleitet, wenn die Quell-IP 10.10.10.200/32 und die Ziel-IP 10.10.10.10/32 ist.
Über 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. Verbindung mit PBR testen
Wir überprüfen nun die PBR-Funktionalität. Die „fw“-Instanz ist mit iptables konfiguriert, um Anfragen abzulehnen, die für den Server bestimmt sind. Wenn PBR funktioniert, schlagen die Anfragen, die zuvor auf clienta funktioniert haben, jetzt fehl, während clientb weiterhin erfolgreich ist.
Stellen Sie eine SSH-Verbindung zur Compute-VM „clienta“ her und führen Sie dieselben Tests aus.
Von 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 so konfiguriert wurde, dass dieser Traffic blockiert wird.
Stellen Sie eine SSH-Verbindung zu „clientb“ her und führen Sie denselben Verbindungstest aus.
Über 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 von clientb an den Server erfolgreich. Das liegt daran, dass die Anfragen nicht mit einer PBR-Regel für die Quell-IP-Adresse übereinstimmen.
16. [Optional] Mit Erfassungen auf der Firewall validieren
In diesem optionalen Abschnitt haben Sie die Möglichkeit, PBR zu validieren, indem Sie Paketerfassungen auf der Firewall-VM vornehmen.
Sie sollten weiterhin eine SSH-Verbindung in cloudshell1 und cloudshell2 zu clienta und clientb haben.
Öffnen Sie einen zusätzlichen Cloud Shell-Tab, indem Sie auf das Pluszeichen (+) klicken.
Legen Sie in cloudshell3 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
Stellen Sie eine SSH-Verbindung zu „fw“ her:
gcloud compute ssh fw --zone=$zone --tunnel-through-iap
Führen Sie den folgenden Befehl auf „fw“ (cloudshell3) aus:
sudo tcpdump -i any icmp -nn
Führen Sie den Ping-Test von clienta (cloudshell1) aus aus:
ping 10.10.10.200 -c 5
Führen Sie den Ping-Test von clientb (cloudshell2) aus:
ping 10.10.10.200 -c 5
Ausgabe auf FW (Cloud Shell 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 von clientb (10.10.10.11) sind keine Pakete zu sehen, da PBR nicht anwendbar ist.
Beenden Sie die Sitzung und kehren Sie zu Cloud Shell zurück, um Ressourcen zu bereinigen.
17. Bereinigungsschritte
Entfernen Sie in Cloud Shell die PBR-Regel, die Weiterleitungsregel, den Backend-Dienst, die Systemdiagnose, die Instanzgruppe, die Compute-Instanzen, NAT, den Cloud Router und die 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