1. Introdução
Rotas com base em políticas
Com as rotas com base em políticas, é possível escolher um próximo salto com base em mais do que o endereço IP de destino de um pacote. Também é possível corresponder o tráfego por protocolo e endereço IP de origem. O tráfego correspondente é redirecionado para um balanceador de carga de rede interna. Isso pode ajudar você a inserir dispositivos, como firewalls, no caminho de tráfego de rede.
Ao criar uma rota com base na política, você seleciona quais recursos podem ter o tráfego processado pela rota. A rota pode ser aplicada a estes casos:
- Toda a rede: todas as instâncias de máquina virtual (VM), gateways VPN e interconexões
- Usar tags de rede: selecione instâncias de VM na VPC
- Região da interconexão: todo o tráfego que entra na rede VPC por meio de anexos da VLAN para a região
O próximo salto de uma rota com base em políticas precisa ser um balanceador de carga de rede interno válido que está na mesma rede VPC que a rota com base em políticas.
Por padrão, os balanceadores de carga de rede internos usam hash simétrico para que o tráfego possa alcançar o mesmo dispositivo nos caminhos de saída e retorno sem configurar o NAT de origem.
As rotas com base em políticas têm prioridade mais alta que outros tipos de rota, exceto caminhos de retorno especiais.
Se duas rotas com base na política tiverem a mesma prioridade, o Google Cloud usará um algoritmo interno determinístico para selecionar uma única rota com base na política, ignorando outras com a mesma prioridade. As rotas baseadas em políticas não usam a correspondência de prefixo mais longo e selecionam apenas a rota de prioridade mais alta.
É possível criar uma única regra para o tráfego unidirecional ou várias regras para lidar com o tráfego bidirecional.
Para usar rotas com base em políticas com o Cloud Interconnect, a rota precisa ser aplicada a todas as conexões do Cloud Interconnect em uma região inteira. Não é possível aplicar rotas com base na política a uma única conexão do Cloud Interconnect.
As instâncias de VM que recebem tráfego de uma rota com base na política precisam estar com o encaminhamento de IP ativado.
Considerações sobre a PBR
Uma configuração especial é necessária para usar rotas baseadas em políticas das seguintes maneiras.
Por exemplo, usando PBR com GKE, PSC ou com PGA/PSA.
Confira mais detalhes sobre o PBR com o GKE neste link e a seção de limitações gerais do PBR aqui.
O que você vai aprender
- Como configurar rotas com base em políticas
O que é necessário
- Conhecimento sobre como implantar instâncias e configurar componentes de rede
- Conhecimento sobre a configuração de firewall da VPC
2. Ambiente de teste
Este codelab vai usar uma única VPC. Haverá dois recursos de computação, clienta e clientb, nesse ambiente que enviarão pacotes para outro recurso de servidor. Usando PBR e filtros, vamos forçar o tráfego de clienta por outro recurso de computação para aplicação de firewall, enquanto o tráfego de clientb vai direto para o servidor. O diagrama abaixo ilustra o caminho.
No diagrama acima, tecnicamente, há um ILB (balanceador de carga interno de rede) para caminhos de PBR. Isso foi omitido para simplificar o diagrama.
3. Antes de começar
O codelab exige um único projeto.
No 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. Ativar APIs
Se ainda não tiver feito isso, ative as APIs para usar os produtos.
No Cloud Shell:
gcloud services enable compute.googleapis.com gcloud services enable networkconnectivity.googleapis.com
5. Criar rede e sub-rede VPC
Rede VPC
Crie a VPC codelab-pbr-vpc:
No Cloud Shell:
gcloud compute networks create $prefix-vpc --subnet-mode=custom
Sub-rede
Crie as respectivas sub-redes na região selecionada:
No Cloud Shell:
gcloud compute networks subnets create $prefix-vpc-subnet \
--range=10.10.10.0/24 --network=$prefix-vpc --region=${region}
6. Criar regras de firewall
Para permitir que o IAP se conecte às suas instâncias de VM, crie uma regra de firewall que:
- Aplica-se a todas as instâncias de VM que você quer acessar usando o IAP.
- Permite o tráfego de entrada do intervalo de IP 35.235.240.0/20. Esse intervalo contém todos os endereços IP que o IAP usa para o encaminhamento de TCP.
No 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
Para permitir a porta HTTP padrão (TCP 80) e o protocolo ICMP no servidor:
- Aplicável a recursos com a tag de rede "server"
- Permite a entrada de todas as fontes
No 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
Para permitir que o firewall receba pacotes, permita uma entrada em todos os protocolos e portas.
- Aplicável a recursos com a tag de rede "fw"
- Permite entrada de fontes 10.10.10.0/24
No 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
Para permitir as sondagens de verificação de integridade
- Aplicável a recursos com a tag de rede "fw"
- Permite a entrada de intervalos de verificação de integridade.
No 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. Criar Cloud Router e Cloud NAT
O objetivo desta seção é permitir que as máquinas virtuais particulares façam o download dos pacotes de software adequados da Internet.
Criar Cloud Router
No Cloud Shell:
gcloud compute routers create ${prefix}-cr \
--region=${region} \
--network=${prefix}-vpc
Criar gateway do Cloud NAT
No 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. Criar instâncias de computação
Crie as instâncias de computação ClientA, ClientB, FW e Server:
No 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'
No 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'
No 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'
No 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. Testar a conectividade sem PBR
Use SSH nas VMs de computação do cliente que criamos recentemente e verifique a conectividade de ambos os clientes com o servidor.
No cloudshell1, faça login no clienta:
gcloud compute ssh clienta --zone=$zone --tunnel-through-iap
Execute os comandos a seguir:
ping 10.10.10.200 -c 5
curl 10.10.10.200/index.html
Os pings e as solicitações curl devem ser bem-sucedidos.
Saída:
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>
Clique no + para abrir outra guia do Cloud Shell.
No cloudshell2, defina variáveis para uso:
export project_id=`gcloud config list --format="value(core.project)"` export region=us-central1 export zone=us-central1-a export prefix=codelab-pbr
No cloudshell2, faça SSH para clientb:
gcloud compute ssh clientb --zone=$zone --tunnel-through-iap
Execute os comandos a seguir:
ping 10.10.10.200 -c 5
curl 10.10.10.200/index.html
Os pings e as solicitações curl devem ser bem-sucedidos.
Saída:
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>
Agora saia do terminal da VM e volte ao Cloud Shell.
10. Criar um grupo de instâncias
Crie um grupo de instâncias não gerenciadas para sua VM de firewall.
No Cloud Shell:
gcloud compute instance-groups unmanaged create pbr-uig --zone=$zone
Adicione a instância fw ao grupo de instâncias não gerenciadas.
No Cloud Shell:
gcloud compute instance-groups unmanaged add-instances pbr-uig --instances=fw --zone=$zone
11. Criar verificação de integridade
Crie uma verificação de integridade para o serviço de back-end. Vamos fazer uma verificação de integridade simples da porta TCP 80.
No Cloud Shell:
gcloud compute health-checks create tcp $prefix-hc-tcp-80 --region=$region --port 80
12. Criar um serviço de back-end
Crie um serviço de back-end para anexar à regra de encaminhamento.
No 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
Agora adicione o grupo de instâncias ao serviço de back-end.
No Cloud Shell:
gcloud compute backend-services add-backend be-pbr --region=$region --instance-group=pbr-uig --instance-group-zone=$zone
13. Criar uma regra de encaminhamento
No 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. Criar regra de PBR
Essa regra de PBR se aplica aos clientes. Ele vai rotear todo o tráfego IPv4 para a regra de encaminhamento 10.10.10.25 se o IP de origem for 10.10.10.10/32 (endereço de clienta) e o IP de destino for 10.10.10.0/24.
Isso significa que clienta vai corresponder ao PBR e não ao clientb.
No 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
Essa regra de PBR se aplica ao servidor. Ele vai rotear todo o tráfego IPv4 para a regra de encaminhamento 10.10.10.25 se o IP de origem for 10.10.10.200/32 e o IP de destino for 10.10.10.10/32.
No 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. Testar a conectividade com PBR
Agora vamos verificar a funcionalidade de PBR. A instância "fw" é configurada com iptables para rejeitar solicitações destinadas ao servidor. Se o PBR estiver funcionando, as solicitações que funcionavam antes no clienta vão falhar, enquanto o clientb ainda vai funcionar.
Use SSH em uma VM de computação clienta e execute os mesmos testes.
No cloudshell1:
gcloud compute ssh clienta --zone=$zone --tunnel-through-iap
Execute os comandos a seguir:
ping 10.10.10.200 -c 5
curl 10.10.10.200/index.html
Saída:
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
Como as solicitações falharam, podemos confirmar que a PBR está roteando ativamente o tráfego do cliente para a instância do firewall, que foi configurada para bloquear esse tráfego.
Acesse o clientb por SSH e execute o mesmo teste de conectividade.
No cloudshell2:
gcloud compute ssh clientb --zone=$zone --tunnel-through-iap
Execute os comandos a seguir:
ping 10.10.10.200 -c 5
curl 10.10.10.200/index.html
Saída:
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>
Como você pode ver, as solicitações do clientb para o servidor são bem-sucedidas. Isso acontece porque as solicitações não correspondem a uma regra de PBR para o IP de origem.
16. [Opcional] Validação com capturas no firewall
Nesta seção opcional, você pode validar a PBR fazendo capturas de pacotes na VM de firewall.
Você ainda precisa ter uma conexão SSH em cloudshell1 e cloudshell2 com clienta e clientb.
Clique no + para abrir outra guia do Cloud Shell.
No cloudshell3, defina as variáveis:
export project_id=`gcloud config list --format="value(core.project)"` export region=us-central1 export zone=us-central1-a export prefix=codelab-pbr
Execute SSH em fw:
gcloud compute ssh fw --zone=$zone --tunnel-through-iap
Execute o comando a seguir em fw (cloudshell3):
sudo tcpdump -i any icmp -nn
No clienta (cloudshell1), execute o teste de ping:
ping 10.10.10.200 -c 5
No clientb (cloudshell2), execute o teste de ping:
ping 10.10.10.200 -c 5
Saída em 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
Você não verá pacotes no tcpdump do clientb (10.10.10.11) porque a PBR não é aplicável.
Saia e volte para o Cloud Shell para limpar os recursos.
17. Etapas de limpeza
No Cloud Shell, remova a regra de PBR, a regra de encaminhamento, o serviço de back-end, a verificação de integridade, o grupo de instâncias, as instâncias de computação, o NAT, o Cloud Router e as regras de firewall.
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
Remova a sub-rede e as VPCs:
gcloud -q compute networks subnets delete $prefix-vpc-subnet \
--region $region
gcloud -q compute networks delete $prefix-vpc
18. Parabéns!
Parabéns por concluir o codelab.
O que aprendemos
- Rotas com base em políticas