1. Wprowadzenie
Trasy oparte na zasadach
Trasy oparte na zasadach umożliwiają wybór następnego przeskoku nie tylko na podstawie docelowego adresu IP pakietu. Ruch możesz też dopasowywać według protokołu i źródłowego adresu IP. Pasujący ruch jest przekierowywany do wewnętrznego sieciowego systemu równoważenia obciążenia. Może to pomóc w umieszczaniu urządzeń, takich jak zapory sieciowe, na ścieżce ruchu w sieci.
Gdy tworzysz trasę opartą na zasadach, wybierasz zasoby, których ruch może być przetwarzany przez tę trasę. Trasa może dotyczyć:
- Cała sieć: wszystkie instancje maszyn wirtualnych, bramy VPN i połączenia Interconnect.
- Używanie tagów sieci: wybieranie instancji maszyn wirtualnych w sieci VPC
- Region połączenia międzysieciowego: cały ruch wchodzący do sieci VPC przez przyłącza VLAN w regionie.
Następny przeskok trasy opartej na zasadach musi być prawidłowym wewnętrznym sieciowym systemem równoważenia obciążenia, który znajduje się w tej samej sieci VPC co trasa oparta na zasadach.
Wewnętrzne sieciowe systemy równoważenia obciążenia domyślnie używają symetrycznego haszowania, dzięki czemu ruch może docierać do tego samego urządzenia na ścieżkach wychodzących i powrotnych bez konfigurowania NAT źródła.
Trasy oparte na zasadach mają wyższy priorytet niż inne typy tras z wyjątkiem specjalnych ścieżek powrotnych.
Jeśli 2 trasy oparte na zasadach mają ten sam priorytet, Google Cloud wybiera jedną z nich za pomocą deterministycznego algorytmu wewnętrznego, ignorując inne trasy o tym samym priorytecie. Trasy oparte na zasadach nie korzystają z dopasowywania najdłuższego prefiksu i wybierają tylko trasę o najwyższym priorytecie.
Możesz utworzyć jedną regułę dla ruchu w jednym kierunku lub kilka reguł do obsługi ruchu dwukierunkowego.
Aby używać tras opartych na zasadach z Cloud Interconnect, musisz zastosować trasę do wszystkich połączeń Cloud Interconnect w całym regionie. Trasy oparte na zasadach nie mogą być stosowane tylko do pojedynczego połączenia Cloud Interconnect.
Instancje maszyn wirtualnych, które odbierają ruch z trasy opartej na zasadach, muszą mieć włączone przekierowywanie adresów IP.
Uwagi dotyczące PBR
Aby korzystać z tras opartych na zasadach w opisany poniżej sposób, musisz zastosować specjalną konfigurację.
Na przykład używanie PBR z GKE, PSC lub PGA/PSA.
Więcej informacji o PBR w GKE znajdziesz tutaj, a ogólne ograniczenia PBR – tutaj.
Czego się nauczysz
- Jak skonfigurować trasy oparte na zasadach
Czego potrzebujesz
- umiejętność wdrażania instancji i konfigurowania komponentów sieciowych;
- Znajomość konfiguracji zapory sieciowej VPC
2. Środowisko testowe
W tym laboratorium wykorzystamy jedną sieć VPC. W tym środowisku będą 2 zasoby obliczeniowe (clienta i clientb), które będą wysyłać pakiety do innego zasobu serwera. Korzystając z PBR i filtrów, wymusimy kierowanie ruchu z klienta a przez inny zasób obliczeniowy w celu egzekwowania zapory sieciowej, a ruch z klienta b będzie kierowany bezpośrednio na serwer. Ścieżkę tę ilustruje poniższy diagram.
Na powyższym diagramie powinna znajdować się wewnętrzny system równoważenia obciążenia (sieciowy wewnętrzny system równoważenia obciążenia) dla ścieżek PBR. Zostało to pominięte dla uproszczenia diagramu.
3. Zanim zaczniesz
Codelab wymaga jednego 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
Jeśli nie zostało to jeszcze zrobione, włącz interfejsy API, aby korzystać z usług.
W Cloud Shell:
gcloud services enable compute.googleapis.com gcloud services enable networkconnectivity.googleapis.com
5. Tworzenie sieci VPC i podsieci
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 połączenie z instancjami maszyn wirtualnych, utwórz regułę zapory sieciowej, która:
- Dotyczy wszystkich instancji maszyn wirtualnych, które mają być dostępne przez IAP.
- Zezwala na ruch przychodzący z zakresu adresów IP 35.235.240.0/20. Ten zakres zawiera wszystkie adresy IP, których IAP używa 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 standardowy port HTTP (TCP 80) i protokół ICMP na serwerze:
- Dotyczy zasobów z tagiem sieci „server”
- Dopuszcza 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 zapora mogła odbierać pakiety, zezwól na ruch przychodzący we wszystkich protokołach i portach.
- Dotyczy zasobów z tagiem sieciowym „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:
- Dotyczy zasobów z tagiem sieciowym „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. Tworzenie routera Cloud Router i Cloud NAT
Celem tej sekcji jest umożliwienie prywatnym maszynom wirtualnym pobierania odpowiednich pakietów 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 Server:
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łączenia bez PBR
Połącz się przez SSH z utworzonymi niedawno maszynami wirtualnymi Compute Engine i sprawdź połączenie z obu klientów z serwerem.
Zaloguj się na klienta z cloudshell1:
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 się powieść.
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 +.
W cloudshell2 ustaw zmienne 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 cloudshell2 SSH do clientb:
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 się powieść.
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 zamknij terminal maszyny wirtualnej i wróć do Cloud Shell.
10. Tworzenie grupy instancji
Utwórz niezarządzaną grupę instancji dla maszyny wirtualnej zapory.
W Cloud Shell:
gcloud compute instance-groups unmanaged create pbr-uig --zone=$zone
Dodaj instancję zapory do grupy instancji niezarządzanych.
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. Przeprowadzimy prostą kontrolę stanu portu TCP 80.
W Cloud Shell:
gcloud compute health-checks create tcp $prefix-hc-tcp-80 --region=$region --port 80
12. Tworzenie usługi backendu
Utwórz usługę backendu, którą chcesz dołączyć 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. Tworzenie reguły 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. Tworzenie reguły PBR
Ta reguła PBR dotyczy klientów. Będzie kierować cały ruch IPv4 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 klient a będzie pasować do PBR, a nie do klienta b.
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 ma zastosowanie do serwera. Będzie kierować cały ruch IPv4 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 zweryfikujemy funkcję PBR. Instancja „fw” jest skonfigurowana za pomocą iptables, aby odrzucać żądania kierowane do serwera. Jeśli PBR działa, żądania, które wcześniej działały na kliencie a, teraz będą kończyć się niepowodzeniem, a klient b nadal będzie działać prawidłowo.
Połącz się z maszyną wirtualną klienta przez SSH i przeprowadź te same testy.
Z cloudshell1:
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 nie powiodły się, możemy potwierdzić, że PBR aktywnie kieruje ruch klienta do instancji FW, która została skonfigurowana do blokowania tego ruchu.
Połącz się z clientb za pomocą SSH i uruchom ten sam test połączenia.
Z cloudshell2:
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 z klienta b do serwera są realizowane. Dzieje się tak, ponieważ żądania nie pasują do reguły PBR dla źródłowego adresu IP.
16. [Opcjonalnie] Sprawdzanie poprawności za pomocą przechwytywania w zaporze sieciowej
W tej opcjonalnej sekcji możesz sprawdzić PBR, przechwytując pakiety na maszynie wirtualnej zapory sieciowej.
Powinno być nadal możliwe połączenie SSH z cloudshell1 i cloudshell2 z klientami clienta i clientb.
Otwórz dodatkową kartę Cloud Shell, klikając +.
W cloudshell3 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
Połącz się z fw przez SSH:
gcloud compute ssh fw --zone=$zone --tunnel-through-iap
Uruchom to polecenie na urządzeniu fw (cloudshell3):
sudo tcpdump -i any icmp -nn
Na maszynie clienta (cloudshell1) uruchom test ping:
ping 10.10.10.200 -c 5
Na maszynie clientb (cloudshell2) uruchom test ping:
ping 10.10.10.200 -c 5
Dane wyjściowe w 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
W tcpdump z klienta b (10.10.10.11) nie zobaczysz żadnych pakietów, ponieważ PBR nie ma zastosowania.
Wróć do Cloud Shell, aby wyczyścić zasoby.
17. Procedura czyszczenia
W 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 ćwiczenia.
Omówione zagadnienia
- Trasy oparte na zasadach