Cloud NGFW Essentials for Load Balancers

1. Wprowadzenie

W tym ćwiczeniu dowiesz się, jak korzystać z Essentials zapory sieciowej Cloud Next Generation Firewall (NGFW) w przypadku wewnętrznych systemów równoważenia obciążenia aplikacji (ALB) i sieciowych systemów równoważenia obciążenia serwera proxy (NLB) przy użyciu regionalnych zasad zapory sieciowej.

Cloud NGFW to w pełni rozproszona usługa zapory sieciowej z zaawansowaną ochroną przed zagrożeniami i funkcjami mikrosegmentacji, która chroni zbiory zadań Google Cloud. Włączenie Cloud NGFW na poziomie systemu równoważenia obciążenia powoduje zastosowanie spójnych reguł zasad zapory sieciowej do całego ruchu TCP przychodzącego do wewnętrznych systemów równoważenia obciążenia opartych na serwerze proxy. Upraszcza wdrażanie stanu zabezpieczeń organizacji, ponieważ zapewnia szersze egzekwowanie zasad we wszystkich usługach.

W tym Codelabie omawiamy te usługi i funkcje Cloud NGFW i Cloud Load Balancer:

Cloud NGFW Essentials
Regionalne zasady zapory sieciowej
Regionalny wewnętrzny system równoważenia obciążenia aplikacji
Backendowa zarządzana grupa instancji (MIG) i grupa punktów końcowych sieci Private Service Connect (PSC)

UWAGA: najnowsze obsługiwane funkcje i ograniczenia reguł zasad zapory sieciowej dla elementów docelowych modułu równoważenia obciążenia znajdziesz w dokumentacji Cloud NGFW.

Czego się dowiesz

Włączanie podstawowych reguł zasad zapory sieciowej Cloud NGFW kierowanych na systemy równoważenia obciążenia
Ochrona wewnętrznej usługi systemu równoważenia obciążenia konsumenta za pomocą backendów instancji maszyn wirtualnych i usługi PSC
Testowanie dostępu klienta i weryfikowanie dzienników zapory sieciowej

Wymagania

projekt Google Cloud,
znajomość pojęć związanych z sieciami w Google Cloud i korzystania z Google Cloud CLI;
Uprawnienia: roles/compute.instanceAdmin.v1, roles/compute.networkAdmin, roles/compute.securityAdmin i roles/storage.admin

2. Pojęcia

Poziomy funkcji zapory sieciowej

Cloud NGFW ma 3 wersje funkcji: Essentials, Standard i Enterprise. Każdy kolejny poziom zapewnia dodatkowe możliwości filtrowania i sprawdzania ruchu w sieci.

Podsumowanie możliwości filtrowania Essentials w Cloud NGFW:

Poziom	Możliwości	Warstwy sieciowe	Przykładowe parametry reguły
Essentials	Filtrowanie adresów IP i zakresów adresów IP	IP	`--src-ip-ranges=1.1.1.0/24,2.2.2.2/32`
Essentials	Grupy adresów	IP	`--src-address-groups=special-ranges`
Essentials	Filtrowanie protokołów i portów	TCP	`--layer4-configs=tcp`
Essentials	Bezpieczne tagi	Metadane	`--src-secure-tags=tagValues/987654321098`
Essentials	Filtrowanie według typu sieci	IP / metadane	`--src-network-type=INTRA_VPC`

Reguły przekierowania systemu równoważenia obciążenia wyraźnie określają docelowy port TCP. Parametr reguły zapory sieciowej --layer4-configs= może określać tylko wartość tcp. Wartość portu jest implikowana przez samą regułę przekierowania.

Grupy adresów i typy sieci mogą być przydatne do zwiększenia skuteczności reguł zasad zapory sieciowej. Typy sieci VPC_NETWORKS i INTRA_VPC są obsługiwane w przypadku reguł w zasadach zapory sieciowej dla systemów równoważenia obciążenia.

UWAGA: reguły zasad zapory sieciowej dla systemów równoważenia obciążenia obsługują tylko --direction=INGRESS. Te reguły służą do kontrolowania dostępu do usług udostępnianych przez system równoważenia obciążenia.

Filtrowanie w płaszczyźnie danych

Funkcje Cloud NFGW w wersji Essentials obejmują podstawowe reguły zapory sieciowej z utrzymywaniem stanu na warstwach 3 (adres IP) i 4 (port TCP). Wszystkie te funkcje reguł zasad zapory sieciowej są wydajnie wykonywane w płaszczyźnie danych modułu równoważenia obciążenia bez konieczności pełnego sprawdzania pakietów.

Reguły zasad Cloud NGFW Essentials kierowane na instancje maszyn wirtualnych są egzekwowane w rozproszonej sieci VPC w ramach podstawowej sieci zdefiniowanej programowo Google Cloud (Andromeda). Filtrowanie pakietów i reguły zasad zapory sieciowej są egzekwowane na poziomie hiperwizora każdej instancji maszyny wirtualnej, zanim pakiet dotrze do interfejsu sieciowego instancji maszyny wirtualnej.

Reguły zasad Cloud NGFW w wersji Essentials, które są kierowane na usługi równoważenia obciążenia, są egzekwowane przy użyciu technologii bazowych usług równoważenia obciążenia Google Cloud, a w szczególności infrastruktury serwera proxy usługi Envoy. Korzystając z tego samego modelu zasobów i struktury reguł Cloud NFGW, filtrowanie pakietów z utrzymywaniem stanu jest wymuszane bezpośrednio w płaszczyźnie danych modułu równoważenia obciążenia opartego na serwerze proxy.

Cele systemu równoważenia obciążenia

Istnieje kilka kluczowych różnic między zasadami Cloud NGFW kierowanymi na systemy równoważenia obciążenia a zasadami kierowanymi na instancje maszyn wirtualnych.

Reguły zasad zapory sieciowej można zastosować do pojedynczego systemu równoważenia obciążenia, określając --target-type=INTERNAL_MANAGED_LB wraz z konkretnym odwołaniem do reguły przekierowania systemu równoważenia obciążenia --target-forwarding-rules=FR_NAME. Aby kierować ruch do wszystkich reguł przekazywania systemu równoważenia obciążenia w regionie sieci VPC (gdzie region jest objęty zakresem zasad), należy pominąć konkretne odwołanie i użyć tylko flagi --target-type=INTERNAL_MANAGED_LB.

Jeśli w konfiguracji reguły parametr --target-type nie jest ustawiony, reguła domyślnie jest stosowana automatycznie do wszystkich instancji maszyn wirtualnych, a nie do modułów równoważenia obciążenia.

Sieć Codelabs

W tym ćwiczeniu używany jest jeden projekt z jedną siecią VPC i tymi zasobami:

2 podsieci regionalne
jedne regionalne zasady zapory sieciowej,
3 regionalne wewnętrzne systemy równoważenia obciążenia aplikacji
- www Usługa HTTP z backendem grupy instancji maszyn wirtualnych
- api Usługa HTTP z backendem grupy instancji maszyn wirtualnych
- gcs Usługa HTTPS z backendem PSC NEG do interfejsów API Google
2 instancje maszyn wirtualnych do testowania różnych zasad zezwalających i odmawiających.

Rys. 1. Sieć Codelabs

Reguły zasad zapory sieciowej kierowane na systemy równoważenia obciążenia są połączone z zasobami reguł przekierowania systemu równoważenia obciążenia. Systemy równoważenia obciążenia składają się z indywidualnie zdefiniowanych zasobów skonfigurowanych w taki sposób, aby zapewnić kompletną usługę równoważenia obciążenia. Definicja reguły przekierowania bezpośrednio odwołuje się do określonego zasobu docelowego serwera proxy zdefiniowanego dla tej reguły.

Rys. 1. Cloud NGFW dla zasobów systemu równoważenia obciążenia

Filtry Cloud NGFW Essentials są programowane w płaszczyźnie danych modułu równoważenia obciążenia i wdrażane w zdefiniowanej warstwie docelowej usługi proxy – analogicznie do interfejsu instancji maszyny wirtualnej – przy użyciu tych samych rozproszonych i spójnych mechanizmów zapory sieciowej do egzekwowania zasad.

3. Konfigurowanie projektu

Dostęp do projektu

W tym ćwiczeniu używany jest jeden projekt Google Cloud. Kroki konfiguracji korzystają z interfejsu wiersza poleceń gcloud cli i poleceń powłoki Linux.

Zacznij od uzyskania dostępu do wiersza poleceń projektu w chmurze Google Cloud:

Cloud Shell na stronie shell.cloud.google.com lub
Terminal lokalny z zainstalowanym interfejsem wiersza poleceń gcloud

Ustawianie identyfikatora projektu

gcloud config set project YOUR_PROJECT_ID_HERE

Włączanie usług API

gcloud services enable \
  cloudresourcemanager.googleapis.com \
  compute.googleapis.com \
  dns.googleapis.com \
  networksecurity.googleapis.com \
  certificatemanager.googleapis.com

Ustawianie zmiennych środowiskowych powłoki

# set your region preference
export REGION_1="us-west1"

# set your zone preference
export ZONE_1="us-west1-c"

# fetch project info and verify vars set
export PROJECT_ID=$(gcloud config list --format="value(core.project)")
export PROJECT_NO=$(gcloud projects describe ${PROJECT_ID} --format="value(projectNumber)")
echo ${REGION_1}
echo ${ZONE_1}
echo ${PROJECT_ID}
echo ${PROJECT_NO}

4. Podstawa sieci

W tej sekcji wdrożysz podstawową infrastrukturę sieciową, która będzie obejmować:

Globalna sieć VPC i podsieci regionalne
Regionalne zasady zapory sieciowej zabezpieczające sieć VPC
Cloud Router i Cloud NAT na potrzeby serwerów do pobierania pakietów oprogramowania
Rezerwacje adresów IP i rekordy DNS dla ruchu przychodzącego systemu równoważenia obciążenia

Tworzenie zasobów sieciowych

# create vpc network
gcloud compute networks create vnet-foo --subnet-mode=custom

# create subnet for clients
gcloud compute networks subnets create subnet-foo-1 \
  --network=vnet-foo \
  --region=${REGION_1} \
  --range=10.0.0.0/24 \
  --enable-private-ip-google-access

# create subnet for backend servers
gcloud compute networks subnets create subnet-foo-2 \
  --network=vnet-foo \
  --region=${REGION_1} \
  --range=172.16.0.0/24 \
  --enable-private-ip-google-access

# create proxy subnet
gcloud compute networks subnets create subnet-foo-3 \
  --purpose=REGIONAL_MANAGED_PROXY \
  --role=ACTIVE \
  --network=vnet-foo \
  --region=${REGION_1} \
  --range=172.16.128.0/23

Tworzenie komponentów zapory sieciowej

Utworzona tutaj podstawowa regionalna zasada zapory sieciowej zostanie użyta później podczas dodawania konkretnych miejsc docelowych systemu równoważenia obciążenia. Zasady muszą znajdować się w tym samym regionie co system równoważenia obciążenia.

Utwórz grupę adresów

Zacznij od utworzenia grupy adresów, aby zidentyfikować źródłowe zakresy adresów IP sondy kontroli stanu, które obsługują funkcje systemu równoważenia obciążenia. Te zakresy muszą być dozwolone, aby backendy systemu równoważenia obciążenia były uznawane za sprawne. Będzie on też później używany w regułach zasad zapory sieciowej kierowanych na systemy równoważenia obciążenia.

# create address group
gcloud network-security address-groups create uhc-probes \
  --description="health check probes" \
  --type=IPv4 \
  --capacity=42 \
  --location=${REGION_1}

# add ip ranges to address group
gcloud network-security address-groups add-items uhc-probes \
  --items=35.191.0.0/16,130.211.0.0/22 \
  --location=${REGION_1}

Utwórz zasadę zapory sieciowej

# create fw policy
gcloud compute network-firewall-policies create fw-policy-foo-${REGION_1} \
  --description="foo fw ${REGION_1}" \
  --region=${REGION_1}

# create fw policy rule to allow in iap
gcloud compute network-firewall-policies rules create 1001 \
  --description="allow iap for ssh" \
  --firewall-policy=fw-policy-foo-${REGION_1} \
  --firewall-policy-region=${REGION_1} \
  --action=allow \
  --direction=INGRESS \
  --layer4-configs=tcp:22 \
  --src-ip-ranges=35.235.240.0/20

# create fw policy rule to allow in health checks
gcloud compute network-firewall-policies rules create 1002 \
  --description="allow health checks to backends" \
  --firewall-policy=fw-policy-foo-${REGION_1} \
  --firewall-policy-region=${REGION_1} \
  --action=allow \
  --direction=INGRESS \
  --layer4-configs=tcp \
  --src-address-groups=projects/${PROJECT_ID}/locations/${REGION_1}/addressGroups/uhc-probes

# create fw policy rule to allow in lb proxies
gcloud compute network-firewall-policies rules create 1003 \
  --description="allow lb proxy" \
  --firewall-policy=fw-policy-foo-${REGION_1} \
  --firewall-policy-region=${REGION_1} \
  --action=allow \
  --direction=INGRESS \
  --layer4-configs=tcp:80,tcp:443,tcp:8080 \
  --src-ip-ranges=172.16.128.0/23

# associate fw policy to vnet
gcloud compute network-firewall-policies associations create \
  --name=fw-policy-association-foo-${REGION_1} \
  --firewall-policy=fw-policy-foo-${REGION_1} \
  --network=vnet-foo \
  --firewall-policy-region=${REGION_1}

Konfigurowanie usług sieciowych

Tworzenie routera Cloud Router i bramy NAT

# create router for nat
gcloud compute routers create cr-nat-foo \
  --network=vnet-foo \
  --asn=16550 \
  --region=${REGION_1}

# create nat gateway
gcloud compute routers nats create natgw-foo \
  --router=cr-nat-foo \
  --region=${REGION_1} \
  --auto-allocate-nat-external-ips \
  --nat-all-subnet-ip-ranges

Rezerwowanie adresów IP

# reserve vip for lb www service
gcloud compute addresses create vip-foo-www \
  --region=${REGION_1} \
  --subnet=subnet-foo-1 \
  --addresses=10.0.0.101

# reserve vip for lb api service
gcloud compute addresses create vip-foo-api \
  --region=${REGION_1} \
  --subnet=subnet-foo-1 \
  --addresses=10.0.0.102

# reserve vip for lb gcs service
gcloud compute addresses create vip-foo-gcs \
  --region=${REGION_1} \
  --subnet=subnet-foo-1 \
  --addresses=10.0.0.103

Tworzenie rekordów DNS

# create dns zone
gcloud dns managed-zones create zone-foo \
  --description="private zone for foo" \
  --dns-name=foo.com \
  --networks=vnet-foo \
  --visibility=private

# create dns record for www service
gcloud dns record-sets create www.foo.com \
  --zone=zone-foo \
  --type=A \
  --ttl=300 \
  --rrdatas="10.0.0.101"

# create dns record for api service
gcloud dns record-sets create api.foo.com \
  --zone=zone-foo \
  --type=A \
  --ttl=300 \
  --rrdatas="10.0.0.102"

# create dns record for gcs service
gcloud dns record-sets create gcs.foo.com \
  --zone=zone-foo \
  --type=A \
  --ttl=300 \
  --rrdatas="10.0.0.103"

To kończy część dotyczącą konfiguracji sieci… teraz przejdziemy do konfigurowania systemów równoważenia obciążenia.

5. Usługi systemu równoważenia obciążenia

W tej sekcji wdrożysz komponenty systemu równoważenia obciążenia (usługi backendu, mapy URL, docelowe serwery proxy i reguły przekierowania) dla 3 usług:

www service (ilb-foo-www) na porcie 80
api service (ilb-foo-api) na porcie 8080
usługa gcs (ilb-foo-gcs) na porcie 443 z certyfikatem TLS.

Oprócz zasobów backendu:

Instancje maszyn wirtualnych z serwerami HTTP w zarządzanej grupie instancji
Grupa punktów końcowych sieci Private Service Connect (PSC) do interfejsów API Google
Zasobnik Google Cloud Storage (GCS)

Konfigurowanie zasobów backendu

Tworzenie serwerów w grupie instancji maszyn wirtualnych

System równoważenia obciążenia www będzie używać serwerów backendu grupy instancji maszyn wirtualnych z uruchomionym serwerem WWW Apache, który nasłuchuje na porcie 80.

System równoważenia obciążenia api będzie używać tej samej grupy instancji maszyn wirtualnych, która nasłuchuje na porcie 8080.

# create vm startup config with http server
cat > vm-server-startup.sh << 'OEOF'
#! /bin/bash
set -e
apt-get update
apt-get install apache2 -y
vm_hostname="$(curl -H "Metadata-Flavor:Google" \
http://169.254.169.254/computeMetadata/v1/instance/name)"
vm_zone="$(curl -H "Metadata-Flavor:Google" \
http://169.254.169.254/computeMetadata/v1/instance/zone | cut -d/ -f4)"
echo "www served from: $vm_hostname in zone $vm_zone on port 80" | \
tee /var/www/html/index.html
echo "Listen 8080" | tee -a /etc/apache2/ports.conf
mkdir -p /var/www/api
echo "api served from: $vm_hostname in zone $vm_zone on port 8080" | \
tee /var/www/api/index.html
tee /etc/apache2/sites-available/api.conf << EOF
<VirtualHost *:8080>
    DocumentRoot /var/www/api
</VirtualHost>
EOF
a2ensite api.conf
systemctl restart apache2
OEOF

# create managed instance group template
gcloud compute instance-templates create mig-template-foo \
  --machine-type=e2-micro \
  --network=vnet-foo \
  --region=${REGION_1} \
  --subnet=subnet-foo-2 \
  --no-address \
  --shielded-secure-boot \
  --metadata-from-file=startup-script=vm-server-startup.sh

# create regional managed instance group
gcloud compute instance-groups managed create mig-foo \
  --region=${REGION_1} \
  --size=2 \
  --template=mig-template-foo \
  --base-instance-name=service-foo

# create named ports for instance group
gcloud compute instance-groups managed set-named-ports mig-foo \
  --named-ports=www-port:80,api-port:8080 \
  --region=${REGION_1}

Utwórz zasobnik na dane

System równoważenia obciążenia gcs będzie używać backendu PSC NEG do łączenia się z zasobnikiem Cloud Storage za pomocą frontendu interfejsów API Google.

# create random bucket name
export BUCKET=$(openssl rand -hex 12)
echo ${BUCKET}

UWAGA: zmienne środowiskowe są tracone po zamknięciu sesji powłoki. W razie potrzeby zanotuj nazwę zasobnika, aby dokończyć proces w przyszłej sesji.

# create bucket
gcloud storage buckets create gs://${BUCKET} --location=${REGION_1}

# give compute sa object admin role on bucket
gcloud storage buckets add-iam-policy-binding gs://${BUCKET} \
  --member=serviceAccount:${PROJECT_NO}-compute@developer.gserviceaccount.com \
  --role=roles/storage.objectAdmin

Utwórz certyfikat

System równoważenia obciążenia gcs będzie kończyć żądania HTTPS klientów za pomocą certyfikatu podpisanego samodzielnie, który jest wdrożony na docelowym serwerze proxy HTTPS.

# create cert
openssl req -x509 -newkey rsa:2048 \
  -nodes \
  -days 365 \
  -keyout foo-gcs-key.pem \
  -out foo-gcs-cert.pem \
  -subj "/CN=Foo, Inc." \
  -addext "subjectAltName=DNS:gcs.foo.com"

# upload to certificate manager
gcloud certificate-manager certificates create cert-foo-gcs \
  --private-key-file=foo-gcs-key.pem \
  --certificate-file=foo-gcs-cert.pem \
  --location=${REGION_1}

Tworzenie komponentów systemu równoważenia obciążenia

Aby zautomatyzować wdrażanie komponentów systemu równoważenia obciążenia, użyj tego skryptu. Pomoże to zwiększyć szybkość i dokładność wszystkich elementów konfiguracji.

Wdrażanie skryptu tworzenia systemu równoważenia obciążenia

# create script file
cat > create_lbs.sh << EOF
#!/bin/bash
set -e

# --- Create load balancer for www service port 80 ---
echo "--- Creating Load Balancer for WWW Service (ilb-foo-www) on port 80 ---"

echo "ilb-foo-www: creating health check (hc-foo-www)"
gcloud compute health-checks create http hc-foo-www \
  --use-serving-port \
  --region=${REGION_1}

echo "ilb-foo-www: creating backend service (bes-foo-www)"
gcloud compute backend-services create bes-foo-www \
  --load-balancing-scheme=INTERNAL_MANAGED \
  --protocol=HTTP \
  --port-name=www-port \
  --health-checks=hc-foo-www \
  --health-checks-region=${REGION_1} \
  --region=${REGION_1}

echo "ilb-foo-www: adding managed instance group (mig-foo) to backend service (bes-foo-www)"
gcloud compute backend-services add-backend bes-foo-www \
  --balancing-mode=UTILIZATION \
  --instance-group=mig-foo \
  --instance-group-region=${REGION_1} \
  --region=${REGION_1}

echo "ilb-foo-www: creating url map (ilb-foo-www)"
gcloud compute url-maps create ilb-foo-www \
  --default-service=bes-foo-www \
  --region=${REGION_1}

echo "ilb-foo-www: creating target http proxy (proxy-foo-www)"
gcloud compute target-http-proxies create proxy-foo-www \
  --url-map=ilb-foo-www \
  --url-map-region=${REGION_1} \
  --region=${REGION_1}

echo "ilb-foo-www: creating forwarding rule (fr-foo-www)"
gcloud compute forwarding-rules create fr-foo-www \
  --load-balancing-scheme=INTERNAL_MANAGED \
  --network=vnet-foo \
  --subnet=subnet-foo-1 \
  --subnet-region=${REGION_1} \
  --address=vip-foo-www \
  --ports=80 \
  --target-http-proxy=proxy-foo-www \
  --target-http-proxy-region=${REGION_1} \
  --region=${REGION_1}

echo "--- Successfully created Load Balancer for WWW Service (ilb-foo-www) ---"
echo

# --- Create load balancer for api service port 8080 ---
echo "--- Creating Load Balancer for API Service (ilb-foo-api) on port 8080 ---"

echo "ilb-foo-api: creating health check (hc-foo-api)"
gcloud compute health-checks create http hc-foo-api \
  --use-serving-port \
  --region=${REGION_1}

echo "ilb-foo-api: creating backend service (bes-foo-api)"
gcloud compute backend-services create bes-foo-api \
  --load-balancing-scheme=INTERNAL_MANAGED \
  --protocol=HTTP \
  --port-name=api-port \
  --health-checks=hc-foo-api \
  --health-checks-region=${REGION_1} \
  --region=${REGION_1}

echo "ilb-foo-api: adding managed instance group (mig-foo) to backend service (bes-foo-api)"
gcloud compute backend-services add-backend bes-foo-api \
  --balancing-mode=UTILIZATION \
  --instance-group=mig-foo \
  --instance-group-region=${REGION_1} \
  --region=${REGION_1}

echo "ilb-foo-api: creating url map (ilb-foo-api)"
gcloud compute url-maps create ilb-foo-api \
  --default-service=bes-foo-api \
  --region=${REGION_1}

echo "ilb-foo-api: creating target http proxy (proxy-foo-api)"
gcloud compute target-http-proxies create proxy-foo-api \
  --url-map=ilb-foo-api \
  --url-map-region=${REGION_1} \
  --region=${REGION_1}

echo "ilb-foo-api: creating forwarding rule (fr-foo-api)"
gcloud compute forwarding-rules create fr-foo-api \
  --load-balancing-scheme=INTERNAL_MANAGED \
  --network=vnet-foo \
  --subnet=subnet-foo-1 \
  --subnet-region=${REGION_1} \
  --address=vip-foo-api \
  --ports=8080 \
  --target-http-proxy=proxy-foo-api \
  --target-http-proxy-region=${REGION_1} \
  --region=${REGION_1}

echo "--- Successfully created Load Balancer for API Service (ilb-foo-api) ---"
echo

# --- Create load balancer for gcs service port 443 ---
echo "--- Creating Load Balancer for GCS Service (ilb-foo-gcs) on port 443 ---"

echo "ilb-foo-gcs: creating network endpoint group (neg-psc-gcs)"
gcloud compute network-endpoint-groups create neg-psc-gcs \
  --network-endpoint-type=private-service-connect \
  --psc-target-service=storage.${REGION_1}.rep.googleapis.com \
  --region=${REGION_1}

echo "ilb-foo-gcs: creating backend service (bes-foo-gcs)"
gcloud compute backend-services create bes-foo-gcs \
  --load-balancing-scheme=INTERNAL_MANAGED \
  --protocol=HTTPS \
  --region=${REGION_1}

echo "ilb-foo-gcs: adding network endpoint group (neg-psc-gcs) to backend service (bes-foo-gcs)"
gcloud compute backend-services add-backend bes-foo-gcs \
  --network-endpoint-group=neg-psc-gcs \
  --network-endpoint-group-region=${REGION_1} \
  --region=${REGION_1}

echo "ilb-foo-gcs: creating url map (ilb-foo-gcs)"
gcloud compute url-maps create ilb-foo-gcs \
  --default-service=bes-foo-gcs \
  --region=${REGION_1}

echo "ilb-foo-gcs: creating target https proxy (proxy-foo-gcs)"
gcloud compute target-https-proxies create proxy-foo-gcs \
  --url-map=ilb-foo-gcs \
  --url-map-region=${REGION_1} \
  --certificate-manager-certificates=cert-foo-gcs \
  --region=${REGION_1}

echo "ilb-foo-gcs: creating forwarding rule (fr-foo-gcs)"
gcloud compute forwarding-rules create fr-foo-gcs \
  --load-balancing-scheme=INTERNAL_MANAGED \
  --network=vnet-foo \
  --subnet=subnet-foo-1 \
  --subnet-region=${REGION_1} \
  --address=vip-foo-gcs \
  --ports=443 \
  --target-https-proxy=proxy-foo-gcs \
  --target-https-proxy-region=${REGION_1} \
  --region=${REGION_1}

echo "--- Successfully created Load Balancer for GCS Service (ilb-foo-gcs) ---"
echo

echo "All load balancers created successfully."
EOF

# make script executable
chmod +x create_lbs.sh

# run script
./create_lbs.sh

UWAGA: wykonanie tego skryptu zajmuje kilka minut.

Sprawdzanie utworzenia systemu równoważenia obciążenia

Sprawdź, czy reguły przekierowania i usługi backendu zostały wdrożone.

# check forwarding rules
gcloud compute forwarding-rules list

# check backend services
gcloud compute backend-services list

To już koniec konfigurowania systemu równoważenia obciążenia. Teraz skonfigurujemy instancje maszyn wirtualnych klienta.

6. Dostęp klienta

Tworzenie zasobów klienta maszyny wirtualnej

W tej sekcji wdrożysz klienty i sprawdzisz łączność na całej trasie.

Tworzenie instancji maszyn wirtualnych

# set variables for client ip addresses
export VM_ALLOW_IP="10.0.0.11"
export VM_DENY_IP="10.0.0.12"
echo ${VM_ALLOW_IP}
echo ${VM_DENY_IP}

# create client 1 vm
gcloud compute instances create vm-allow \
  --machine-type=e2-micro \
  --zone=${ZONE_1} \
  --subnet=subnet-foo-1 \
  --no-address \
  --private-network-ip=${VM_ALLOW_IP} \
  --scopes=cloud-platform \
  --shielded-secure-boot

# create client 2 vm
gcloud compute instances create vm-deny \
  --machine-type=e2-micro \
  --zone=${ZONE_1} \
  --subnet=subnet-foo-1 \
  --no-address \
  --private-network-ip=${VM_DENY_IP} \
  --scopes=cloud-platform \
  --shielded-secure-boot

Testowanie usługi podstawowej

Test od klienta `vm-allow`

UWAGA: instancje maszyn wirtualnych zostaną włączone i będą dostępne przez ssh za pomocą IAP wkrótce po wydaniu poleceń instances create. Jeśli prośba nie zostanie zrealizowana za pierwszym razem, może być konieczne odczekanie chwili.

# send request to foo www service
gcloud compute ssh vm-allow --zone=${ZONE_1} --command="
  curl -s www.foo.com"

# send request to foo api service
gcloud compute ssh vm-allow --zone=${ZONE_1} --command="
  curl -s api.foo.com:8080"

Przetestuj przesyłanie pliku do Google Cloud Storage za pomocą systemu równoważenia obciążenia.

# send request to foo gcs service
gcloud compute ssh vm-allow --zone=${ZONE_1} --command="
  echo 'test one on the way' > test-upload-1.txt
  TOKEN=\$(gcloud auth print-access-token)
  curl -s -k -X POST \"https://gcs.foo.com/upload/storage/v1/b/${BUCKET}/o?uploadType=media&name=test-upload-object-1.txt\" \
  -H \"Authorization: Bearer \${TOKEN}\" \
  -H \"Content-Type: text/plain\" \
  --data-binary @test-upload-1.txt"

Odpowiedź interfejsu Cloud Storage API potwierdza, że ścieżka sieciowa działa prawidłowo.

Test od klienta `vm-deny`

# send request to foo www service
gcloud compute ssh vm-deny --zone=${ZONE_1} --command="
  curl -s www.foo.com"

# send request to foo api service
gcloud compute ssh vm-deny --zone=${ZONE_1} --command="
  curl -s api.foo.com:8080"

# send request to foo gcs service
gcloud compute ssh vm-deny --zone=${ZONE_1} --command="
  echo 'test two on the way' > test-upload-2.txt
  TOKEN=\$(gcloud auth print-access-token)
  curl -s -k -X POST \"https://gcs.foo.com/upload/storage/v1/b/${BUCKET}/o?uploadType=media&name=test-upload-object-2.txt\" \
  -H \"Authorization: Bearer \${TOKEN}\" \
  -H \"Content-Type: text/plain\" \
  --data-binary @test-upload-2.txt"

UWAGA: te testy również powinny się powieść, ponieważ żadne reguły zapory sieciowej nie są jeszcze kierowane na moduł równoważenia obciążenia.

To wszystkie główne części konfiguracji… teraz przejdziemy do tworzenia reguł zapory sieciowej systemu równoważenia obciążenia.

7. Zapora sieciowa systemu równoważenia obciążenia

W tej sekcji wdrożysz reguły zasad zapory sieciowej kierowane na systemy równoważenia obciążenia. Kolejność konfiguracji będzie prowadzić do stanu zabezpieczeń, który zezwala na dostęp do vm-allow i blokuje ruch vm-deny we wszystkich usługach.

Zezwalaj na wybrany ruch do `fr-foo-www`

Dodaj nową regułę zasad zapory sieciowej do istniejących zasad zapory sieciowej fw-policy-foo-${REGION_1}.

Zezwalaj na zakres źródłowych adresów IP, który obejmuje adresy IP vm-allow i wyklucza adresy IP vm-deny.
Dodaj dodatkowy filtr źródła INTRA_VPC, aby użyć typu sieci w regule zasady zapory sieciowej kierowanej na system równoważenia obciążenia.

W regułach zasad zapory sieciowej kierowanych na moduły równoważenia obciążenia obsługiwane są typy sieci źródłowych INTRA_VPC i VPC_NETWORKS, jeśli są używane w połączeniu z innym parametrem źródła. Logika oceny to AND między dwoma parametrami źródłowymi. W tym przypadku ruch musi spełniać kryteria INTRA_VPC i --src-ip-ranges=${VM_ALLOW_IP}/32, aby był dozwolony.

Tworzenie reguły zezwalającej na `vm-allow` kierowanie `fr-foo-www`

# create fw policy rule
gcloud beta compute network-firewall-policies rules create 2001 \
  --description="allow vm traffic to fr-www" \
  --firewall-policy=fw-policy-foo-${REGION_1} \
  --firewall-policy-region=${REGION_1} \
  --enable-logging \
  --action=allow \
  --direction=INGRESS \
  --layer4-configs=tcp \
  --src-network-type=INTRA_VPC \
  --src-ip-ranges=${VM_ALLOW_IP}/32 \
  --target-type=INTERNAL_MANAGED_LB \
  --target-forwarding-rules=projects/${PROJECT_ID}/regions/${REGION_1}/forwardingRules/fr-foo-www

Test od klienta `vm-allow`

# send request to foo www service
gcloud compute ssh vm-allow --zone=${ZONE_1} --command="
  curl -s www.foo.com"

Test od klienta `vm-deny`

# send request to foo www service
gcloud compute ssh vm-deny --zone=${ZONE_1} --command="
  curl -s www.foo.com"

UWAGA: ta operacja się powiodła, ponieważ niejawne domyślne działanie reguły zasad zapory sieciowej w przypadku modułów równoważenia obciążenia to --action=allow. Aby to zmienić, musisz mieć domyślną (ogólną) regułę odmowy.

Odrzucanie domyślnego ruchu do `fr-foo-www`

Dodaj nową regułę zasady zapory sieciowej o niższym priorytecie (wyższa liczba).

Odrzucanie całego ruchu z dowolnego źródłowego adresu IP
Ruch z vm-allow do fr-foo-www będzie dozwolony, zanim zostanie zastosowana reguła odrzucania.

Tworzenie reguły odrzucania kierowania ruchu `fr-foo-www`

# create fw policy rule
gcloud beta compute network-firewall-policies rules create 2999 \
  --description="allow vm traffic to fr-www" \
  --firewall-policy=fw-policy-foo-${REGION_1} \
  --firewall-policy-region=${REGION_1} \
  --enable-logging \
  --action=deny \
  --direction=INGRESS \
  --layer4-configs=tcp \
  --src-ip-ranges=0.0.0.0/0 \
  --target-type=INTERNAL_MANAGED_LB \
  --target-forwarding-rules=projects/${PROJECT_ID}/regions/${REGION_1}/forwardingRules/fr-foo-www

Wskazówki dotyczące kontroli stanu

Podobnie jak w przypadku reguł zasad zapory sieciowej kierowanych na instancje maszyn wirtualnych, domyślna reguła odmowy ruchu przychodzącego (niejawna) blokuje ruch pochodzący z zakresów sond kontroli stanu i kierowany do backendów systemu równoważenia obciążenia. Dlatego skonfigurowano jawną regułę zezwalającą na zakresy sond kontroli stanu ruchu przychodzącego (patrz reguła 1002).

WAŻNE: podobnie podczas tworzenia reguły ruchu przychodzącego typu „catchall” (jawnie odrzucającej) dla elementów docelowych systemu równoważenia obciążenia należy utworzyć inną regułę o wyższym priorytecie (niższym numerze), która zezwala na ruch przychodzący z zakresu sond kontroli stanu. Ta reguła musi kierować reklamy na systemy równoważenia obciążenia.

# create fw policy rule
gcloud beta compute network-firewall-policies rules create 2002 \
  --description="allow health checks to fr-www" \
  --firewall-policy=fw-policy-foo-${REGION_1} \
  --firewall-policy-region=${REGION_1} \
  --action=allow \
  --direction=INGRESS \
  --layer4-configs=tcp \
  --src-address-groups=projects/${PROJECT_ID}/locations/${REGION_1}/addressGroups/uhc-probes \
  --target-type=INTERNAL_MANAGED_LB \
  --target-forwarding-rules=projects/${PROJECT_ID}/regions/${REGION_1}/forwardingRules/fr-foo-www

Test od klienta `vm-deny`

# send request to foo www service
gcloud compute ssh vm-deny --zone=${ZONE_1} --command="
  curl -s www.foo.com"

Powinno to teraz się nie udać, ponieważ reguła zapory sieciowej 2999 odrzuca cały ruch pochodzący z sieci VPC. Reguła o wyższym priorytecie (niższa liczba priorytetu) 2001 zezwalała tylko na zakres źródłowy, który obejmuje vm-allow.

Zatrzymaj proces curl, naciskając Ctrl+C.

# send request to foo api service
gcloud compute ssh vm-deny --zone=${ZONE_1} --command="
  curl -s api.foo.com:8080"

vm-deny nadal może korzystać z usługi API. Operacja się powiodła, ponieważ reguła zapory sieciowej została zastosowana tylko do reguły przekierowania fr-foo-www i nie była kierowana na fr-foo-api.

Aktualizowanie reguł, aby obejmowały wszystkie systemy równoważenia obciążenia

UWAGA: reguły zasad zapory sieciowej można zastosować do wszystkich modułów równoważenia obciążenia w sieci VPC, pomijając --target-forwarding-rules=FR_NAME.

Zmień reguły zasad zapory sieciowej, aby były stosowane do wszystkich miejsc docelowych reguł przekierowania systemu równoważenia obciążenia w sieci VPC.

Utwórz nową regułę zezwalającą na ruch przychodzący 2003, która będzie kierowana na wszystkie reguły przekierowania, aby zezwalać na ruch maszyn wirtualnych (zakres adresów IP vm-allow).
Utwórz nową regułę zezwalającą na ruch przychodzący 2004, która jest kierowana na wszystkie reguły przekierowania, aby zezwalać na ruch kontroli stanu (grupa adresów uhc-probes).
Utwórz nową regułę odmowy dla ruchu przychodzącego 2998 kierowaną na wszystkie reguły przekazywania jako regułę odmowy typu catch-all dla całego innego ruchu.

Modyfikowanie reguł zapory sieciowej, aby były kierowane na wszystkie systemy równoważenia obciążenia

# create fw policy rule
gcloud beta compute network-firewall-policies rules create 2003 \
  --description="allow vm traffic to all vnet lb fr" \
  --firewall-policy=fw-policy-foo-${REGION_1} \
  --firewall-policy-region=${REGION_1} \
  --enable-logging \
  --action=allow \
  --direction=INGRESS \
  --layer4-configs=tcp  \
  --src-ip-ranges=${VM_ALLOW_IP}/32 \
  --target-type=INTERNAL_MANAGED_LB

# create fw policy rule
gcloud beta compute network-firewall-policies rules create 2004 \
  --description="allow health checks to all vnet lb fr" \
  --firewall-policy=fw-policy-foo-${REGION_1} \
  --firewall-policy-region=${REGION_1} \
  --enable-logging \
  --action=allow \
  --direction=INGRESS \
  --layer4-configs=tcp \
  --src-address-groups=projects/${PROJECT_ID}/locations/${REGION_1}/addressGroups/uhc-probes \
  --target-type=INTERNAL_MANAGED_LB

# create fw policy rule
gcloud beta compute network-firewall-policies rules create 2998 \
  --description="deny all vnet traffic to all vnet lb fr" \
  --firewall-policy=fw-policy-foo-${REGION_1} \
  --firewall-policy-region=${REGION_1} \
  --enable-logging \
  --action=deny \
  --direction=INGRESS \
  --layer4-configs=tcp \
  --src-ip-ranges=0.0.0.0/0 \
  --target-type=INTERNAL_MANAGED_LB

Poprzednie reguły zasad zapory sieciowej kierowane na wyraźne reguły przekazywania ruchu modułu równoważenia obciążenia można usunąć, ponieważ są one teraz zbędne w stosunku do reguł kierowanych na wszystkie reguły przekazywania ruchu w sieci VPC.

# delete redundant fw policy rules
gcloud beta compute network-firewall-policies rules delete 2001 \
  --firewall-policy=fw-policy-foo-${REGION_1} \
  --firewall-policy-region=${REGION_1}

gcloud beta compute network-firewall-policies rules delete 2002 \
  --firewall-policy=fw-policy-foo-${REGION_1} \
  --firewall-policy-region=${REGION_1}

gcloud beta compute network-firewall-policies rules delete 2999 \
  --firewall-policy=fw-policy-foo-${REGION_1} \
  --firewall-policy-region=${REGION_1}

Test od klienta `vm-deny`

# send request to foo api service
gcloud compute ssh vm-deny --zone=${ZONE_1} --command="
  curl -s api.foo.com:8080"

Powinno to się teraz nie udać, ponieważ fr-foo-api jest też celem wszystkich reguł zasad zapory sieciowej z wartością --target-type=INTERNAL_MANAGED_LB.

Zatrzymaj proces curl, naciskając Ctrl+C.

Sprawdź, czy możesz pobrać plik z Google Cloud Storage za pomocą systemu równoważenia obciążenia.

# send request to foo gcs service
gcloud compute ssh vm-deny --zone=${ZONE_1} --command="
  TOKEN=\$(gcloud auth print-access-token)
  curl -s -k \"https://gcs.foo.com/storage/v1/b/${BUCKET}/o/test-upload-object.txt?alt=media\" \
  -H \"Authorization: Bearer \${TOKEN}\" \
  -o test-download.txt"

Zatrzymaj proces curl, naciskając Ctrl+C.

Test od klienta `vm-allow`

# send request to foo www service
gcloud compute ssh vm-allow --zone=${ZONE_1} --command="
  curl -s www.foo.com"

# send request to foo api service
gcloud compute ssh vm-allow --zone=${ZONE_1} --command="
  curl -s api.foo.com:8080"

# send request to foo gcs service
gcloud compute ssh vm-allow --zone=${ZONE_1} --command="
  TOKEN=\$(gcloud auth print-access-token)
  curl -s -k \"https://gcs.foo.com/storage/v1/b/${BUCKET}/o/test-upload-object-1.txt?alt=media\" \
  -H \"Authorization: Bearer \${TOKEN}\" \
  -o test-download-1.txt"

Sprawdzanie pobranych treści

# send request from vm
gcloud compute ssh vm-allow --zone=${ZONE_1} --command="
  cat test-download-1.txt"

Wszystkie usługi systemu równoważenia obciążenia są dostępne dla vm-allow i zostały zablokowane dla vm-deny.

To koniec części testowej. Teraz krótko omówimy logowanie.

8. Logowanie reguł zapory sieciowej

Format dziennika zapory sieciowej zawiera pola i rekordy reguł, które są kierowane na systemy równoważenia obciążenia (--target-type=INTERNAL_MANAGED_LB).

Dzienniki będą zawierać dodatkowe pole oznaczone etykietą load_balancer_details z dodatkowymi informacjami o usłudze równoważenia obciążenia, do której kierowana była reguła zasady zapory sieciowej. Jest to analogiczne do formatu pola InstanceDetails, gdy w regułach zasad zapory sieciowej są kierowane na instancje maszyn wirtualnych.

load_balancer_details.forwarding_rule_name wyświetla docelową regułę przekierowania reguły zasad zapory sieciowej.
load_balancer_details.type wskazuje, która wersja systemu równoważenia obciążenia opartego na serwerze proxy jest docelowa.
load_balancer_details.url_map_name rejestruje zasób mapy URL używany, gdy typem jest system równoważenia obciążenia aplikacji.

Wyświetl logi

Wysyłaj zapytania do logów zapory sieciowej, aby zobaczyć wyniki reguł zasad zapory sieciowej.

gcloud logging read \
  "logName=projects/${PROJECT_ID}/logs/compute.googleapis.com%2Ffirewall \
  AND (jsonPayload.connection.src_ip=\"${VM_ALLOW_IP}\" OR jsonPayload.connection.src_ip=\"${VM_DENY_IP}\")" \
  --project=${PROJECT_ID} \
  --freshness=30m \
  --limit=50 \
  --format="table(
    timestamp:label=TIMESTAMP,
    jsonPayload.connection.src_ip:label=SRC_IP,
    jsonPayload.connection.src_port:label=SRC_PORT,
    jsonPayload.connection.dest_ip:label=DEST_IP,
    jsonPayload.connection.dest_port:label=DEST_PORT,
    jsonPayload.disposition:label=ACTION,
    jsonPayload.rule_details.priority:label=PRIORITY,
    jsonPayload.load_balancer_details.forwarding_rule_name:label=FWD_RULE
  )"

Dane wyjściowe logu pokazują obowiązujące reguły egzekwowane przez zasadę:

Reguła 2011 zezwala na cały ruch vm-allow do wszystkich systemów równoważenia obciążenia.
Cały ruch kierowany do systemów równoważenia obciążenia jest blokowany przez regułę 2998

TIMESTAMP                       SRC_IP     SRC_PORT  DEST_IP     DEST_PORT  ACTION   PRIORITY  FWD_RULE
YYYY-MM-DDTHH:MM:SS.850967068Z  10.0.0.11  48480     10.0.0.103  443        ALLOWED  2003      fr-foo-gcs
YYYY-MM-DDTHH:MM:SS.418613380Z  10.0.0.11  37340     10.0.0.101  80         ALLOWED  2003      fr-foo-www
YYYY-MM-DDTHH:MM:SS.213234118Z  10.0.0.12  55950     10.0.0.103  443        DENIED   2998      fr-foo-gcs
YYYY-MM-DDTHH:MM:SS.981484412Z  10.0.0.11  41738     10.0.0.101  80         ALLOWED  2003      fr-foo-www
YYYY-MM-DDTHH:MM:SS.189358071Z  10.0.0.12  55950     10.0.0.103  443        DENIED   2998      fr-foo-gcs
YYYY-MM-DDTHH:MM:SS.061463883Z  10.0.0.12  55950     10.0.0.103  443        DENIED   2998      fr-foo-gcs
YYYY-MM-DDTHH:MM:SS.965498098Z  10.0.0.12  53284     10.0.0.102  8080       DENIED   2998      fr-foo-api

Logi można też wyświetlać w konsoli Google Cloud za pomocą Eksploratora logów. Otwórz console.cloud.google.com/logs/query i użyj standardowego dziennika zapory sieciowej VPC compute.googleapis.com/firewall.

logName=projects/${PROJECT_ID}/logs/compute.googleapis.com%2Ffirewall

To koniec rejestrowania… czas na porządki!

9. Czyszczenie

# delete client compute resources
gcloud -q compute instances delete vm-deny --zone=${ZONE_1}

gcloud -q compute instances delete vm-allow --zone=${ZONE_1}

# next

# delete load balancer resources for gcs
gcloud -q compute forwarding-rules delete fr-foo-gcs --region=${REGION_1}

gcloud -q compute target-https-proxies delete proxy-foo-gcs --region=${REGION_1}

gcloud -q compute url-maps delete ilb-foo-gcs --region=${REGION_1}

gcloud -q compute backend-services delete bes-foo-gcs --region=${REGION_1}

gcloud -q compute addresses delete vip-foo-gcs --region=${REGION_1}

# next

# delete load balancer resources for api
gcloud -q compute forwarding-rules delete fr-foo-api --region=${REGION_1}

gcloud -q compute target-http-proxies delete proxy-foo-api --region=${REGION_1}

gcloud -q compute url-maps delete ilb-foo-api --region=${REGION_1}

gcloud -q compute backend-services delete bes-foo-api --region=${REGION_1}

gcloud -q compute health-checks delete hc-foo-api --region=${REGION_1}

gcloud -q compute addresses delete vip-foo-api --region=${REGION_1}

# next

# delete load balancer resources for www
gcloud -q compute forwarding-rules delete fr-foo-www --region=${REGION_1}

gcloud -q compute target-http-proxies delete proxy-foo-www --region=${REGION_1}

gcloud -q compute url-maps delete ilb-foo-www --region=${REGION_1}

gcloud -q compute backend-services delete bes-foo-www --region=${REGION_1}

gcloud -q compute health-checks delete hc-foo-www --region=${REGION_1}

gcloud -q compute addresses delete vip-foo-www --region=${REGION_1}

# next

# delete service backend resources
gcloud -q storage rm --recursive gs://${BUCKET}

gcloud -q certificate-manager certificates delete cert-foo-gcs --location=${REGION_1}

gcloud -q compute network-endpoint-groups delete neg-psc-gcs --region=${REGION_1}

gcloud -q compute instance-groups managed delete mig-foo --region=${REGION_1}

gcloud -q compute instance-templates delete mig-template-foo --global

# next

# delete dns, nat, fw resources
gcloud -q dns record-sets delete gcs.foo.com --type=A --zone=zone-foo

gcloud -q dns record-sets delete api.foo.com --type=A --zone=zone-foo

gcloud -q dns record-sets delete www.foo.com --type=A --zone=zone-foo

gcloud -q dns managed-zones delete zone-foo

gcloud -q compute routers delete cr-nat-foo --region=${REGION_1}

gcloud -q compute network-firewall-policies associations delete \
  --firewall-policy=fw-policy-foo-${REGION_1} \
  --name=fw-policy-association-foo-${REGION_1} \
  --firewall-policy-region=${REGION_1}

gcloud -q compute network-firewall-policies delete fw-policy-foo-${REGION_1} --region=${REGION_1}

gcloud -q network-security address-groups delete uhc-probes --location=${REGION_1}

# next

# delete network resources
gcloud -q compute networks subnets delete subnet-foo-3 --region=${REGION_1}

gcloud -q compute networks subnets delete subnet-foo-2 --region=${REGION_1}

gcloud -q compute networks subnets delete subnet-foo-1 --region=${REGION_1}

gcloud -q compute networks delete vnet-foo

# next

# delete shell variables and local files
unset PROJECT_ID REGION_1 ZONE_1 VM_ALLOW_IP VM_DENY_IP BUCKET

rm vm-server-startup.sh create_lbs.sh foo-gcs-key.pem foo-gcs-cert.pem

# end

10. Podsumowanie

Gratulacje! Udało Ci się skonfigurować Cloud NGFW Essentials dla systemów równoważenia obciążenia.

Jeśli masz jakieś uwagi, pytania lub poprawki, możesz je przesłać za pomocą tego formularza opinii.

Dziękujemy!

Cloud NGFW Essentials for Load Balancers

1. Wprowadzenie

Czego się dowiesz

Wymagania

2. Pojęcia

Poziomy funkcji zapory sieciowej

Filtrowanie w płaszczyźnie danych

Cele systemu równoważenia obciążenia

Sieć Codelabs

3. Konfigurowanie projektu

Dostęp do projektu

Ustawianie identyfikatora projektu

Włączanie usług API

Ustawianie zmiennych środowiskowych powłoki

4. Podstawa sieci

Tworzenie zasobów sieciowych

Tworzenie komponentów zapory sieciowej

Utwórz grupę adresów

Utwórz zasadę zapory sieciowej

Konfigurowanie usług sieciowych

Tworzenie routera Cloud Router i bramy NAT

Rezerwowanie adresów IP

Tworzenie rekordów DNS

5. Usługi systemu równoważenia obciążenia

Konfigurowanie zasobów backendu

Tworzenie serwerów w grupie instancji maszyn wirtualnych

Utwórz zasobnik na dane

Utwórz certyfikat

Tworzenie komponentów systemu równoważenia obciążenia

Wdrażanie skryptu tworzenia systemu równoważenia obciążenia

Sprawdzanie utworzenia systemu równoważenia obciążenia

6. Dostęp klienta

Tworzenie zasobów klienta maszyny wirtualnej

Tworzenie instancji maszyn wirtualnych

Testowanie usługi podstawowej

Test od klienta vm-allow

Test od klienta vm-deny

7. Zapora sieciowa systemu równoważenia obciążenia

Zezwalaj na wybrany ruch do fr-foo-www

Tworzenie reguły zezwalającej na vm-allow kierowanie fr-foo-www

Test od klienta vm-allow

Test od klienta vm-deny

Odrzucanie domyślnego ruchu do fr-foo-www

Tworzenie reguły odrzucania kierowania ruchu fr-foo-www

Wskazówki dotyczące kontroli stanu

Test od klienta vm-deny

Aktualizowanie reguł, aby obejmowały wszystkie systemy równoważenia obciążenia

Modyfikowanie reguł zapory sieciowej, aby były kierowane na wszystkie systemy równoważenia obciążenia

Test od klienta vm-deny

Test od klienta vm-allow

8. Logowanie reguł zapory sieciowej

Wyświetl logi

9. Czyszczenie

10. Podsumowanie

Test od klienta `vm-allow`

Test od klienta `vm-deny`

Zezwalaj na wybrany ruch do `fr-foo-www`

Tworzenie reguły zezwalającej na `vm-allow` kierowanie `fr-foo-www`

Test od klienta `vm-allow`

Test od klienta `vm-deny`

Odrzucanie domyślnego ruchu do `fr-foo-www`

Tworzenie reguły odrzucania kierowania ruchu `fr-foo-www`

Test od klienta `vm-deny`

Test od klienta `vm-deny`

Test od klienta `vm-allow`