Cuelgue de la conexión

Síntoma: su red virtual en la nube (VCN) se conecta a su red local existente mediante una VPN de sitio a sitio u Oracle Cloud Infrastructure FastConnect. Los hosts de un lado de la conexión pueden hacer ping a los hosts del otro lado, pero el tráfico normal que usa la conexión se bloquea. Por ejemplo:

• Puede aplicar un SSH a un host entre la conexión, pero después de iniciar sesión en el host, la conexión se bloquea.
• Puede iniciar una conexión a la informática de redes virtuales (VNC), pero la sesión permanece colgada.
• Puede iniciar una descarga de SFTP, pero la descarga permanece colgada.

Problema general: es probable que el descubrimiento de la unidad de transmisión máxima de la ruta (PMTUD) no funcione en uno de los lados de la conexión o en ambos. Debe funcionar en ambos lados de la conexión para que puedan saber si están intentando enviar paquetes demasiado grandes para la conexión y ajustarlos según corresponda. Para obtener una breve visión general de la unidad de transmisión máxima (MTU) y del PMTUD, consulte Visión general de la MTU y Visión general del PMTUD.

Soluciones para corregir el PMTUD:

En el siguiente diagrama se muestra un escenario de ejemplo con la red local conectada a su VCN a través de una VPN de sitio a sitio y tiene referencias que representan cada parte de la solución.

1. Asegúrese de que los hosts utilizan el PMTUD: si los hosts de la red local no utilizan PMTUD (es decir, si no definen el indicador No fragmentar en los paquetes), no tienen forma de detectar si están enviando paquetes demasiado grandes para la conexión. Las instancias de Oracle de la conexión utilizan el PMTUD por defecto. No cambie esa configuración en las instancias. Además, asegúrese de que los servidores tengan una regla de firewall para permitir los mensajes ICMP de tipo 3 y código 4.

2. Asegúrese de que tanto las listas de seguridad de la VCN como los firewalls de instancia permitan los mensajes ICMP de tipo 3 y código 4: cuando PMTUD está en uso, los hosts de envío reciben un mensaje ICMP especial si envían paquetes demasiado grandes para la conexión. Al recibir el mensaje, el host puede actualizar dinámicamente el tamaño de los paquetes para que se ajuste a la conexión. Sin embargo, para que sus instancias reciban estos importantes mensajes ICMP, debe configurar tanto las listas de seguridad para la subred de la VCN como los firewalls de instancia para que los acepten.

   Consejo
   
   Si utiliza reglas de lista de seguridad con estado (para el tráfico TCP, UDP o ICMP), no necesita asegurarse de que la lista de seguridad tenga una regla explícita para permitir mensajes ICMP de tipo 3 código 4 porque el servicio de Networking realiza un seguimiento de las conexiones y permite automáticamente estos mensajes. Las reglas sin estado necesitan una regla explícita en la lista de seguridad de entrada para los mensajes ICMP de tipo 3 y código 4. Confirme que los firewalls de instancia están configurados correctamente.

   Para comprobar si un host recibe los mensajes, consulte Búsqueda del punto en el que se interrumpe el PMTUD.

3. Asegúrese de que el enrutador local cumple con el indicador No fragmentar: si el enrutador no cumple el indicador y, por lo tanto, ignora el uso del PMTUD, envía paquetes fragmentados a las instancias de la VCN. Esto se debe evitar (consulte Motivos por los que evitar la fragmentación). Lo más probable es que las listas de seguridad de la VCN estén configuradas de tal forma que reconozcan solo el fragmento inicial y borren los restantes, lo que hace que la conexión se bloquee. En su lugar, el enrutador debe utilizar el PMTUD y mantener el indicador No fragmentar para determinar el tamaño correcto de los paquetes no fragmentados que se enviarán a través de la conexión.

Siga leyendo para obtener una breve visión general de la MTU y el PMTUD, y cómo comprobar si el PMTUD funciona en ambos lados de la conexión de red.

Es posible que se pregunte por qué habría que evitar la fragmentación. En primer lugar, afecta negativamente al rendimiento de la aplicación. La fragmentación requiere el reensamblaje de los fragmentos y la retransmisión de los fragmentos perdidos. Ambos procedimientos requieren el uso de recursos de tiempo y CPU.

En segundo lugar, solo el primer fragmento contiene la información del puerto de origen y de destino. Esto significa que tanto los cortafuegos como las listas de seguridad de su VCN borran los otros paquetes, ya que normalmente están configurados para evaluar la información del puerto. Para que la fragmentación funcione con los firewalls y las listas de seguridad, tendría que configurarlos para que sean más permisivos que de costumbre, lo cual no es recomendable.

Las comunicaciones entre dos hosts de una red de protocolo de internet (IP) utilizan paquetes. Cada paquete tiene una dirección IP de origen y de destino, y una carga útil de datos. Cada segmento de red entre los dos hosts tiene una unidad de transmisión máxima (MTU) que representa el número de bytes que puede llevar un único paquete.

El tamaño estándar de la MTU de Internet es de 1500 bytes. Esto también es así para la mayoría de las redes principales y muchas redes corporativas (y sus redes Wi-Fi). Algunos centros de datos, incluidos los de Oracle Cloud Infrastructure, pueden tener una MTU de mayor tamaño. Todas las instancias informáticas de OCI utilizan una MTU de 9000 por defecto. En un host Oracle Linux 8, puede utilizar el comando ip address show para mostrar la MTU de la conexión de red de ese host (o utilizar ip link en Red Hat Linux). Por ejemplo, esta es la salida de una instancia de Oracle Linux 8 (la MTU se resalta en cursiva roja):

ip address show <interface-x>
<interface-x>: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 01:00:5E:90:10:10 brd ff:ff:ff:ff:ff:ff
    ... 

Para comparar, a continuación se muestra la salida de un host de Oracle Linux 8 conectado a una red corporativa:

ip address show <interface-y>
<interface-y>: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 01:00:5E:90:10:20 brd ff:ff:ff:ff:ff:ff
    ...

Tenga en cuenta que lo más habitual es que la MTU sea de 1500 bytes.

Si el host se conecta mediante una VPN corporativa, la MTU será incluso de menor tamaño, ya que el túnel de la VPN debe encapsular el tráfico dentro de un paquete IPSec y enviarlo a través de la red local. Por ejemplo:

ip address show <interface-z>
<interface-z>: flags=81d1<UP,POINTOPOINT,RUNNING,NOARP,PROMISC,MULTICAST> mtu 1300 
... 

¿Cómo se presenta en los dos hosts el tamaño de un paquete que pueden enviar entre sí? Para muchos tipos de tráfico de red, como HTTP, SSH y FTP, los hosts utilizan TCP para establecer nuevas conexiones. Durante el establecimiento de comunicación inicial de tres vías entre dos hosts, cada uno envía el tamaño máximo de segmento (MSS) para saber cuál es su carga útil. Esto es de menor tamaño que la MTU. El TCP se ejecuta dentro del protocolo de internet (IP), y es por este motivo por el que se le denomina TCP/IP. Los segmentos para la TCP serían el equivalente a lo que los paquetes son para el IP).

Con la aplicación tcpdump, puede ver el valor MSS compartido durante el establecimiento de comunicación. A continuación se muestra un ejemplo de tcpdump (con MSS resaltado en cursiva roja):

12:11:58.846890 IP 192.168.0.25.22 > 10.197.176.19.58824: Flags [S.], seq
2799552952, ack 2580095593, win 26844, options [mss 1260,sackOK,TS val
44858491 ecr 1321638674,nop,wscale 7], length 0

El paquete anterior proviene de una conexión SSH a una instancia desde un equipo portátil conectado a una VPN corporativa. La red local que el portátil utiliza para su conexión a Internet tiene una MTU de 1500 bytes. El túnel de VPN aplica una MTU de 1300 bytes. A continuación, al intentar la conexión SSH, el TCP (que se ejecuta dentro de la conexión IP) indica a la instancia de Oracle Cloud Infrastructure que admite segmentos TCP de 1260 bytes o menos. Con una conexión VPN corporativa, el portátil conectado a la VPN suele tener la MTU y MSS de menor tamaño en comparación con cualquier elemento con la comunicación a través de internet.

Un caso más complejo es cuando los dos hosts tienen una MTU más grande que un enlace de red intermedio entre ellos no conectado directamente a ninguno de ellos. En el siguiente diagrama se muestra un ejemplo.

En el ejemplo se muestran dos servidores, cada uno conectado directamente a su propia red enrutada que admite una MTU de 9000 bytes. Los servidores están en diferentes centros de datos. Cada uno de los centros de datos se conecta a Internet y admite una MTU de 1500 bytes. Un túnel IPSec de VPN de sitio a sitio conecta los dos centros de datos. El túnel cruza internet, de modo que el interior del túnel tenga una MTU más pequeña que internet. En este diagrama, la MTU tiene 1380 bytes.

Si los dos servidores intentan comunicarse (con SSH, por ejemplo), durante el establecimiento de comunicación de tres vías concordarán en un MSS alrededor de 8960. La conexión SSH inicial puede realizarse correctamente, ya que los tamaños máximos de paquetes durante la configuración inicial de la conexión SSH suelen ser inferiores a 1380 bytes. Cuando un lado intenta enviar un paquete más grande que el enlace más pequeño entre los dos puntos finales, el descubrimiento de la MTU de la ruta (PMTUD) adquiere una importancia crucial.

La detección de MTU de ruta se define en RFC 1191 y RFC 8899. Funciona con la petición a los dos hosts que se comuniquen para definir un indicador No fragmentar en los paquetes que envían cada uno. Si un paquete de uno de estos hosts alcanza un enrutador donde la interfaz de salida (o saliente) tiene una MTU más pequeña que la longitud del paquete, el enrutador lo anula. El enrutador también devuelve un mensaje de ICMP tipo 3 y código 4 al host. Este mensaje indica específicamente "Destino inaccesible, fragmentación necesaria y se ha configurado no fragmentar" (en RFC 792). El enrutador indicará de forma eficaz al host "has especificado no fragmentar paquetes de gran tamaño y este lo es. Por lo que no lo estoy enviando". El enrutador también indica al host el tamaño máximo permitido de paquetes a través de esa interfaz de egreso. El host de envío ajusta el tamaño de sus paquetes salientes para que sea de menor tamaño que el valor proporcionado por el enrutador en el mensaje.

En este ejemplo se muestra el resultado cuando una instancia intenta hacer ping a un host (203.0.113.2) a través de Internet con un paquete de 8000 bytes y el indicador No fragmentar (es decir, con el PMTUD en uso). El mensaje de ICMP devuelto se resalta en cursiva roja:

ping 203.0.113.2 -M do -s 8000

PING 203.0.113.2 (203.0.113.2) 8000(8028) bytes of data.
From 10.0.0.2 icmp_seq=1 

Frag needed and DF set (mtu = 1500)

La respuesta es exactamente lo que debe esperar. El host de destino está en internet, que tiene una MTU de 1500 bytes. Aunque la conexión de red local del host de envío tiene una MTU de 9000 bytes, el host no puede acceder al host de destino con el paquete 8000 bytes y obtiene un mensaje de ICMP como corresponde. El PMTUD funciona correctamente.

A modo de comparación, aquí se muestra el mismo ping, pero el host de destino se encuentra al otro lado de un túnel de IPSec de la VPN de sitio a sitio:

ping 192.168.6.130 -M do -s 8000
PING 192.168.0.130 (192.168.0.130) 8000(8028) bytes of data.
From 192.0.2.2 icmp_seq=1 Frag needed and DF set 

(mtu = 1358)

Aquí, el enrutador VPN ve que debe enviar este paquete a su destino; la interfaz saliente es un túnel VPN. El túnel pasa por internet, por lo que debe ajustarse dentro del enlace de MTU de 1500 bytes de internet. Como resultado, el interior del túnel solo permite paquetes de hasta 1360 bytes (que el enrutador bajó a 1358, lo que puede hacer que las cosas sean más confusas).

Si el PMTUD no funciona en algún lugar de la conexión, debe averiguar por qué y dónde está roto. Normalmente, se debe a que el paquete de ICMP tipo 3 y código 4 (del enrutador con el enlace restringido que no se puede ajustar al paquete) nunca vuelve al host de envío. Esto puede suceder si algo bloquea ese tipo de tráfico entre el host y el enrutador, y en cualquier lado del túnel de VPN (u otro enlace de MTU restringido).

-M pmtudisc_opt
Select Path MTU Discovery strategy. pmtudisc_option may be either do
(prohibit fragmentation, even local one), want (do PMTU discovery, fragment
locally when packet size is large), or dont (do not set DF flag).

ping -M do

 -s 1500 192.168.6.130
PING 192.168.0.130 (192.168.0.130) 1500(1528) bytes of data.
From 10.0.0.2 icmp_seq=1 

Frag needed and DF set (mtu = 1358)

Oracle recomienda utilizar el PMTUD. Sin embargo, en algunas situaciones, es posible configurar los servidores para que no necesiten basarse en él. Considere el caso de instancias de su VCN que se comunican a través de la VPN de sitio a sitio con hosts de la red local. Conoce el rango de direcciones IP para la red local. Puede agregar una ruta especial a las instancias que especifican la MTU máxima que se debe usar al comunicarse con los hosts de ese rango de direcciones. La comunicación de instancia a instancia en la VCN sigue utilizando una MTU de 9000 bytes.

La siguiente información muestra cómo definir esa ruta en una instancia de Linux.

La tabla de rutas por defecto de la instancia suele tener: la ruta de forma predeterminada (para la puerta de enlace por defecto) y una ruta local (para la subred local). Por ejemplo:

ip route show
default via 10.0.6.1 dev ens3
10.0.6.0/27 dev ens3  proto kernel  scope link  src 10.0.6.9

Puede agregar otra ruta que apunte al mismo gateway por defecto, con el rango de direcciones de la red local y una MTU más pequeña. Por ejemplo, en el siguiente comando, la red local es 1.0.0.0/8, el gateway por defecto es 10.0.6.1 y el tamaño máximo de la MTU es de 1300 para los paquetes enviados a la red local.

ip route add 1.0.0.0/8 via 10.0.6.1 mtu 1300

La tabla de rutas actualizada tiene este aspecto:

ip route show
default via 10.0.6.1 dev ens3
1.0.0.0/8 via 10.0.6.1 dev ens3  mtu 1300
10.0.6.0/27 dev ens3  proto kernel  scope link  src 10.0.6.9

Dentro de la VCN, la comunicación de instancia a instancia sigue usando la MTU de 9000 bytes. Sin embargo, la comunicación a la red local utiliza un máximo de 1300. En este ejemplo, se supone que ninguna parte de la conexión entre la red local y la VCN utiliza una MTU de menos de 1300.