1. Wprowadzenie
Trasy oparte na zasadach
Trasy oparte na zasadach pozwalają wybrać następny przeskok na podstawie więcej niż docelowego adresu IP pakietu. Możesz też dopasowywać ruch według protokołu i źródłowego adresu IP. Pasujący ruch jest przekierowywany do wewnętrznego systemu równoważenia obciążenia sieci. Ułatwia to umieszczanie urządzeń, takich jak zapory sieciowe, w ścieżce ruchu sieciowego.
Podczas tworzenia trasy opartej na zasadach wybierasz zasoby, które mogą przetwarzać ruch na tej trasie. Trasa może odnosić się do:
- Cała sieć: wszystkie instancje maszyn wirtualnych, bramy VPN i połączenia międzysieciowe
- Używanie tagów sieci: wybierz instancje maszyn wirtualnych w VPC
- Region połączenia międzysieciowego: cały ruch trafiający do sieci VPC przez przyłącza VLAN w regionie
Następny przeskok trasy opartej na zasadach musi być prawidłowym wewnętrznym systemem równoważenia obciążenia sieci w tej samej sieci VPC co trasa oparta na zasadach.
Wewnętrzne sieciowe systemy równoważenia obciążenia używają domyślnie szyfrowania symetrycznego, więc ruch może docierać do tego samego urządzenia na ścieżkach wychodzących i zwrotnych bez konfigurowania źródłowego NAT.
Trasy oparte na zasadach mają wyższy priorytet niż inne typy tras z wyjątkiem specjalnych ścieżek zwrotnych.
Jeśli 2 trasy oparte na zasadach mają ten sam priorytet, Google Cloud używa deterministycznego, wewnętrznego algorytmu, aby wybrać jedną trasę opartą na zasadach, ignorując inne trasy o tym samym priorytecie. Trasy oparte na zasadach nie używają dopasowania z najdłuższym prefiksem i wybierają tylko trasę o najwyższym priorytecie.
Możesz utworzyć jedną regułę dla ruchu jednokierunkowego lub wiele reguł do obsługi ruchu dwukierunkowego.
Aby można było używać tras opartych na zasadach z Cloud Interconnect, trasa musi być zastosowana do wszystkich połączeń Cloud Interconnect w całym regionie. Tras opartych na zasadach nie można stosować tylko do pojedynczego połączenia Cloud Interconnect.
Instancje maszyn wirtualnych, które otrzymują ruch z trasy opartej na zasadach, muszą mieć włączone przekierowanie IP.
Uwagi dotyczące PBR
Aby można było korzystać z tras opartych na zasadach na poniższe sposoby, konieczna jest specjalna konfiguracja.
Możesz na przykład użyć PBR z GKE, PSC lub PGA/PSA.
Więcej informacji o PBR w GKE znajdziesz tutaj, a o ogólnych ograniczeniach PBR – tutaj.
Czego się nauczysz
- Jak skonfigurować trasy oparte na zasadach
Czego potrzebujesz
- Wiedza na temat wdrażania instancji i konfigurowania komponentów sieci
- Wiedza o konfiguracji zapory sieciowej VPC
2. Środowisko testowe
To ćwiczenia z programowania będą wykorzystywać jedną sieć VPC. W tym środowisku będą znajdować się 2 zasoby obliczeniowe – clienta (klienta) i customerb (klient) – które będą wysyłać pakiety do innego zasobu serwera. Przy użyciu PBR i filtrów wymusimy ruch z klienta przez inny zasób obliczeniowy na potrzeby egzekwowania zapory sieciowej, podczas gdy ruch klientów będzie kierowany bezpośrednio do serwera. Poniższy diagram przedstawia ścieżkę.
Na diagramie powyżej technicznie powinien występować wewnętrzny system równoważenia obciążenia sieci dla ścieżek PBR. Pominięto to dla uproszczenia diagramu.
3. Zanim zaczniesz
Ćwiczenia z programowania wymagają 1 projektu.
W 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. Włącz interfejsy API
Włącz interfejsy API, aby korzystać z usług, jeśli jeszcze nie zostało to zrobione
W Cloud Shell:
gcloud services enable compute.googleapis.com gcloud services enable networkconnectivity.googleapis.com
5. Utwórz sieć i podsieć VPC
Sieć VPC
Utwórz sieć VPC Codelab-pbr-vpc:
W Cloud Shell:
gcloud compute networks create $prefix-vpc --subnet-mode=custom
Podsieć
Utwórz odpowiednie podsieci w wybranym regionie:
W Cloud Shell:
gcloud compute networks subnets create $prefix-vpc-subnet \
--range=10.10.10.0/24 --network=$prefix-vpc --region=${region}
6. Utwórz reguły zapory sieciowej
Aby umożliwić IAP nawiązywanie połączeń z maszynami wirtualnymi, utwórz regułę zapory sieciowej, która:
- Dotyczy wszystkich instancji maszyn wirtualnych, które mają być dostępne za pomocą IAP.
- Zezwala na ruch przychodzący z zakresu adresów IP 35.235.240.0/20. Ten zakres zawiera wszystkie adresy IP używane przez IAP do przekierowywania TCP.
W 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
Aby zezwolić na korzystanie z serwera przez standardowy port HTTP (TCP 80) i protokół ICMP:
- Ma zastosowanie do zasobów z tagiem sieci „server”
- Zezwala na ruch przychodzący ze wszystkich źródeł
W 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
Aby umożliwić programowi FW odbieranie pakietów, zezwól na ruch przychodzący we wszystkich protokołach i portach.
- Ma zastosowanie do zasobów z tagiem sieci „fw”
- Zezwala na ruch przychodzący ze źródeł 10.10.10.0/24
W 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
Aby zezwolić na sondy kontroli stanu
- Ma zastosowanie do zasobów z tagiem sieci „fw”
- Zezwala na ruch przychodzący z zakresów kontroli stanu
W 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. Utwórz router Cloud Router Cloud NAT
Dzięki tej sekcji prywatne maszyny wirtualne mogą pobierać odpowiednie pakiety oprogramowania z internetu.
Tworzenie routera Cloud Router
W Cloud Shell:
gcloud compute routers create ${prefix}-cr \
--region=${region} \
--network=${prefix}-vpc
Tworzenie bramy Cloud NAT
W 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. Tworzenie instancji Compute
Utwórz instancje obliczeniowe: ClientA, ClientB, FW i serwer:
W 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'
W 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'
W 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'
W 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. Testowanie połączeń bez PBR
Łącz się przez SSH z maszynami wirtualnymi klienta, które niedawno utworzyliśmy, i weryfikujemy połączenia między klientami a serwerem.
Zaloguj się w Cloudshell1 do klienta clienta:
gcloud compute ssh clienta --zone=$zone --tunnel-through-iap
Uruchom te polecenia:
ping 10.10.10.200 -c 5
curl 10.10.10.200/index.html
Pingi i żądania curl powinny działać.
Dane wyjściowe:
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>
Otwórz dodatkową kartę Cloud Shell, klikając +.
Z Cloud Shell2 zestawu zmiennych do użycia:
export project_id=`gcloud config list --format="value(core.project)"` export region=us-central1 export zone=us-central1-a export prefix=codelab-pbr
Z Cloud Shell2 przez SSH do klienta:
gcloud compute ssh clientb --zone=$zone --tunnel-through-iap
Uruchom te polecenia:
ping 10.10.10.200 -c 5
curl 10.10.10.200/index.html
Pingi i żądania curl powinny działać.
Dane wyjściowe:
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>
Teraz wyjdź z terminalu maszyny wirtualnej i wróć do Cloud Shell.
10. Tworzenie grupy instancji
Utwórz niezarządzaną grupę instancji dla dotychczasowej maszyny wirtualnej.
W Cloud Shell:
gcloud compute instance-groups unmanaged create pbr-uig --zone=$zone
Dodaj instancję do niezarządzanej grupy instancji.
W Cloud Shell:
gcloud compute instance-groups unmanaged add-instances pbr-uig --instances=fw --zone=$zone
11. Utwórz kontrolę stanu
Utwórz kontrolę stanu usługi backendu. Wykonamy prostą kontrolę stanu TCP 80.
W Cloud Shell:
gcloud compute health-checks create tcp $prefix-hc-tcp-80 --region=$region --port 80
12. Utwórz usługę backendu
Utwórz usługę backendu, która zostanie dołączona do reguły przekierowania.
W 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
Teraz dodaj grupę instancji do usługi backendu.
W Cloud Shell:
gcloud compute backend-services add-backend be-pbr --region=$region --instance-group=pbr-uig --instance-group-zone=$zone
13. Utwórz regułę przekierowania.
W 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. Utwórz regułę PBR
Ta reguła PBR dotyczy klientów. Cały ruch IPv4 zostanie przekierowany do reguły przekierowania 10.10.10.25, jeśli źródłowy adres IP to 10.10.10.10/32 (adres klienta), a docelowy adres IP to 10.10.10.0/24.
Oznacza to, że parametr clienta będzie pasować do PBR, a nie do klienta.
W 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
Ta reguła PBR dotyczy serwera. Cały ruch IPv4 zostanie przekierowany do reguły przekierowania 10.10.10.25, jeśli źródłowy adres IP to 10.10.10.200/32, a docelowy adres IP to 10.10.10.10/32.
W 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. Testowanie połączenia z PBR
Teraz sprawdzimy, czy funkcja PBR działa prawidłowo. Wyrażenie „fw” instancja jest skonfigurowana z adresami IP, aby odrzucać żądania wysyłane do serwera. Jeśli PBR działa, żądania, które były obsługiwane wcześniej w przypadku klienta, będą kończyć się niepowodzeniem, a klientb będzie nadal pomyślnie wywoływany.
Połącz się z maszyną wirtualną Clienta Compute przez SSH i przeprowadź te same testy.
Z Cloud Shell1:
gcloud compute ssh clienta --zone=$zone --tunnel-through-iap
Uruchom te polecenia:
ping 10.10.10.200 -c 5
curl 10.10.10.200/index.html
Dane wyjściowe:
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
Ponieważ żądania się nie powiodły, możemy potwierdzić, że PBR aktywnie kieruje ruch klienta do instancji FW, która została skonfigurowana tak, aby blokować ten ruch.
Połącz się z klientem przez SSH i uruchom ten sam test połączenia.
W Cloud Shell2:
gcloud compute ssh clientb --zone=$zone --tunnel-through-iap
Uruchom te polecenia:
ping 10.10.10.200 -c 5
curl 10.10.10.200/index.html
Dane wyjściowe:
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>
Jak widać, żądania przesyłane między klientem a serwerem zakończyły się powodzeniem. Dzieje się tak, ponieważ żądania nie pasują do reguły PBR dla źródłowego adresu IP.
16. [Opcjonalnie] Weryfikacja za pomocą przechwytywania w zaporze sieciowej
W tej opcjonalnej sekcji możesz zweryfikować PBR, przechwytując pakiety w maszynie wirtualnej zapory sieciowej.
Nadal powinno być połączenie SSH w usługach cloudshell1 i cloudshell2 z usługami clienta i clientb.
Otwórz dodatkową kartę Cloud Shell, klikając +.
W Cloud Shell3 ustaw zmienne:
export project_id=`gcloud config list --format="value(core.project)"` export region=us-central1 export zone=us-central1-a export prefix=codelab-pbr
Łączenie z serwerem SSH:
gcloud compute ssh fw --zone=$zone --tunnel-through-iap
Uruchom to polecenie w fw (cloudshell3):
sudo tcpdump -i any icmp -nn
Z poziomu klienta clienta (cloudshell1) uruchom test ping:
ping 10.10.10.200 -c 5
Z poziomu klienta (cloudshell2) uruchom test ping:
ping 10.10.10.200 -c 5
Dane wyjściowe w systemie operacyjnym (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
Nie będą widoczne żadne pakiety na pliku tcpdump z klienta clientb (10.10.10.11), ponieważ PBR nie ma zastosowania.
Wróć do Cloud Shell, aby wyczyścić zasoby.
17. Procedura czyszczenia
Z Cloud Shell usuń regułę PBR, regułę przekierowania, usługę backendu, kontrolę stanu, grupę instancji, instancje obliczeniowe, NAT, router Cloud Router i reguły zapory sieciowej.
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
Usuń podsieć i sieci VPC:
gcloud -q compute networks subnets delete $prefix-vpc-subnet \
--region $region
gcloud -q compute networks delete $prefix-vpc
18. Gratulacje!
Gratulujemy ukończenia ćwiczeń z programowania.
Omówione zagadnienia
- Trasy oparte na zasadach