Diagnosticar e Solucionar Problemas Básicos de Rede no Oracle Cloud Infrastructure

Introdução

Na Oracle Cloud Infrastructure (OCI), diagnosticar problemas de conectividade de rede requer visibilidade da configuração e do fluxo de tráfego em vários componentes. As ferramentas do OCI Network Command Center, como Network Visualizer, Network Path Analyzer e Logs de Fluxo da VCN, fornecem insights profundos sobre o layout, o roteamento e o comportamento do fluxo dos recursos de rede. Essas ferramentas permitem a identificação rápida de configurações incorretas, rotas ausentes e falhas de comunicação em redes virtuais na nuvem (VCNs), sub-redes e gateways em um ambiente de rede da OCI.

Neste tutorial, vamos nos concentrar em técnicas fundamentais de solução de problemas para problemas comuns de conectividade. Embora demonstre como usar efetivamente essas ferramentas para simplificar a solução de problemas e resolver problemas com eficiência, o objetivo também é desenvolver uma compreensão mais ampla de como abordar e analisar os desafios de conectividade, não apenas como usar as próprias ferramentas.

Objetivos

Use a ferramenta Visualizador de Rede para explorar o layout de rede nos níveis regional, VCN e sub-rede.
Analise os caminhos de fluxo de tráfego usando a ferramenta Network Path Analyzer para entender como os pacotes atravessam a rede e identificar falhas.
Interprete a ferramenta Logs de Fluxo da VCN para inspecionar registros de fluxo de tráfego e detectar problemas de conectividade ou comportamento incomum.
Identifique e solucione problemas de configurações incorretas de rede, rotas ausentes e falhas de comunicação.

Pré-requisitos

Você está familiarizado com componentes básicos de rede do OCI, como VCN, sub-redes, gateways, listas de segurança e tabelas de roteamento.
Você tem acesso a uma tenancy do OCI com recursos de rede configurados.
Sua conta de usuário exigiu políticas do Oracle Cloud Infrastructure Identity and Access Management (OCI IAM) para gerenciar componentes da VCN, também para usar o Visualizador de Rede, o Analisador de Caminho de Rede e Logs de Fluxo da VCN.

Se você quiser acompanhar alguns dos próximos exemplos, execute os comandos a seguir na sua máquina virtual (vM) Oracle Linux de teste para criar um site simples do Apache.

sudo dnf install httpd --assumeyes
sudo systemctl enable httpd
sudo systemctl start httpd
sudo firewall-offline-cmd --add-service=http
sudo systemctl restart firewalld
sudo vi /var/www/html/index.html

'<!doctype html><html><body><h1>Test Apache Website.. it's reachable!</h1></body></html>'

Tarefa 1: Exibir sua Configuração de Rede com o Visualizador de Rede

Antes de começar a investigar o que está quebrado, ajuda a dar um passo atrás e obter uma visão clara do seu ambiente de rede. O Visualizador de Rede na OCI oferece uma representação gráfica da topologia da sua VCN. Embora não solucione problemas diretamente, ele fornece uma visão clara e consolidada de toda a sua arquitetura de rede em um compartimento específico que você escolher.

Esse contexto visual mostra como tudo está conectado (VCNs, sub-redes, gateways, tabelas de roteamento, listas de segurança), tudo em um só lugar. Isso facilita a identificação de qualquer coisa que pareça diferente, como uma rota ausente ou uma VCN que não esteja associada a um Gateway de Roteamento Dinâmico (DRG). Em configurações complexas, isso pode poupar muitas suposições. Nem sempre é uma correção, mas é um primeiro passo sólido que pode apontá-lo na direção certa antes de entrar nos detalhes.

Para este tutorial, resumimos como o Visualizador de Rede funciona no diagrama a seguir. Para obter mais informações, consulte Visualizador de Rede.

Exemplo

Usaremos a arquitetura a seguir como nosso exemplo.

Neste exemplo, dois problemas surgiram no ambiente. Veremos como o Visualizador de Rede ajuda a identificá-los e resolvê-los.

Problema 1: VM-1 não pode executar ping em VM-2.
Problema 2: VM-2 não pode acessar a Internet.

Vamos fazer um tour rápido pelo nosso ambiente de rede usando o Visualizador de Rede na Console do OCI, que deve refletir a arquitetura.

Primeiro Nível: Topologia de Rede Regional

Essa topologia inclui DRGs, VCNs, CPEs e vários tipos de gateways.

Faça log-in na Console do OCI.
1. Certifique-se de estar na região certa.
2. Clique no menu de hambúrguer (≡) no canto superior esquerdo.
3. Clique em Networking.
4. Clique em Visualizador de rede.

Esta é a primeira exibição que você verá quando acessar o Visualizador de Rede. Vamos dividir.
1. Selecione o compartimento no qual residem seus componentes de rede. Se você não tiver certeza de onde estão seus recursos, selecione o compartimento principal (ou o compartimento raiz) e selecione Incluir compartimentos secundários.
2. Anote as VCNs que você tem: VCN-1 e VCN-2, e o bloco de endereços IPv4 para cada uma.
3. Observe os gateways de rede, como:
  - Um DRG que tem vários anexos (VCNs, RPC e IPSec).
  - Um Gateway NAT em VCN-2.
4. Você verá um RPC (Remote Peering Connect) também que conecta as VCNs na região de Jeddah a outra região (Riadh).
5. Há também uma conexão IPSec com a rede on-premises. Você pode ver o IP público do dispositivo CPE do cliente (210.20.x.x) e o bloco de endereços de rede local que se comunicará de forma privada com nossas VCNs (172.16.16.10/32).

Clique em VCN-2.
Agora, vamos nos aprofundar na topologia da VCN, começando pelo mapa de roteamento.

Segundo Nível: Topologia da VCN

Esta topologia inclui sub-redes, VLANs e gateways para outros recursos. Além das regras de segurança que a sub-rede usa (lista de segurança ou NSG).

Estamos na exibição de mapa Roteamento da VCN.
VCN-2 consiste em uma sub-rede privada.
Podemos ver uma regra na tabela de roteamento da sub-rede que envia o tráfego destinado a VCN-1 para o DRG como o próximo salto.

Alterne para a view de mapa de Segurança da VCN.
Também podemos ver nessa view que o VCN-2 consiste em uma sub-rede privada.
Além disso, as listas de segurança e os NSGs (Grupos de Segurança de Rede) anexados à sub-rede privada ficam visíveis nesse modo.

Clique na sub-rede privada.
Agora vamos nos aprofundar na topologia de sub-rede, começando com o mapa de inventário.

Terceiro Nível: Topologia de Sub-rede

Esta topologia mostra as informações de recursos sobre instâncias do OCI Compute, Balanceadores de Carga do OCI, Serviço de Armazenamento de Arquivos do OCI e clusters do OCI Kubernetes Engine (OKE) na sub-rede e as regras de segurança que o recurso usa.

Estamos na view de mapa do Inventário da sub-rede.
Temos apenas uma instância de computação nesta sub-rede (VM-2). Clique nela.
Você pode ver algumas informações sobre a VM, como compartimento, IPs e muito mais.

Alterne para a view de mapa Segurança da sub-rede.
Temos apenas uma instância de computação nesta sub-rede (VM-2).
Vemos quais listas de segurança e NSGs o VM-2 está usando.

Resumo:

Exploramos como é o nosso ambiente de rede e os componentes envolvidos, o que você acha que são as causas do problema que mencionamos anteriormente?

Problema 1: VM-1 não pode executar ping em VM-2.

Em Primeiro Nível: Topologia de Rede Regional, observe que VCN-1 não está anexado ao DRG; portanto, para que o fluxo de comunicação ocorra entre VM-1 e VM-2, devemos anexar VCN-1 e adicionar a regra de roteamento necessária para ativar o fluxo de tráfego.

Anexar VCN-1 e adicionar a seguinte regra de roteamento (destino: VCN-2, próximo salto: DRG) deve resolver o problema. Isso pressupõe que o roteamento em VCN-2 já esteja configurado corretamente e que o ICMP tipo 8 seja permitido nas duas listas de segurança.
Problema 2: VM-2 não pode acessar a Internet.

No Segundo Nível: topologia da VCN, observe que a sub-rede privada de VCN-2 tem apenas uma rota para o DRG, mas não rotas para o gateway NAT, o que faz com que o VM-2 não tenha conectividade com a Internet.

A adição da seguinte regra de roteamento (destino: 0.0.0.0/0, próximo salto: Gateway NAT) deve resolver o problema. Supondo que o tráfego de saída já seja permitido na lista de segurança.

O Visualizador de Rede pode ajudá-lo a identificar problemas óbvios causados por configurações incorretas, como vimos no exemplo. Mas mesmo quando não revela um problema claro, o seu valor real reside em dar-lhe uma visão holística do seu ambiente. Essa perspectiva abrangente ajuda a validar a configuração atual e oferece um ponto de partida sólido antes de se aprofundar em questões mais complexas.

Tarefa 2: Validar Configuração de Rede

Depois de obter uma visão clara do seu ambiente de rede e quais componentes você tem, o próximo passo essencial é validar a configuração real em vigor. Muitos problemas de conectividade se resumem a algo simples: uma rota ausente, regras de segurança excessivamente rígidas ou uma sub-rede que está simplesmente vinculada à tabela de roteamento ou à lista de segurança errada.

Antes de entrar em uma solução de problemas mais profunda, como verificar logs ou executar capturas de pacotes, é importante garantir que tudo esteja configurado conforme esperado. Este passo pode muitas vezes revelar a causa raiz cedo e ajudá-lo a evitar investigações desnecessárias mais tarde.

Exemplo

Usaremos a arquitetura a seguir como nosso exemplo.

Para começar, vamos descrever os principais componentes de roteamento e segurança que desempenham um papel central na validação da configuração:

Regras de Roteamento:
- On-premises:
  - RT-0: Roteamento do dispositivo Customer Premises Equipment (CPE) on-premises (ou multicloud), no caso de conexão FastConnect ou IPSec (consulte o fornecedor: Cisco, Fortinet etc.).
- Tabelas de Roteamento da VCN do OCI: existem na VCN e são usadas para enviar o tráfego da VCN (por exemplo, para a internet, para uma rede local ou para uma VCN pareada). Essas tabelas de roteamento têm regras que se parecem e agem de forma semelhante às regras de roteamento da rede tradicionais com as que você já deve estar familiarizado.
  - RT-1-2-3: Tabelas de roteamento da VCN designadas ao nível da sub-rede, a fim de rotear o tráfego de saída.
  - RT-2a: as tabelas de roteamento da VCN designadas ao anexo VCN-2 do DRG, que é necessário para cenários de roteamento de trânsito; neste exemplo, ele é usado como uma Tabela de Roteamento de Entrada para rotear o tráfego proveniente do DRG por meio do firewall para inspeção.
  - RT-2b: Tabela de roteamento da VCN que está anexada ao gateway NAT; neste exemplo, ela é usada como uma Tabela de Roteamento de Entrada para rotear o tráfego de resposta que retorna da Internet para o firewall para inspeção.
- Tabelas de Roteamento do DRG do OCI: Existem no DRG e são usadas para rotear pacotes informando o DRG por meio do anexo.
  - RT-10-20-30: Tabelas de roteamento do DRG para anexos da VCN, para rotear o tráfego proveniente da VCN.
  - RT-40-50: Tabelas de roteamento do DRG para anexos RPC, para rotear o tráfego proveniente da outra região.
  - RT-60: DRG RT para anexo IPSec, para rotear o tráfego proveniente de uma rede local ou multicloud.
Regras de Segurança:
- On-premises:
  - FW-0: Controle e restrinja o fluxo de tráfego de/para a OCI no dispositivo CPE on-premises (ou multicloud), no caso de conexão FastConnect ou IPSec (consulte o fornecedor: Cisco, Fortinet e assim por diante).
- Listas de Segurança da VCN do OCI: Aja como firewalls virtuais para recursos baseados em VCN, com regras de entrada e saída que especificam os tipos de tráfego permitidos dentro e fora. As listas de Segurança são configuradas no nível da sub-rede, o que significa que todas as VNICs de uma sub-rede estão sujeitas ao mesmo conjunto de listas de Segurança.
  - SL-1-2-3: Listas de segurança designadas ao nível da sub-rede para controlar o tráfego de entrada e saída em cada sub-rede.
Observação: Os NSGs são outro tipo de firewalls virtuais disponíveis no OCI. Eles funcionam de forma semelhante às listas de segurança, mas oferecem controle mais granular, à medida que são aplicados no nível do recurso. Isso é útil quando dois recursos na mesma sub-rede exigem posturas de segurança diferentes. Entretanto, os NSGs não são usados neste tutorial. Para obter mais informações, consulte Comparação entre Listas de Segurança e Grupos de Segurança de Rede.
- OCI Network Firewall ou um Firewall de Terceiros: atua como um ponto de inspeção centralizado e com monitoramento de estado para tráfego entre sub-redes, VCNs e redes externas, impondo políticas de segurança avançadas além das regras básicas da lista de segurança.
  - FW-2: Controla e inspeciona todo o tráfego Norte-Sul e Leste-Oeste em um ambiente de rede da OCI.

Entendemos como o roteamento e a segurança são aplicados em todo o ambiente, vamos dar uma olhada no exemplo a seguir, em que quatro problemas surgiram. Aplicando algum senso comum, vamos descobrir quais configurações verificar e onde, para cada cenário de solução de problemas.

Observação:

Se NSGs forem usados, revise as configurações aplicadas a cada VNIC anexada a cada VM.

Neste exemplo, VM-2 atua como um firewall de terceiros (FortiGate). Ele já está configurado para rotear o tráfego corretamente.

Problema 1: VM-1 não pode fazer ping em VM-3 (regiões diferentes, o firewall NÃO deve inspecionar o tráfego).
- Roteamento:
  - Solicitação: RT-1 > RT-10 > RT-40.
  - Resposta: RT-3 > RT-30 > RT-50.
- Segurança: O ICMP tipo 8 deve ter permissão para ter um ping bem-sucedido.
  - Solicitação: SL-1 (Regras de Saída) > SL-3 (Regras de Entrada).
  - Resposta: SL-3 (Regras de Saída) > SL-1 (Regras de Entrada).
Problema 2: O VM-1 não pode acessar a Internet (o firewall VM-2 deve inspecionar o tráfego).
- Roteamento:
  - Solicitação: RT-1 > RT-10 > RT-2a > Roteamento interno FW-2 > RT-2.
  - Resposta: RT-2b > Roteamento FW-2 > RT-2 > RT-20.
- Segurança:
  - Solicitação: SL-1 (Regras de Saída) > SL-2 (Regras de Entrada e Saída) > FW-2 (Regras de Entrada e Saída).
  - Resposta: SL-2 (Regras de Entrada e Saída) > FW-2 (Regras de Entrada e Saída) > SL-1 (Regras de Entrada).
Problema 3: VM2 não pode acessar a Internet.
- Roteamento:
  - Solicitação: RT-2.
  - Resposta: Nenhum roteiro é necessário.
- Segurança:
  - Solicitação: SL-2 (Regras de Saída).
  - Resposta: SL-2 (Regras de Entrada).
Problema 4: On-premises não pode fazer ping em VM-1 (o firewall deve inspecionar o tráfego).
- Roteamento:
  - Solicitação: RT-0 (CPE local) > RT-60 > RT-2a > Roteamento interno FW-2 > RT-2 > RT-20.
  - Resposta: RT-1 > RT-10 > RT-2a > Roteamento interno FW-2 > RT-2 > RT-20.
- Segurança:
  - Solicitação: FW-0 (Regras de Saída) > SL-2 (Regras de Entrada e Saída) > FW-2 (Regras de Entrada e Saída) > SL-1 (Regras de Entrada).
  - Resposta: SL-1 (Regras de Saída) > SL-2 (Regras de Entrada e Saída) > FW-2 (Regras de Entrada e Saída) > FW-0 (Regras de Entrada).

É fundamental entender como o tráfego é gerenciado e controlado em toda a rede. Ao rastrear o tráfego de caminho, você pode identificar rapidamente onde os problemas podem ocorrer e quais configurações precisam ser revisadas ao solucionar problemas.

Tarefa 3: Utilizar o Network Path Analyzer

Você revisou a configuração geral da rede, verificou manualmente a configuração das regras de roteamento e segurança. No entanto, o problema persiste, talvez você tenha ignorado alguns detalhes de configuração, então qual é o próximo passo?

É aqui que entra o Network Path Analyzer. Pense nisso como seu detetive de rede virtual, projetado para inspecionar seu roteamento de rede e configuração de segurança da OCI em tempo real. Ele os coleta e analisa para determinar como os caminhos entre a origem e o destino funcionarão ou falharão. Em vez disso, nenhum tráfego real é enviado, a configuração é examinada e usada para confirmar a acessibilidade.

Em vez de executar testes de conectividade manuais, como ping ou telnet, em VMs ou bancos de dados individuais, o Network Path Analyzer permite verificar a configuração dos caminhos de comunicação diretamente na Console do OCI, oferecendo uma abordagem de solução de problemas mais eficiente e centralizada.

O Network Path Analyzer oferece suporte aos seguintes cenários:

OCI para OCI.
da OCI para on-premises.
On-premises para OCI.
Internet para OCI.
Da OCI à Internet.

Exemplo 1

Usaremos a arquitetura a seguir como nosso exemplo.

Encontramos um problema de rede e usaremos o Network Path Analyzer para rastrear e resolver a causa raiz.

Problema: O VM-1 não pode acessar um site hospedado no VM-2 (OCI para OCI).

Faça log-in na Console do OCI, vá para VM-2 e execute o comando a seguir para verificar se o site está sendo executado localmente.
```
curl localhost
```
Vá para a Console do OCI, navegue até VM-1 e execute o mesmo comando para testar a conectividade com VM-2.
```
curl 192.168.0.20
```
Você verá que a solicitação falha. Nas próximas etapas, usaremos o Network Path Analyzer para investigar a causa.
Vá para a Console do OCI.
1. Certifique-se de estar na região certa.
2. Clique no menu de hambúrguer (≡) no canto superior esquerdo.
3. Clique em Networking.
4. Clique em Analisador de Caminho de Rede.
Clique em Criar análise de caminho.
Agora, vamos configurar os detalhes do fluxo de rede a ser testado.
1. Digite Nome como test-vm1-to-vm2-port80.
2. Selecione Protocolo como TCP.
Começaremos com o preenchimento da informação de origem, que neste caso é VM-1.
1. Selecione Localizar recurso do OCI.
2. Selecione Tipo de origem como Instância de computação (VNIC).
3. Selecione VM-1 na lista.
4. Selecione a VNIC que gerará o tráfego (já será preenchida automaticamente se a VM tiver apenas uma VNIC).
5. Selecione Endereço de origem IPv4 10.0.0.10 (também será preenchido automaticamente se houver apenas um endereço IPv4).
1. Clique em Mostrar opções avançadas.
2. Aqui, você pode especificar a porta de origem, se necessário; para este exemplo, deixe-a definida como Usar qualquer porta.
Em seguida, preencheremos as informações de destino, que neste caso é VM-2.
1. Selecione Localizar recurso do OCI.
2. Selecione Tipo de origem como Instância de computação (VNIC).
3. Selecione VM-2 na lista.
4. Selecione a VNIC que gerará o tráfego (já será preenchida automaticamente se a VM tiver apenas uma VNIC).
5. Selecione Endereço de origem IPv4 como 192.168.0.20 (também será preenchido automaticamente se houver apenas um endereço IPv4).
6. Informe Porta de destino como 80.
1. Para analisar o tráfego de encaminhamento e reversão, mantenha a Direção como Bi-direcional.
2. Clique em Executar análise.
1. Os detalhes da conexão são exibidos à medida que a análise é executada.
2. Role para baixo até rastrear o andamento da análise e aguarde até que ela termine. Isso pode levar um ou dois minutos.
A Análise foi concluída. Vamos começar a verificar o resultado de Forward path.
1. A análise indica que VM-2 está inacessível após dois saltos bem-sucedidos.
2. A eliminação ocorre entre o DRG e VM-2.
3. Para obter mais informações, clique em Exibir informações do diagrama.
4. Esta tabela divide o fluxo de roteamento e as verificações de segurança em cada etapa do caminho.
5. Se você ampliar, verá que o tráfego está sendo Negado entre o DRG e o VM-2.
1. Expanda o mesmo segmento para obter mais detalhes.
2. Observe que O roteamento foi encaminhado com sucesso.
3. No entanto, o tráfego está sendo negado devido a uma regra de segurança ausente:
  1. (3.a) O tráfego de saída é permitido, sem problemas aqui.
  2. (3.b) O tráfego de entrada é negado porque não há nenhuma regra que o permita. A lista de segurança associada à sub-rede VM-2 é mostrada (Lista de Segurança Padrão para VCN-2), anote-a, pois a revisaremos nas próximas etapas. Neste ponto, identificamos a origem do problema.
1. O caminho de retorno não foi analisado porque a verificação do caminho de encaminhamento falhou.
2. Clique em Salvar análise.
3. Você pode revisitar e executar novamente a análise a qualquer momento. Vamos executá-lo novamente mais tarde neste tutorial depois de corrigir o problema.
1. Navegue até VCN-2, onde a VM de destino está localizada.
2. Clique em Segurança.
3. Clique em Lista de Segurança Padrão do VCN-2.
Observação: As listas de segurança operam no nível da sub-rede, o que significa que qualquer tráfego permitido por essas regras se aplica a todas as VNICs dessa sub-rede.
1. Clique em Regras de segurança.
2. A tabela mostra qual tráfego é permitido. Tudo o resto, incluindo HTTP, é negado por padrão, já que não há regra para permitir. É por isso que o VM-1 não pode aceder ao website alojado no VM-2.
3. Para corrigir isso, clique em Adicionar Regras de Entrada.
1. Digite 10.0.0.0/16 no campo CIDR de Origem (este é o CIDR para VCN-1).
2. Selecione TCP para Protocolo IP.
3. Defina 80 como Porta de Destino.
4. Clique em Adicionar Regras de Entrada.
Faça log-in no VM-1 e execute o mesmo comando para testar a conectividade com o VM-2.
```
curl 192.168.0.20
```
Agora você deve ver que o site está acessível.
Volte para a análise para executar outra execução e verifique se o problema foi corrigido.
Clique em Analisar.
Aguarde o término da análise.
A Análise foi concluída. Vamos verificar o resultado de Forward path.
1. O status agora mostra Acessível.
2. O Hop 3 agora é bem-sucedido porque adicionamos uma regra de segurança que permite o tráfego HTTP.
3. Clique em Exibir informações do diagrama.
4. Você pode ver que o status de segurança do hop 3 agora é Permitido (anteriormente, ele foi Negado).
Verificando o caminho de retorno, podemos ver que é bem sucedido também.

Exemplo 2

Usaremos a arquitetura a seguir como nosso exemplo.

Encontramos um problema de rede e usaremos o Network Path Analyzer para rastrear e resolver a causa raiz.

Problema: VM-2 não pode instalar o pacote telnet (OCI para Internet).

Observação: o Telnet é um protocolo de rede e uma ferramenta de linha de comando usados para acessar e gerenciar dispositivos remotamente em uma rede. Também é usado para testes básicos de rede (por exemplo, verificando se uma porta está aberta).

Verifique se podemos instalar o telnet no VM-2.
1. Faça log-in no VM-2 e execute o comando a seguir para instalar o telnet.
```
sudo yum install telnet
```
2. Informe y e pressione Enter para continuar.
3. Falha na instalação. O VM-2 tentou estabelecer conexão com o repositório YUM regional (yum.me-jeddah-1.oci.oraclecloud.com), mas não conseguiu acessá-lo.
1. Execute o comando abaixo para localizar o IP do repositório yum.
```
dig yum.me-jeddah-1.oci.oraclecloud.com
```
2. Anote os endereços IP. VM-2 não pode acessar esses IPs públicos, o que indica que ele não tem acesso à internet por meio de um gateway NAT ou acesso privado ao Oracle Services Network por meio de um gateway de serviço para acessar o repositório yum, ou o tráfego de saída está sendo bloqueado. Para chegar ao fundo do problema, vamos avançar com a análise do NPA nas próximas etapas.
Vá para a Console do OCI.
1. Certifique-se de estar na região certa.
2. Clique no menu de hambúrguer (≡) no canto superior esquerdo.
3. Clique em Networking.
4. Clique em Analisador de Caminho de Rede.
Clique em Criar análise de caminho.
Agora, vamos configurar os detalhes do fluxo de rede a ser testado.
1. Digite Nome como test-vm2-to-internet-port443.
2. Selecione Protocolo como TCP.
Começaremos com o preenchimento da informação de origem, que neste caso é VM-2.
1. Selecione Localizar recurso do OCI.
2. Selecione Tipo de origem como Instância de computação (VNIC).
3. Selecione VM-2 na lista.
4. Selecione a VNIC que gerará o tráfego (já será preenchida automaticamente se a VM tiver apenas uma VNIC).
5. Selecione Endereço de origem IPv4 como 192.168.0.20 (também será preenchido automaticamente se houver apenas um endereço IPv4).
1. Clique em Mostrar opções avançadas.
2. Aqui, você pode especificar a porta de origem, se necessário; para este exemplo, deixe-a definida como Usar qualquer porta.
Em seguida, preencheremos as informações de destino, que neste caso é a internet, especificamente, os IPs públicos do repositório yum (192.29.119.92 e 192.29.125.93), vamos testar usando apenas um deles.
1. Selecione Informar endereço IP.
2. Informe o Endereço IPv4 de destino 192.29.119.92.
3. Informe a Porta de destino como 443, pois o acesso ao repositório é via HTTPS.
1. Para analisar o tráfego de encaminhamento e reversão, mantenha a Direção como Bi-direcional.
2. Clique em Executar análise.
1. Os detalhes da conexão são exibidos à medida que a análise é executada.
2. Role para baixo até rastrear o andamento da análise e aguarde até que ela termine. Isso pode levar um ou dois minutos.
A Análise foi concluída. Vamos começar a verificar o resultado de Forward path.
1. A análise mostra que o VM-2 não pode acessar a internet.
2. Este segmento destaca uma configuração ausente que impede que o tráfego saia do VCN-2.
3. Para obter mais informações, clique em Exibir informações do diagrama.
4. Esta tabela divide o fluxo de roteamento e as verificações de segurança em cada etapa do caminho. Como observado, o fluxo é direto, pois não há lúpulo intermediário no meio.
5. Se você ampliar, verá que há Nenhuma rota definida para esse tráfego.
1. Expanda o mesmo segmento para obter mais informações.
2. Não há roteamento configurado para enviar tráfego pela internet. Para corrigir isso, precisamos adicionar uma regra à tabela de roteamento de sub-rede VM-2 (Tabela de Roteamento Padrão para VCN-2), anote-a, pois a revisaremos nas próximas tarefas. Neste ponto, identificamos a origem do problema.
3. Observe que a segurança é Permitida.
  1. (3.a) O tráfego de saída é permitido, sem problemas aqui.
  2. (3.b) O tráfego de entrada não é relevante neste caso, pois o cenário se concentra apenas no tráfego de saída.
1. O caminho de retorno não foi analisado porque a verificação do caminho de encaminhamento falhou.
2. Clique em Salvar análise.
3. Você pode revisitar e executar novamente a análise a qualquer momento. Vamos executá-lo novamente mais tarde neste tutorial depois de corrigir o problema.
1. Navegue até a VCN-2, onde a VM de origem está localizada.
2. Clique em Roteamento.
3. Clique em Tabela de Roteamento Padrão para VCN-2.
Observação: As tabelas de roteamento operam no nível da sub-rede, o que significa que todas as regras definidas na tabela se aplicam a todos os recursos dessa sub-rede. As tabelas de roteamento também podem ser associadas a VNICs ou endereços IP específicos, bem como usando o Roteamento por Recurso. No entanto, isso não é relevante para o nosso tutorial. Para obter mais informações, consulte Roteamento por Recurso.
1. Clique em Regras de Roteamento.
2. No momento, há apenas uma regra de roteamento configurada para rotear o tráfego para VCN-1.
3. Para ativar o acesso à Internet, clique em Adicionar Regras de Roteamento.
1. Selecione Gateway NAT como Tipo de Destino.
2. Informe 0.0.0.0/0 como Bloco CIDR de Destino.
3. Selecione o Gateway NAT criado anteriormente.
4. Clique em Adicionar Regras de Roteamento.
Faça login no VM-2 e tente instalar o telnet novamente.
1. Execute o seguinte comando.
```
sudo yum install telnet
```
2. A instalação está Concluída!.
Volte para a análise para executar outra execução e verifique se o problema foi corrigido.
Clique em Analisar.
Aguarde o término da análise.
A Análise foi concluída. Vamos verificar o resultado de Forward path.
1. O status agora mostra Acessível.
2. O Hop 2 agora é bem-sucedido porque adicionamos uma regra de roteamento que envia tráfego ao gateway NAT.
3. Clique em Exibir informações do diagrama.
4. Você pode ver que o status de roteamento do hop 2 agora é Encaminhado (anteriormente, era Nenhuma rota).
Verificando o caminho de retorno, podemos ver que é bem sucedido também.

Tarefa 4: Analisar Logs de Fluxo da VCN

Os Logs de Fluxo da VCN oferecem uma camada adicional de visibilidade do comportamento do tráfego. Esse serviço permite que você faça drill-down do tráfego real que atinge cada VNIC, indicando se ele foi aceito ou rejeitado com base na lista de segurança e nas regras de NSG, ajudando a solucionar problemas relacionados à segurança.

Além da solução de problemas, os Logs de Fluxo da VCN são cruciais para monitorar a atividade da rede, capturar IPs de origem/destino, portas, protocolos e timestamps, fornecendo a telemetria detalhada necessária para auditorias e investigações de segurança também.

Exemplo

Usaremos a arquitetura a seguir como nosso exemplo.

Observação: Neste exemplo, nos concentramos apenas no registro em log no ponto Y, onde o destino está localizado. No entanto, você pode aplicar as mesmas etapas para ativar e analisar logs no ponto X (a origem do tráfego) para obter visibilidade adicional do fluxo de tráfego geral.

Encontramos um problema de rede e usaremos Logs de Fluxo da VCN para rastrear e tratar a causa raiz.

Problema: VM-1 não pode acessar um site hospedado na VM-2.

Faça login no VM-2 e execute o comando a seguir para verificar se o site está sendo executado localmente.
```
curl localhost
```
Faça log-in no VM-1 e execute o mesmo comando para testar a conectividade com VM-2.
```
curl 192.168.0.20
```
Você verá que a solicitação falha. Nas próximas etapas, usaremos logs de fluxo VCN-2 para investigar a causa.
Agora, vamos ativar os logs. Começaremos criando um Filtro de Captura, que é um conjunto de regras simples usado no OCI para determinar qual tráfego de rede deve ser capturado para registro em log ou espelhado em VTAPs (Virtual Test Access Points).
1. Faça log-in na Console do OCI e certifique-se de estar na região certa.
2. Clique no menu de hambúrguer (≡) no canto superior esquerdo.
3. Clique em Networking.
4. Clique em Capturar filtros.
Clique em Criar filtro de captura.
1. Digite vcn-2-private-sn-logs como Nome.
2. Selecione Filtro de captura de log de fluxo como Tipo de filtro.
3. Defina a Taxa de amostragem como 100%. Isso define a porcentagem de fluxos de rede a serem capturados. Nesse caso, queremos registrar todo o tráfego.
1. Deixe todas as outras definições em seus valores padrão.
2. Clique em Criar filtro de captura.
Depois que o filtro de captura for criado, clique em Copiar para copiar seu OCID, pois você precisará dele nas próximas etapas.
Agora, estamos prontos para ativar os logs.
1. Navegue até VCN-2.
2. Abra a Sub-rede Privada, na qual VM-2 reside.
3. Clique em Monitoramento.
4. Role para baixo até a seção Logs.
5. Clique nos três pontos (••••) ao lado da categoria Logs de Fluxo.
6. Clique em Ativar log.
1. Selecione Grupo de Logs. Se você ainda não tiver um, crie um novo grupo de logs.
2. Nome do log é preenchido automaticamente.
3. Cole o OCID do filtro de captura copiado anteriormente.
4. Clique em Ativar log.
Os logs de fluxo agora estão Ativos.
Repita o mesmo teste para gerar tráfego executando o comando a seguir no VM-1.
```
curl 192.168.0.20
```
Retorne à seção Logs e clique em Nome do Log criado anteriormente.
1. Role para baixo e você verá logs mostrando o tráfego que entra ou sai da rede.
2. Clique em Ações.
3. Clique em Explorar com Pesquisa de Log para aplicar filtros avançados e restringir os resultados do log.
1. Aplique os Filtros a seguir para corresponder à nossa conexão de teste.
  - IP de Origem (VM-1): data.sourceAddress = '10.0.0.10'.
  - IP de Destino (VM-2): data.destinationAddress = '192.168.0.20'.
  - Porta de Destino (HTTP): data.destinationPort = 80.
2. Ajuste o intervalo de tempo em Filtrar por hora, se necessário, ou deixe-o como o Últimos 5 minutos padrão.
3. Clique em Pesquisar.
1. Revise os resultados que correspondem aos critérios de pesquisa.
2. Expanda os detalhes do registro.
Para esse registro específico, você pode exibir informações detalhadas sobre esse fluxo de tráfego. Os campos-chave a serem observados incluem:
1. Timestamp: A data e a hora exatas em que o tráfego atingiu a sub-rede.
2. Detalhes da conexão: Como endereço IP de origem, endereço IP de destino e número da porta.
3. Ação: Mostra como o tráfego foi tratado; nesse caso, ele foi REJECT. Isso confirma a causa raiz do problema. Não há regra de segurança em vigor para permitir o tráfego HTTP para VM-2.
Para permitir que o tráfego HTTP chegue a VM-2, você tem duas opções:
- Lista de Segurança: Aplicada no nível de sub-rede, o que significa que todas as VNICs de uma sub-rede estão sujeitas ao mesmo conjunto de listas de seguranças.
- NSG: Aplicado no nível de recurso (nível de VNIC).
Aqui, vamos permitir isso na lista de segurança padrão que já está associada à sub-rede VM-2.
1. Navegue até VCN-2, onde a VM de destino está localizada.
2. Clique em Segurança.
3. Clique em Default Security List for VCN-2.
1. Clique em Regras de segurança.
2. A tabela mostra qual tráfego é permitido. Tudo o resto, incluindo HTTP, é negado por padrão, já que não há regra para permitir. É por isso que o VM-1 não pode aceder ao website alojado no VM-2.
3. Para corrigir isso, clique em Adicionar Regras de Entrada.
1. Digite 10.0.0.0/16 como CIDR de Origem (este é o CIDR para VCN-1).
2. Selecione TCP como IP Protocol.
3. Defina 80 como Porta de Destino.
4. Clique em Adicionar Regras de Entrada.
Faça log-in no VM-1 e execute o mesmo comando para testar a conectividade com o VM-2.
```
curl 192.168.0.20
```
Agora você deve ver que o site está acessível.
Retorne aos logs e repita as mesmas etapas de antes para executar uma nova pesquisa.
1. Aplique os Filtros a seguir para corresponder à nossa conexão de teste.
  - IP de Origem (VM-1): data.sourceAddress = '10.0.0.10'.
  - IP de Destino (VM-2): data.destinationAddress = '192.168.0.20'.
  - Porta de Destino (HTTP): data.destinationPort = 80.
2. Se necessário, ajuste o intervalo de tempo ou deixe-o como padrão (Últimos 5 minutos).
3. Clique em Pesquisar.
1. Revise os resultados que correspondem aos critérios de pesquisa.
2. Expanda os detalhes do registro.
Para esse registro específico, você pode exibir informações detalhadas sobre esse fluxo de tráfego. Os campos-chave a serem observados incluem:
1. Timestamp: A data e a hora exatas em que o tráfego atingiu a sub-rede.
2. Detalhes da conexão: Como IP de origem, IP de destino e número da porta.
3. Ação: Mostra como o tráfego foi tratado. Depois de resolver o problema, agora você deverá ver que o tráfego é ACEITAR.

Próximas Etapas

Exploramos como solucionar problemas fundamentais de rede na OCI examinando configurações de arquitetura, roteamento e segurança. Essas verificações básicas ajudam a resolver os problemas de conectividade mais comuns. O próximo tutorial se concentrará em cenários avançados e em casos de uso mais reais.

Confirmações

Autores - Anas Abdallah (Especialista em Cloud Networking), Sachin Sharma (Especialista em Cloud Networking)

Mais Recursos de Aprendizado

Explore outros laboratórios em docs.oracle.com/learn ou acesse mais conteúdo de aprendizado gratuito no canal do Oracle Learning YouTube. Além disso, acesse education.oracle.com/learning-explorer para se tornar um Oracle Learning Explorer.

Para obter a documentação do produto, visite o Oracle Help Center.

Título e Informações de Copyright

Troubleshoot Basic Network Issues in Oracle Cloud Infrastructure

G40745-01

Oracle e/ou suas empresas afiliadas.