Lab: Troubleshooting VPC
Objetivo do Lab
Este lab coloca você no papel de um administrador cloud que precisa diagnosticar e resolver problemas de conectividade de rede. Você irá analisar cenários reais e propor soluções.
Este lab é baseado na análise de cenários. Você deve identificar o problema e propor a solução antes de olhar a resposta.
Parte 1: Estudo de Caso
Arquitetura de Referência
Todas as perguntas se baseiam nesta arquitetura:
┌─────────────────────────────────────────────────────────────────────────┐
│ ARQUITETURA E-COMMERCE │
├─────────────────────────────────────────────────────────────────────────┤
│ │
│ INTERNET │
│ │ │
│ ┌──────▼──────┐ │
│ │ IGW │ │
│ │ igw-abc123 │ │
│ └──────┬──────┘ │
│ │ │
│ ┌──────────────────────────────┼──────────────────────────────┐ │
│ │ VPC │ (10.0.0.0/16) │ │
│ │ │ │ │
│ │ ┌──────────────────────────┴────────────────────────────┐ │ │
│ │ │ SUBNET PÚBLICA │ │ │
│ │ │ 10.0.1.0/24 │ │ │
│ │ │ rtb-public │ │ │
│ │ │ │ │ │
│ │ │ ┌─────────────────┐ ┌─────────────────┐ │ │ │
│ │ │ │ BASTION │ │ NAT Gateway │ │ │ │
│ │ │ │ 10.0.1.10 │ │ 10.0.1.50 │ │ │ │
│ │ │ │ sg-bastion │ │ nat-xyz789 │ │ │ │
│ │ │ │ IP: 52.1.2.3 │ │ EIP: 52.4.5.6 │ │ │ │
│ │ │ └─────────────────┘ └─────────────────┘ │ │ │
│ │ │ │ │ │
│ │ └────────────────────────────────────────────────────────┘ │ │
│ │ │ │
│ │ ┌────────────────────────────────────────────────────────┐ │ │
│ │ │ SUBNET PRIVADA APP │ │ │
│ │ │ 10.0.11.0/24 │ │ │
│ │ │ rtb-private │ │ │
│ │ │ │ │ │
│ │ │ ┌─────────────────┐ ┌─────────────────┐ │ │ │
│ │ │ │ WEB SERVER │ │ API SERVER │ │ │ │
│ │ │ │ 10.0.11.20 │ │ 10.0.11.30 │ │ │ │
│ │ │ │ sg-web │ │ sg-api │ │ │ │
│ │ │ └─────────────────┘ └─────────────────┘ │ │ │
│ │ │ │ │ │
│ │ └────────────────────────────────────────────────────────┘ │ │
│ │ │ │
│ │ ┌────────────────────────────────────────────────────────┐ │ │
│ │ │ SUBNET PRIVADA DB │ │ │
│ │ │ 10.0.21.0/24 │ │ │
│ │ │ rtb-database │ │ │
│ │ │ │ │ │
│ │ │ ┌─────────────────┐ │ │ │
│ │ │ │ DATABASE │ │ │ │
│ │ │ │ 10.0.21.10 │ │ │ │
│ │ │ │ sg-database │ │ │ │
│ │ │ │ MySQL:3306 │ │ │ │
│ │ │ └─────────────────┘ │ │ │
│ │ │ │ │ │
│ │ └────────────────────────────────────────────────────────┘ │ │
│ │ │ │
│ └───────────────────────────────────────────────────────────────┘ │
│ │
└──────────────────────────────────────────────────────────────────────────┘
Configuração Atual
Route Tables:
rtb-public:
┌─────────────────────┬───────────────┐
│ Destination │ Target │
├─────────────────────┼───────────────┤
│ 10.0.0.0/16 │ local │
│ 0.0.0.0/0 │ igw-abc123 │
└─────────────────────┴───────────────┘
rtb-private:
┌─────────────────────┬───────────────┐
│ Destination │ Target │
├─────────────────────┼───────────────┤
│ 10.0.0.0/16 │ local │
│ 0.0.0.0/0 │ nat-xyz789 │
└─────────────────────┴───────────────┘
rtb-database:
┌─────────────────────┬───────────────┐
│ Destination │ Target │
├─────────────────────┼───────────────┤
│ 10.0.0.0/16 │ local │
└─────────────────────┴───────────────┘
Security Groups:
sg-bastion:
┌────────────────────────────────────────────────────┐
│ Inbound: SSH (22) from 0.0.0.0/0 │
│ Outbound: All traffic to 0.0.0.0/0 │
└────────────────────────────────────────────────────┘
sg-web:
┌────────────────────────────────────────────────────┐
│ Inbound: HTTP (80) from 0.0.0.0/0 │
│ Inbound: SSH (22) from sg-bastion │
│ Outbound: All traffic to 0.0.0.0/0 │
└────────────────────────────────────────────────────┘
sg-api:
┌────────────────────────────────────────────────────┐
│ Inbound: TCP (8080) from sg-web │
│ Inbound: SSH (22) from sg-bastion │
│ Outbound: All traffic to 0.0.0.0/0 │
└────────────────────────────────────────────────────┘
sg-database:
┌────────────────────────────────────────────────────┐
│ Inbound: MySQL (3306) from sg-api │
│ Outbound: All traffic to 0.0.0.0/0 │
└────────────────────────────────────────────────────┘
Parte 2: Exercícios de Troubleshooting
Exercício 1: SSH para o Bastion
Sintoma: Um administrador não consegue se conectar via SSH ao bastion a partir de sua estação de trabalho (IP: 203.0.113.50).
$ ssh -i key.pem ec2-user@52.1.2.3
Connection timed out
Perguntas:
- Qual é o problema mais provável?
- Qual comando você usaria para verificar?
- Qual é a solução?
💡 Solução Exercício 1
Análise:
O Security Group sg-bastion permite SSH de 0.0.0.0/0, então não é esse o problema.
Vamos verificar:
- ✅ Route Table rtb-public tem rota para IGW
- ✅ IGW está anexado
- ❓ O bastion tem um IP público?
Verificação:
aws ec2 describe-instances --instance-id i-bastion \
--query 'Reservations[].Instances[].PublicIpAddress'
Problema provável: O bastion não tem IP público ou o IP mudou após um reboot.
Solução:
# Opção 1: Associar uma Elastic IP
aws ec2 allocate-address --domain vpc
aws ec2 associate-address --instance-id i-bastion --allocation-id eipalloc-xxx
# Opção 2: Ativar auto-assign public IP no subnet
Exercício 2: Web Server Inacessível
Sintoma: O site não está acessível a partir da Internet.
$ curl http://10.0.11.20
curl: (7) Failed to connect to 10.0.11.20 port 80: No route to host
Perguntas:
- Por que o admin está usando o IP privado a partir da Internet?
- Qual é o verdadeiro problema de arquitetura aqui?
- Como a arquitetura deveria ser configurada?
💡 Solução Exercício 2
Análise:
O Web Server está em um subnet privado (10.0.11.0/24)!
Problemas identificados:
- O admin está tentando acessar um IP privado da Internet (impossível)
- O web server não tem IP público
- Mesmo com IP público, não há rota IGW para esse subnet
Arquitetura incorreta: Um servidor web destinado ao público não deveria estar em um subnet privado.
Soluções possíveis:
Opção A (Recomendada): Adicionar um Load Balancer
Internet → ALB (subnet público) → Web Server (subnet privado)
Opção B: Mover o Web Server para o subnet público
Internet → IGW → Web Server (subnet público com IP público)
Para Opção A:
- Criar um Application Load Balancer no subnet público
- Configurar um Target Group com o web server
- Atualizar sg-web para aceitar tráfego do sg-alb
Exercício 3: API não consegue acessar o Database
Sintoma: O servidor de API não consegue conectar ao MySQL.
$ mysql -h 10.0.21.10 -u app -p
ERROR 2003 (HY000): Can't connect to MySQL server on '10.0.21.10' (110)
Perguntas:
- Liste todas as causas possíveis.
- Como verificar cada hipótese?
- Qual é a causa mais provável dada a configuração?
💡 Solução Exercício 3
Hipóteses e verificações:
| Hipótese | Verificação | Resultado |
|---|---|---|
| SG API → DB | sg-database permite sg-api? | ❌ Permite sg-api |
| Rota | Rota local existe? | ✅ Sim (10.0.0.0/16 → local) |
| MySQL rodando | Serviço MySQL iniciado? | A verificar |
| Porta escutando | MySQL ouvindo em 0.0.0.0:3306? | A verificar |
Problema identificado:
Olhando sg-database:
Inbound: MySQL (3306) from sg-api
Está correto. Mas olhando sg-api:
Inbound: TCP (8080) from sg-web
O sg-api não tem acesso de saída explícito para MySQL? Não, ele tem Outbound: All traffic, então está OK.
Verificação adicional: O API server está realmente associado ao sg-api?
aws ec2 describe-instances --filters "Name=private-ip-address,Values=10.0.11.30" \
--query 'Reservations[].Instances[].SecurityGroups'
Causa provável: O API server pode não estar associado ao Security Group correto!
Exercício 4: Web Server não consegue instalar pacotes
Sintoma: O web server não consegue executar yum update.
$ sudo yum update
Loaded plugins: priorities, update-motd, upgrade-helper
Could not retrieve mirrorlist https://... error was
12: Timeout on ...
Perguntas:
- Por que o servidor não consegue acessar a Internet?
- Verifique a configuração de rede.
- Proponha a solução.
💡 Solução Exercício 4
Análise:
O Web Server está no subnet privado (10.0.11.0/24) que usa rtb-private.
rtb-private:
10.0.0.0/16 → local
0.0.0.0/0 → nat-xyz789
A rota para o NAT Gateway existe! Vamos verificar:
Checklist NAT Gateway:
- NAT Gateway está no estado "available"?
aws ec2 describe-nat-gateways --nat-gateway-ids nat-xyz789
-
NAT Gateway está em um subnet com IGW?
- NAT está em 10.0.1.0/24 (público) ✅
-
NAT Gateway tem uma Elastic IP?
- EIP: 52.4.5.6 ✅
-
O subnet público tem rota para IGW?
- 0.0.0.0/0 → igw-abc123 ✅
Se tudo está OK do lado do NAT, verificar:
-
Security Group do NAT Gateway?
- NAT Gateway não tem SG (é um serviço gerenciado)
-
NACL do subnet privado permite saída?
Causa provável: NACL restritivo no subnet privado bloqueando tráfego de saída ou portas efêmeras de entrada.
Solução:
# Verificar a NACL
aws ec2 describe-network-acls \
--filters "Name=association.subnet-id,Values=subnet-private"
# Garantir que as regras permitem:
# Outbound: 0.0.0.0/0 (todo o tráfego)
# Inbound: portas efêmeras 1024-65535 (para respostas)
Exercício 5: Database não recebe conexões
Sintoma: Após corrigir o exercício 3, o log do DB mostra 0 conexões.
Configuração adicional revelada:
NACL do subnet database (acl-db):
┌────────┬──────────┬───────────┬─────────────┬────────┐
│ Rule # │ Type │ Port │ Source/Dest │ Action │
├────────┼──────────┼───────────┼─────────────┼────────┤
│ 100 │ Inbound │ 3306 │ 10.0.1.0/24 │ ALLOW │
│ * │ Inbound │ All │ 0.0.0.0/0 │ DENY │
├────────┼──────────┼───────────┼─────────────┼────────┤
│ 100 │ Outbound │ 1024-65535│ 10.0.1.0/24 │ ALLOW │
│ * │ Outbound │ All │ 0.0.0.0/0 │ DENY │
└────────┴──────────┴───────────┴─────────────┴────────┘
Perguntas:
- Qual é o problema com essa NACL?
- Por que as conexões da API estão sendo bloqueadas?
- Corrija a NACL.
💡 Solução Exercício 5
Problema:
A NACL permite tráfego MySQL (3306) apenas de 10.0.1.0/24 (subnet público).
Mas o API server está em 10.0.11.0/24 (subnet privado app)!
Rule 100 Inbound: 3306 from 10.0.1.0/24 → Não inclui 10.0.11.0/24
Solução:
# Adicionar uma regra para o subnet app
aws ec2 create-network-acl-entry \
--network-acl-id acl-db \
--rule-number 110 \
--protocol tcp \
--port-range From=3306,To=3306 \
--cidr-block 10.0.11.0/24 \
--rule-action allow \
--ingress
# Adicionar a regra outbound correspondente
aws ec2 create-network-acl-entry \
--network-acl-id acl-db \
--rule-number 110 \
--protocol tcp \
--port-range From=1024,To=65535 \
--cidr-block 10.0.11.0/24 \
--rule-action allow \
--egress
Lição: As NACLs são stateless e muito precisas quanto a fontes/destinos.
Parte 3: Exercício de Síntese
Sua Missão
Documente um procedimento de troubleshooting completo para sua equipe.
Crie um documento com:
-
Fluxograma de diagnóstico: Árvore de decisão para problemas comuns
-
Comandos de verificação: Lista dos comandos essenciais do AWS CLI
-
Checklist rápida: Lista de verificação para cada tipo de problema
-
Lições aprendidas: Erros comuns e como evitá-los
Template de Entregável
# Procedimento de Troubleshooting de Rede VPC
## 1. Fluxograma de Diagnóstico
[Insira seu diagrama]
## 2. Comandos de Verificação
### Estado das instâncias
```bash
[Seus comandos]
Security Groups
[Seus comandos]
Rotas
[Seus comandos]
3. Checklist por Sintoma
Timeout da Internet
- ...
- ...
Timeout para a Internet
- ...
- ...
4. Lições Aprendidas
| Erro Comum | Como Evitar |
|---|---|
| ... | ... |
## Critérios de Avaliação
| Critério | Pontos |
|----------|--------|
| Exercícios 1-5 corretamente analisados | /50 |
| Fluxograma claro e completo | /15 |
| Comandos pertinentes | /15 |
| Checklist utilizável | /10 |
| Lições aprendidas relevantes | /10 |
| **Total** | **/100** |
---
*Próxima semana: [Publicação Web](../module_07/index.mdx)*