Solución de problemas básicos de red en Oracle Cloud Infrastructure

Introducción

En Oracle Cloud Infrastructure (OCI), el diagnóstico de problemas de conectividad de red requiere visibilidad de la configuración y el flujo de tráfico en varios componentes. Las herramientas del centro de comandos de red de OCI, como Network Visualizer, Network Path Analyzer y los logs de flujo de VCN, proporcionan estadísticas detalladas sobre el diseño, el enrutamiento y el comportamiento del flujo de los recursos de red. Estas herramientas permiten identificar rápidamente configuraciones incorrectas, rutas que faltan y fallos de comunicación en redes virtuales en la nube (VCN), subredes y gateways en un entorno de red de OCI.

En este tutorial, nos centraremos en técnicas fundamentales de resolución de problemas para problemas de conectividad comunes. Si bien demuestra cómo usar eficazmente estas herramientas para simplificar la resolución de problemas y resolverlos de manera eficiente, el objetivo también es desarrollar una comprensión más amplia de cómo abordar y analizar los desafíos de conectividad, no solo cómo usar las propias herramientas.

Objetivos

Utilice la herramienta Network Visualizer para explorar el diseño de red en los niveles regional, de VCN y de subred.
Analice las rutas de flujo de tráfico mediante la herramienta Network Path Analyzer para comprender cómo los paquetes atraviesan la red e identificar fallos.
Interpretar la herramienta Logs de flujo de VCN para inspeccionar los registros de flujo de tráfico y detectar problemas de conectividad o comportamientos inusuales.
Identifique y solucione errores de configuración de red, rutas que faltan y fallos de comunicación.

Requisitos

Está familiarizado con los componentes de red básicos de OCI, como VCN, subredes, gateways, listas de seguridad y tablas de rutas.
Tiene acceso a un arrendamiento de OCI con recursos de red configurados.
Su cuenta de usuario ha necesitado políticas de Oracle Cloud Infrastructure Identity and Access Management (OCI IAM) para gestionar los componentes de la VCN, así como para utilizar Network Visualizer, Network Path Analyzer y VCN Flow Logs.

Si desea seguir algunos de los próximos ejemplos, ejecute los siguientes comandos en la máquina virtual (vM) de Oracle Linux de prueba para crear un sitio web Apache simple.

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>'

Tarea 1: Visualización de la configuración de red con el visualizador de red

Antes de comenzar a indagar en lo que está roto, ayuda dar un paso atrás y obtener una visión clara de su entorno de red. El visualizador de red en OCI ofrece una representación gráfica de la topología de la VCN. Aunque no soluciona directamente los problemas, proporciona una vista clara y consolidada de toda la arquitectura de red en un compartimento específico que elija.

Este contexto visual muestra cómo se conecta todo (VCNs, subredes, gateways, tablas de rutas, listas de seguridad) todo en un solo lugar. Esto hace que sea más fácil detectar cualquier cosa que esté desactivada, como una ruta que falta o una VCN que no esté asociada a un gateway de direccionamiento dinámico (DRG). En configuraciones complejas, puede ahorrarte muchas conjeturas. No siempre es una solución, pero es un primer paso sólido que puede apuntarte en la dirección correcta antes de entrar en los detalles.

Para este tutorial, hemos resumido cómo funciona el Visualizador de red en el siguiente diagrama. Para obtener más información, consulte Network Visualizer.

Ejemplo

Utilizaremos la siguiente arquitectura como ejemplo.

En este caso de ejemplo, surgieron dos problemas en el medio ambiente. Veremos cómo el Visualizador de Red ayuda a identificarlos y resolverlos.

Problema 1: VM-1 no puede hacer ping a VM-2.
Problema 2: VM-2 no puede acceder a Internet.

Hagamos un recorrido rápido por nuestro entorno de red mediante Network Visualizer en la consola de OCI, que debería reflejar la arquitectura.

Primer Nivel: Topología de Red Regional

Esta topología incluye DRG, VCN, CPE y varios tipos de gateways.

Conéctese a la consola de OCI.
1. Asegúrese de que está en la región correcta.
2. Haga clic en el menú de hamburguesa (≡) en la esquina superior izquierda.
3. Haga clic en Networking.
4. Haga clic en Visualizador de red.

Esta es la primera vista que verá una vez que acceda a Network Visualizer. Vamos a desglosarlo.
1. Seleccione el compartimento en el que residen los componentes de red. Si no está seguro de dónde están los recursos, seleccione el compartimento principal (o el compartimento raíz) y seleccione Incluir compartimentos secundarios.
2. Anote las VCN que tiene: VCN-1 y VCN-2, y el bloque de direcciones IPv4 para cada una.
3. Tenga en cuenta los gateways de red, como:
  - Un DRG que tiene varias asociaciones (VCN, RPC y IPSec).
  - Un gateway de NAT en VCN-2.
4. También verá una conexión de intercambio de tráfico remoto (RPC) que conecta las redes virtuales en la nube de la región de Jeddah a otra región (Riyadh).
5. También hay una conexión IPSec a la red local. Puede ver la IP pública del dispositivo CPE del cliente (210.20.x.x) y el bloque de direcciones de red local que se comunicará de forma privada con nuestras redes virtuales en la nube (172.16.16.10/32).

Haga clic en VCN-2.
Ahora profundicemos en la topología de la VCN, empezando por el mapa de enrutamiento.

Segundo nivel: topología de VCN

Esta topología incluye subredes, VLAN y gateways a otros recursos. Además de las reglas de seguridad que utiliza la subred (lista de seguridad o NSG).

Estamos en la vista de mapa Enrutamiento de la VCN.
VCN-2 consta de una subred privada.
Podemos ver una regla en la tabla de rutas de la subred que envía el tráfico destinado a VCN-1 al DRG como el siguiente salto.

Cambie a la vista de asignación de seguridad de la VCN.
También podemos ver en esta vista que VCN-2 consta de una subred privada.
Además, las listas de seguridad y los grupos de seguridad de red (NSG) que están conectados a la subred privada están visibles en este modo.

Haga clic en la subred privada.
Ahora profundicemos en la topología de subred, empezando por el mapa de inventario.

Tercer nivel: topología de subred

Esta topología muestra la información de los recursos sobre las instancias informáticas de OCI, los equilibradores de carga de OCI, el servicio OCI File Storage y los clusters de OCI Kubernetes Engine (OKE) en la subred, así como las reglas de seguridad que utiliza el recurso.

Estamos en la vista de mapa de inventario de subred.
Solo tenemos una instancia informática en esta subred (VM-2), haga clic en ella.
Puede ver información sobre la máquina virtual, como el compartimento, las IP, etc.

Cambie a la vista de mapa de seguridad de subred.
Solo tenemos una instancia informática en esta subred (VM-2).
Vemos qué listas de seguridad y NSG está utilizando VM-2.

Resumen:

Hemos explorado cómo se ve nuestro entorno de red y los componentes involucrados, ¿cuáles crees que son las causas fundamentales del problema que mencionamos anteriormente?

Problema 1: VM-1 no puede hacer ping a VM-2.

En el primer nivel: topología de red regional, observe que VCN-1 no está asociado al DRG, por lo que para que el flujo de comunicación se produzca entre VM-1 y VM-2, debemos asociar VCN-1 y agregar la regla de ruta necesaria para activar el flujo de tráfico.

La asociación de VCN-1 y la adición de la siguiente regla de ruta (destino: VCN-2, siguiente salto: DRG) deben resolver el problema. Esto supone que el enrutamiento en VCN-2 ya está configurado correctamente, y el tipo de ICMP 8 está permitido en ambas listas de seguridad.
Problema 2: VM-2 no puede acceder a Internet.

En el segundo nivel: topología de VCN, observe que la subred privada de VCN-2 solo tiene una ruta al DRG, pero no tiene rutas al gateway de NAT, lo que hace que VM-2 no tenga conectividad a Internet.

Al agregar la siguiente regla de ruta (destino: 0.0.0.0/0, siguiente salto: gateway de NAT), se debe resolver el problema. Suponiendo que el tráfico de salida ya está permitido en la lista de seguridad.

Network Visualizer puede ayudarte a detectar problemas obvios causados por configuraciones erróneas, como vimos en el ejemplo. Pero incluso cuando no revela un problema claro, su valor real radica en darle una visión holística de su entorno. Esa perspectiva de gran imagen le ayuda a validar la configuración actual y le brinda un punto de partida sólido antes de profundizar en problemas más complejos.

Tarea 2: Validación de la configuración de red

Después de obtener una visión clara de su entorno de red y de los componentes que tiene, el siguiente paso esencial es validar la configuración real en su lugar. Muchos problemas de conectividad se reducen a algo simple: una ruta faltante, reglas de seguridad demasiado estrictas o una subred que simplemente está vinculada a la tabla de rutas o lista de seguridad incorrectas.

Antes de adentrarse en una solución de problemas más profunda, como la comprobación de logs o la ejecución de capturas de paquetes, es importante asegurarse de que todo esté configurado según lo esperado. Este paso a menudo puede revelar la causa raíz temprano y ayudarlo a evitar investigaciones innecesarias más adelante.

Ejemplo

Utilizaremos la siguiente arquitectura como ejemplo.

Para empezar, describamos los componentes principales de enrutamiento y seguridad que desempeñan un papel central en la validación de la configuración:

Reglas de Direccionamiento:
- Local:
  - RT-0: enrutamiento del dispositivo local del equipo local del cliente (CPE) (o multinube), en caso de conexión FastConnect o IPSec (consulte al proveedor: Cisco, Fortinet, etc.).
- Tablas de rutas de VCN de OCI: existen en la VCN y se utilizan para enviar tráfico desde la VCN (por ejemplo, a Internet, a una red local o a una VCN conectada). Estas tablas de rutas tienen reglas que parecen y actúan como la regla de ruta de red tradicional con las que puede que esté familiarizado.
  - RT-1-2-3: tablas de enrutamiento de VCN que se asignan al nivel de subred para enrutar el tráfico saliente.
  - RT-2a: tablas de enrutamiento de VCN que están asignadas a la asociación VCN-2 de DRG, que es necesaria para escenarios de enrutamiento en tránsito, en este ejemplo, se utiliza como tabla de rutas de entrada para enrutar el tráfico procedente de DRG a través del firewall para su inspección.
  - RT-2b: tabla de enrutamiento de VCN asociada al gateway de NAT, en este ejemplo se utiliza como tabla de rutas de entrada para enrutar el tráfico de respuesta que vuelve de Internet al firewall para su inspección.
- Tablas de rutas de OCI DRG: existen en el DRG y se utilizan para enrutar paquetes de entrada en el DRG a través de la asociación.
  - RT-10-20-30: tablas de enrutamiento de DRG para asociaciones de VCN, para enrutar el tráfico que proviene de la VCN.
  - RT-40-50: tablas de enrutamiento de DRG para asociaciones RPC, para enrutar el tráfico que proviene de la otra región.
  - RT-60: RT de DRG para asociación IPSec, para enrutar el tráfico que proviene de una red local o multinube.
Reglas de seguridad:
- Local:
  - FW-0: controla y restringe el flujo de tráfico hacia y desde OCI en el dispositivo CPE local (o multinube), en caso de conexión FastConnect o IPSec (consulte al proveedor: Cisco, Fortinet, etc.).
- Listas de seguridad de VCN de OCI: actúe como firewalls virtuales para recursos basados en VCN, con reglas de entrada y salida que especifiquen los tipos de tráfico permitidos de entrada y salida. Las listas de Seguridad se configuren en el nivel del subred, lo que significa que todas las VNIC de una subred están sujetas al mismo conjunto de listas de Seguridad.
  - SL-1-2-3: listas de seguridad que se asignan al nivel de subred para controlar el tráfico de entrada y salida en cada subred.
Nota: Los NSG son otro tipo de firewalls virtuales disponibles en OCI. Funcionan de forma similar a las listas de seguridad, pero ofrecen un control más granular, ya que se aplican en el nivel de recurso. Esto resulta útil cuando dos recursos de la misma subred requieren diferentes posturas de seguridad. Sin embargo, los NSG no se utilizan en este tutorial. Para obtener más información, consulte Comparación de listas de seguridad y grupos de seguridad de red.
- OCI Network Firewall o un firewall de terceros: actúa como punto de inspección centralizado y con estado para el tráfico entre subredes, redes virtuales en la nube y redes externas, aplicando políticas de seguridad avanzadas más allá de las reglas básicas de la lista de seguridad.
  - FW-2: controla e inspecciona todo el tráfico Norte-Sur y Este-Oeste en un entorno de red de OCI.

Entendemos cómo se aplican el enrutamiento y la seguridad en todo el entorno, echemos un vistazo más de cerca al siguiente caso de ejemplo, en el que han surgido cuatro problemas. Al aplicar algún sentido común, descubriremos qué configuraciones verificar y dónde, para cada escenario de solución de problemas.

Nota:

Si se utilizan NSG, revise las configuraciones aplicadas a cada VNIC conectada a cada VM.

En este ejemplo, VM-2 actúa como un firewall de terceros (FortiGate). Ya está configurado para enrutar el tráfico correctamente.

Problema 1: VM-1 no puede hacer ping a VM-3 (diferentes regiones, el firewall NO debe inspeccionar el tráfico).
- Direccionamiento:
  - Solicitud: RT-1 > RT-10 > RT-40.
  - Respuesta: RT-3 > RT-30 > RT-50.
- Seguridad: se debe permitir que el tipo 8 de ICMP tenga un ping correcto.
  - Solicitud: SL-1 (Reglas de salida) > SL-3 (Reglas de entrada).
  - Respuesta: SL-3 (reglas de salida) > SL-1 (reglas de entrada).
Problema 2: VM-1 no puede acceder a Internet (el firewall VM-2 debe inspeccionar el tráfico).
- Direccionamiento:
  - Solicitud: RT-1 > RT-10 > RT-2a > enrutamiento interno de FW-2 > RT-2.
  - Respuesta: RT-2b > enrutamiento FW-2 > RT-2 > RT-20.
- Seguridad:
  - Solicitud: SL-1 (Reglas de salida) > SL-2 (Reglas de entrada y salida) > FW-2 (Reglas de entrada y salida).
  - Respuesta: SL-2 (reglas de entrada y salida) > FW-2 (reglas de entrada y salida) > SL-1 (reglas de entrada).
Problema 3: VM2 no puede acceder a Internet.
- Direccionamiento:
  - Solicitud: RT-2.
  - Respuesta: no se requiere enrutamiento.
- Seguridad:
  - Solicitud: SL-2 (Reglas de salida).
  - Respuesta: SL-2 (reglas de entrada).
Problema 4: el entorno local no puede hacer ping a VM-1 (el firewall debe inspeccionar el tráfico).
- Direccionamiento:
  - Solicitud: RT-0 (CPE local) > RT-60 > RT-2a > enrutamiento interno FW-2 > RT-2 > RT-20.
  - Respuesta: RT-1 > RT-10 > RT-2a > enrutamiento interno de FW-2 > RT-2 > RT-20.
- Seguridad:
  - Solicitud: FW-0 (Reglas de salida) > SL-2 (Reglas de entrada y salida) > FW-2 (Reglas de entrada y salida) > SL-1 (Reglas de entrada).
  - Respuesta: SL-1 (Reglas de salida) > SL-2 (Reglas de entrada y salida) > FW-2 (Reglas de entrada y salida) > FW-0 (Reglas de entrada).

Es crucial entender cómo se gestiona y controla el tráfico en toda la red. Al realizar un seguimiento del tráfico de ruta, puede identificar rápidamente dónde se pueden producir problemas y qué configuración se debe revisar al solucionar problemas.

Tarea 3: Uso del analizador de rutas de red

Ha revisado la configuración general de la red y ha comprobado manualmente la configuración de las reglas de enrutamiento y seguridad. Sin embargo, el problema persiste, tal vez haya pasado por alto algunos detalles de configuración, así que ¿cuál es el siguiente paso?

Aquí es donde entra en juego Network Path Analyzer. Piense en ello como su detective de red virtual, diseñado para inspeccionar su configuración de seguridad y enrutamiento de red de OCI en tiempo real. Los recopila y analiza para determinar cómo funcionarán o fallarán las rutas entre el origen y el destino. No se envía tráfico real, en su lugar, se examina la configuración y se utiliza para confirmar la accesibilidad.

En lugar de realizar pruebas de conectividad manuales como ping o telnet desde máquinas virtuales o bases de datos individuales, Network Path Analyzer le permite verificar la configuración de las rutas de comunicación directamente dentro de la consola de OCI, ofreciendo un enfoque de solución de problemas más eficiente y centralizado.

Network Path Analyzer admite los siguientes escenarios:

De OCI a OCI.
De OCI a local.
De forma local a OCI.
de Internet a OCI.
De OCI a Internet.

Ejemplo 1

Utilizaremos la siguiente arquitectura como ejemplo.

Hemos encontrado un problema de red y utilizaremos Network Path Analyzer para rastrear y abordar la causa raíz.

Problema: VM-1 no puede acceder a un sitio web alojado en VM-2 (OCI a OCI).

Conéctese a la consola de OCI, vaya a VM-2 y ejecute el siguiente comando para comprobar si el sitio web se está ejecutando localmente.
```
curl localhost
```
Vaya a la consola de OCI, vaya a VM-1 y ejecute el mismo comando para probar la conectividad a VM-2.
```
curl 192.168.0.20
```
Verá que la solicitud falla. En los siguientes pasos, utilizaremos Network Path Analyzer para investigar la causa.
Vaya a la consola de OCI.
1. Asegúrese de que está en la región correcta.
2. Haga clic en el menú de hamburguesa (≡) en la esquina superior izquierda.
3. Haga clic en Networking.
4. Haga clic en Network Path Analyzer (Analizador de rutas de redes).
Haga clic en Crear análisis de ruta.
Ahora, vamos a configurar los detalles del flujo de red que se va a probar.
1. Introduzca Name como test-vm1-to-vm2-port80.
2. Seleccione Protocolo como TCP.
Empezaremos por rellenar la información fuente, que en este caso es VM-1.
1. Seleccione Buscar recurso de OCI.
2. Seleccione Tipo de origen como Instancia informática (VNIC).
3. Seleccione VM-1 en la lista.
4. Seleccione la VNIC que generará el tráfico (ya se rellena automáticamente si la VM solo tiene una VNIC).
5. Seleccione Dirección IPv4 de origen 10.0.0.10 (también se rellena automáticamente si solo hay una dirección IPv4).
1. Haga clic en Mostrar las opciones avanzadas.
2. Aquí, puede especificar el puerto de origen si es necesario; para este ejemplo, déjelo definido en Usar cualquier puerto.
A continuación, cumplimentaremos la información de destino, que en este caso es VM-2.
1. Seleccione Buscar recurso de OCI.
2. Seleccione Tipo de origen como Instancia informática (VNIC).
3. Seleccione VM-2 en la lista.
4. Seleccione la VNIC que generará el tráfico (ya se rellena automáticamente si la VM solo tiene una VNIC).
5. Seleccione Dirección IPv4 de origen como 192.168.0.20 (también se rellena automáticamente si solo hay una dirección IPv4).
6. Introduzca Destination port (Puerto de destino) como 80.
1. Para analizar el tráfico tanto hacia delante como hacia atrás, mantenga la dirección como bidireccional.
2. Haga clic en Ejecutar análisis.
1. Los detalles de conexión se muestran a medida que se ejecuta el análisis.
2. Desplácese hacia abajo para realizar un seguimiento del progreso del análisis y espere hasta que finalice, lo que puede tardar uno o dos minutos.
El análisis se ha completado. Comencemos a comprobar el resultado de Ruta de acceso anticipada.
1. El análisis indica que no se puede acceder a VM-2 después de dos saltos correctos.
2. El borrado se produce entre el DRG y VM-2.
3. Para obtener más información, haga clic en Ver información de diagrama.
4. Esta tabla desglosa el flujo de enrutamiento y las comprobaciones de seguridad en cada paso de la ruta.
5. Si amplía, verá que el tráfico está siendo Denegado entre el DRG y VM-2.
1. Amplíe el mismo segmento para obtener más detalles.
2. Tenga en cuenta que el enrutamiento se reenvía correctamente.
3. Sin embargo, el tráfico se está denegando debido a que falta una regla de seguridad:
  1. (3.a) Se permite el tráfico de salida, no hay problemas aquí.
  2. (3.b) Se deniega el tráfico de entrada porque no hay ninguna regla que lo permita. Se muestra la lista de seguridad asociada a la subred VM-2 (Lista de seguridad por defecto para VCN-2), anótela, ya que la revisaremos en los siguientes pasos. En este punto, hemos identificado la fuente del problema.
1. La ruta de devolución no se analiza porque la comprobación de ruta de reenvío ha fallado.
2. Haga clic en Guardar el análisis.
3. Puede volver a ejecutar el análisis en cualquier momento. Volveremos a ejecutarlo más adelante en este tutorial después de solucionar el problema.
1. Navegue hasta VCN-2, donde se encuentra la VM de destino.
2. Haga clic en Seguridad.
3. Haga clic en Default Security List for VCN-2.
Nota: Las listas de seguridad funcionan en el nivel de subred, lo que significa que cualquier tráfico permitido por estas reglas se aplica a todas las VNIC de esa subred.
1. Haga clic en Reglas de seguridad.
2. En la tabla, se muestra qué tráfico se permite. Todo lo demás, incluido HTTP, se deniega por defecto, ya que no hay ninguna regla que lo permita. Por eso VM-1 no puede acceder al sitio web alojado en VM-2.
3. Para solucionarlo, haga clic en Agregar reglas de entrada.
1. Introduzca 10.0.0.0/16 en el campo CIDR de origen (este es el CIDR para VCN-1).
2. Seleccione TCP en Protocolo IP.
3. Defina 80 como Destination Port (Puerto de destino).
4. Haga clic en Agregar reglas de entrada.
Inicie sesión en VM-1 y ejecute el mismo comando para probar la conectividad a VM-2.
```
curl 192.168.0.20
```
Ahora debe ver que el sitio web es accesible.
Vuelva al análisis para realizar otra ejecución y verifique que el problema se ha solucionado.
Haga clic en Analizar.
Espere a que finalice el análisis.
El análisis ha finalizado. Vamos a comprobar el resultado de Ruta de avance.
1. El estado ahora muestra Alcanzable.
2. El salto 3 ahora es correcto porque agregamos una regla de seguridad que permite el tráfico HTTP.
3. Haga clic en Ver información del diagrama.
4. Puede ver que el estado de seguridad para el salto 3 ahora es Permitido (anteriormente, era Denegado).
Verificando la ruta de retorno, podemos ver que también es exitosa.

Ejemplo 2

Utilizaremos la siguiente arquitectura como ejemplo.

Hemos encontrado un problema de red y utilizaremos Network Path Analyzer para rastrear y abordar la causa raíz.

Problema: VM-2 no puede instalar el paquete telnet (OCI a Internet).

Nota: Telnet es un protocolo de red y una herramienta de línea de comandos que se utiliza para acceder y gestionar dispositivos de forma remota a través de una red. También se utiliza para pruebas de red básicas (por ejemplo, comprobar si un puerto está abierto).

Compruebe si podemos instalar telnet en VM-2.
1. Inicie sesión en VM-2 y ejecute el siguiente comando para instalar telnet.
```
sudo yum install telnet
```
2. Introduzca y y pulse Intro para continuar.
3. La instalación ha fallado. VM-2 ha intentado conectarse al repositorio YUM regional (yum.me-jeddah-1.oci.oraclecloud.com), pero no ha podido acceder a él.
1. Ejecute el siguiente comando para buscar la IP del repositorio yum.
```
dig yum.me-jeddah-1.oci.oraclecloud.com
```
2. Anote las direcciones IP. VM-2 no puede acceder a estas IP públicas, lo que indica que no tiene acceso a Internet a través de un gateway de NAT ni de acceso privado a Oracle Services Network a través de un gateway de servicios para acceder al repositorio yum, o que el tráfico saliente se está bloqueando. Para llegar al fondo del problema, vamos a avanzar con el análisis de NPA en los próximos pasos.
Vaya a la consola de OCI.
1. Asegúrese de que está en la región correcta.
2. Haga clic en el menú de hamburguesa (≡) en la esquina superior izquierda.
3. Haga clic en Networking.
4. Haga clic en Network Path Analyzer (Analizador de rutas de redes).
Haga clic en Crear análisis de ruta.
Ahora, vamos a configurar los detalles del flujo de red que se va a probar.
1. Introduzca Name como test-vm2-to-internet-port443.
2. Seleccione Protocolo como TCP.
Empezaremos por rellenar la información fuente, que en este caso es VM-2.
1. Seleccione Buscar recurso de OCI.
2. Seleccione Tipo de origen como Instancia informática (VNIC).
3. Seleccione VM-2 en la lista.
4. Seleccione la VNIC que generará el tráfico (ya se rellena automáticamente si la VM solo tiene una VNIC).
5. Seleccione Dirección IPv4 de origen como 192.168.0.20 (también se rellena automáticamente si solo hay una dirección IPv4).
1. Haga clic en Mostrar las opciones avanzadas.
2. Aquí, puede especificar el puerto de origen si es necesario; para este ejemplo, déjelo definido en Usar cualquier puerto.
A continuación, rellenaremos la información de destino, que en este caso es Internet, concretamente, las IP públicas del repositorio yum (192.29.119.92 y 192.29.125.93), probaremos utilizando solo una de ellas.
1. Seleccione Enter IP address (Introducir dirección IP).
2. Introduzca la dirección IPv4 de destino 192.29.119.92.
3. Introduzca el puerto de destino como 443, ya que el acceso al repositorio se realiza mediante HTTPS.
1. Para analizar el tráfico tanto hacia delante como hacia atrás, mantenga la dirección como bidireccional.
2. Haga clic en Ejecutar análisis.
1. Los detalles de conexión se muestran a medida que se ejecuta el análisis.
2. Desplácese hacia abajo para realizar un seguimiento del progreso del análisis y espere hasta que finalice, lo que puede tardar uno o dos minutos.
El análisis ha finalizado. Comencemos a comprobar el resultado de Ruta de acceso anticipada.
1. El análisis muestra que VM-2 no puede acceder a Internet.
2. Este segmento resalta una configuración faltante que impide que el tráfico salga de VCN-2.
3. Para obtener más información, haga clic en Ver información de diagrama.
4. Esta tabla desglosa el flujo de enrutamiento y las comprobaciones de seguridad en cada paso de la ruta. Como se observó, el flujo es directo, ya que no hay saltos intermedios en el medio.
5. Si amplía, verá que no hay ninguna ruta definida para este tráfico.
1. Amplíe el mismo segmento para obtener más información.
2. No hay ningún enrutamiento configurado para enviar tráfico a través de Internet, para solucionarlo, debemos agregar una regla a la tabla de rutas de subred VM-2 (Tabla de rutas por defecto para VCN-2), anotarla, ya que la revisaremos en las siguientes tareas. En este punto, hemos identificado la fuente del problema.
3. Tenga en cuenta que la seguridad es Permitida.
  1. (3.a) Se permite el tráfico de salida, no hay problemas aquí.
  2. (3.b) El tráfico de entrada no es relevante en este caso, ya que el escenario se centra solo en el tráfico saliente.
1. La ruta de devolución no se analiza porque la comprobación de ruta de reenvío ha fallado.
2. Haga clic en Guardar el análisis.
3. Puede volver a ejecutar el análisis en cualquier momento. Volveremos a ejecutarlo más adelante en este tutorial después de solucionar el problema.
1. Vaya a VCN-2, donde se encuentra la VM de origen.
2. Haga clic en Enrutamiento.
3. Haga clic en Default Route Table for VCN-2.
Nota: Las tablas de rutas funcionan en el nivel de subred, lo que significa que las reglas definidas en la tabla se aplican a todos los recursos de esa subred. Las tablas de rutas también se pueden asociar a VNIC o direcciones IP específicas, así como mediante el enrutamiento por recurso. Sin embargo, esto no es relevante para nuestro tutorial. Para obtener más información, consulte Enrutamiento por recurso.
1. Haga clic en Reglas de ruta.
2. Actualmente, solo hay una regla de ruta configurada para enrutar el tráfico a VCN-1.
3. Para activar el acceso a Internet, haga clic en Agregar reglas de ruta.
1. Seleccione Gateway de NAT en Tipo de destino.
2. Introduzca 0.0.0.0/0 como Bloque de CIDR de destino.
3. Seleccione el gateway de NAT creado anteriormente.
4. Haga clic en Agregar reglas de ruta.
Inicie sesión en VM-2 e intente instalar telnet de nuevo.
1. Ejecute el siguiente comando.
```
sudo yum install telnet
```
2. La instalación está completa.
Vuelva al análisis para realizar otra ejecución y verifique que el problema se ha solucionado.
Haga clic en Analizar.
Espere a que finalice el análisis.
El análisis se ha completado. Vamos a comprobar el resultado de Ruta de avance.
1. El estado ahora muestra Alcanzable.
2. El salto 2 se ha realizado correctamente porque hemos agregado una regla de ruta que envía tráfico al gateway de NAT.
3. Haga clic en Ver información del diagrama.
4. Puede ver que el estado de enrutamiento para el salto 2 ahora es Reenviado (anteriormente, era Sin ruta).
Verificando la ruta de retorno, podemos ver que también es exitosa.

Tarea 4: Análisis de logs de flujo de VCN

Los logs de flujo de VCN ofrecen una capa adicional de visibilidad del comportamiento del tráfico. Este servicio le permite aumentar detalle del tráfico real que afecta a cada VNIC, lo que indica si se aceptó o rechazó en función de la lista de seguridad y las reglas del NSG, lo que le ayuda a solucionar problemas relacionados con la seguridad.

Además de la resolución de problemas, los logs de flujo de VCN son cruciales para supervisar la actividad de la red, capturar IP de origen/destino, puertos, protocolos y registros de hora, proporcionando también la telemetría detallada necesaria para auditorías e investigaciones de seguridad.

Ejemplo

Utilizaremos la siguiente arquitectura como ejemplo.

Nota: En este ejemplo, nos centramos únicamente en el registro en el punto Y, donde se encuentra el destino. Sin embargo, puede aplicar los mismos pasos para activar y analizar logs en el punto X (el origen del tráfico) para obtener visibilidad adicional del flujo de tráfico general.

Se ha producido un problema de red y utilizaremos los logs de flujo de VCN para rastrear y solucionar la causa raíz.

Problema: VM-1 no puede acceder a un sitio web alojado en VM-2.

Inicie sesión en VM-2 y ejecute el siguiente comando para comprobar si el sitio web se está ejecutando localmente.
```
curl localhost
```
Inicie sesión en VM-1 y ejecute el mismo comando para probar la conectividad a VM-2.
```
curl 192.168.0.20
```
Verá que la solicitud falla. En los siguientes pasos, utilizaremos logs de flujo VCN-2 para investigar la causa.
Ahora, vamos a activar los logs. Empezaremos por crear un filtro de captura, que es un juego de reglas simple que se utiliza en OCI para determinar qué tráfico de red se debe capturar para el registro o se debe reflejar en puntos de acceso de prueba virtual (VTAP).
1. Conéctese a la consola de OCI y asegúrese de que está en la región correcta.
2. Haga clic en el menú de hamburguesa (≡) en la esquina superior izquierda.
3. Haga clic en Networking.
4. Haga clic en Capturar filtros.
Haga clic en Crear filtro de captura.
1. Introduzca vcn-2-private-sn-logs como Nombre.
2. Seleccione Filtro de captura de log de flujo como Tipo de filtro.
3. Establezca la tasa de muestreo en 100 %. Esto define el porcentaje de flujos de red que se van a capturar; en este caso, queremos registrar todo el tráfico.
1. Deje todos los demás valores por defecto.
2. Haga clic en Crear filtro de captura.
Una vez creado el filtro de captura, haga clic en Copiar para copiar su OCID, ya que lo necesitará en los siguientes pasos.
Ahora, estamos listos para activar los logs.
1. Navegue hasta VCN-2.
2. Abra Subred privada, donde reside VM-2.
3. Haga clic en Monitoring (Supervisión).
4. Desplácese hacia abajo hasta la sección Logs.
5. Haga clic en los tres puntos (••••) situados junto a la categoría Registros de flujo.
6. Haga clic en Activar registro.
1. Seleccione Log Group (Grupo de logs). Si aún no tiene uno, cree un nuevo grupo de logs.
2. El nombre de log se rellena automáticamente.
3. Pegue el OCID de filtro de captura copiado anteriormente.
4. Haga clic en Activar registro.
Los logs de flujo ahora están activos.
Repita la misma prueba para generar tráfico mediante la ejecución del siguiente comando en VM-1.
```
curl 192.168.0.20
```
Vuelva a la sección Logs y haga clic en Nombre de log creado anteriormente.
1. Desplácese hacia abajo y verá los logs que muestran el tráfico que entra o sale de la red.
2. Haga clic en Acciones.
3. Haga clic en Explorar con Búsqueda de Log para aplicar filtros avanzados y reducir los resultados del log.
1. Aplique los siguientes filtros para que coincidan con nuestra conexión de prueba.
  - IP de origen (VM-1): data.sourceAddress = '10.0.0.10'.
  - IP de destino (VM-2): data.destinationAddress = '192.168.0.20'.
  - Puerto de destino (HTTP): data.destinationPort = 80.
2. Ajuste el rango de tiempo en Filtrar por tiempo si es necesario, o déjelo como el valor predeterminado de Últimos 5 minutos.
3. Haga clic en Buscar.
1. Revise los resultados que coincidan con los criterios de búsqueda.
2. Expanda los detalles del registro.
Para este registro en particular, puede ver información detallada sobre este flujo de tráfico. Entre los campos clave a tener en cuenta se incluyen:
1. Registro de hora: fecha y hora exactas en que el tráfico alcanzó la subred.
2. Detalles de conexión: como la dirección IP de origen, la dirección IP de destino y el número de puerto.
3. Acción: muestra cómo se manejó el tráfico; en este caso, era REJECT. Esto confirma la causa raíz del problema, no hay ninguna regla de seguridad para permitir el tráfico HTTP a VM-2.
Para permitir que el tráfico HTTP llegue a VM-2, tiene dos opciones:
- Lista de seguridad: se configura en el nivel del subred, lo que significa que todas las VNIC de una subred están sujetas al mismo conjunto de listas de seguridad.
- NSG: se aplica en el nivel de recurso (nivel de VNIC).
Aquí, lo vamos a permitir desde la lista de seguridad por defecto que ya está asociada a la subred VM-2.
1. Navegue hasta VCN-2, donde se encuentra la VM de destino.
2. Haga clic en Seguridad.
3. Haga clic en Default Security List for VCN-2.
1. Haga clic en Reglas de seguridad.
2. En la tabla, se muestra qué tráfico se permite. Todo lo demás, incluido HTTP, se deniega por defecto, ya que no hay ninguna regla que lo permita. Por eso VM-1 no puede acceder al sitio web alojado en VM-2.
3. Para solucionarlo, haga clic en Agregar reglas de entrada.
1. Introduzca 10.0.0.0/16 como CIDR de origen (este es el CIDR para VCN-1).
2. Seleccione TCP como Protocolo IP.
3. Defina 80 como Destination Port (Puerto de destino).
4. Haga clic en Agregar reglas de entrada.
Inicie sesión en VM-1 y ejecute el mismo comando para probar la conectividad a VM-2.
```
curl 192.168.0.20
```
Ahora debe ver que el sitio web es accesible.
Vuelva a los logs y repita los mismos pasos que antes para realizar una nueva búsqueda.
1. Aplique los siguientes filtros para que coincidan con nuestra conexión de prueba.
  - IP de origen (VM-1): data.sourceAddress = '10.0.0.10'.
  - IP de destino (VM-2): data.destinationAddress = '192.168.0.20'.
  - Puerto de destino (HTTP): data.destinationPort = 80.
2. Ajuste el rango de tiempo si es necesario o déjelo como valor predeterminado (Últimos 5 minutos).
3. Haga clic en Buscar.
1. Revise los resultados que coincidan con los criterios de búsqueda.
2. Expanda los detalles del registro.
Para este registro en particular, puede ver información detallada sobre este flujo de tráfico. Entre los campos clave a tener en cuenta se incluyen:
1. Registro de hora: fecha y hora exactas en que el tráfico alcanzó la subred.
2. Detalles de conexión: como IP de origen, IP de destino y número de puerto.
3. Acción: muestra cómo se gestionó el tráfico. Después de resolver el problema, ahora debe ver que el tráfico es ACCEPT (Aceptar).

Pasos Siguientes

Hemos explorado cómo solucionar problemas fundamentales de red en OCI examinando las configuraciones de arquitectura, enrutamiento y seguridad. Estas comprobaciones principales ayudan a resolver los problemas de conectividad más comunes. El siguiente tutorial se centrará en escenarios avanzados y casos de uso más reales.

Acuses de recibo

Autores - Anas Abdallah (Especialista en redes en la nube), Sachin Sharma (Especialista en redes en la nube)

Más recursos de aprendizaje

Explore otros laboratorios en docs.oracle.com/learn o acceda a más contenido de aprendizaje gratuito en el canal YouTube de Oracle Learning. Además, visite education.oracle.com/learning-explorer para convertirse en un explorador de Oracle Learning.

Para obtener documentación sobre el producto, visite Oracle Help Center.

Título e Información de Copyright

Troubleshoot Basic Network Issues in Oracle Cloud Infrastructure

G40750-01

Oracle y/o sus filiales.