Linux EHOSTUNREACH con OpenVPN: ¿qué salto siguiente ha fallado?

EHOSTUNREACH es una decisión local con tanta frecuencia como un fallo remoto. El núcleo puede rechazar un paquete porque una ruta dice que el destino es inalcanzable, porque el siguiente salto Ethernet nunca respondió o porque llegó un informe ICMP host-unreachable desde más adelante en la ruta. Cada origen vive en una tabla o caché distinta, y cada uno se corrige en un lugar distinto. Lea la ruta seleccionada y el estado del siguiente salto antes de tocar cifrados o reinstalar el túnel.

Elija la dirección y el namespace que el cliente usa realmente

Empiece fijando el destino y el namespace de red que produjo el error. Un cliente VPN puede ejecutarse en su propio namespace, y una consulta desde el namespace predeterminado consulta otra tabla de enrutamiento con reglas de política distintas.

La consulta debe usar el mismo contexto de origen, marca y tabla que la aplicación que falla, o puede responder una pregunta que nadie hizo. Para un par IPv4 ilustrativo, las comprobaciones de solo lectura son:

ip -4 route get 198.51.100.25
ip -4 neigh show 198.51.100.1
ip -4 route show table all | grep -w unreachable

Un resultado de una shell administrativa solo demuestra qué haría esa shell. Si el cliente establece una marca de cortafuegos o se enlaza a una VRF, repita la consulta con la marca correspondiente o dentro de la VRF, y compare la ruta seleccionada y el siguiente salto. La primera dirección que hay que confirmar es la del par en el perfil, no el clúster o servicio que nombra el usuario.

Una ruta inalcanzable explícita rechaza el paquete localmente

Una ruta de tipo unreachable es una respuesta local deliberada. Le dice al núcleo que descarte el paquete y devuelva EHOSTUNREACH al remitente, por eso el error aparece al instante y sin ningún tráfico que salga de la máquina. Alguien, o alguna automatización, puso esa ruta ahí a propósito.

Los tipos de ruta no son intercambiables. Blackhole descarta el paquete sin error al remitente, prohibit devuelve EACCES y unreachable devuelve EHOSTUNREACH. Un auxiliar de VPN que instala una ruta sumidero durante la reconexión puede, por tanto, producir una ráfaga de errores host-unreachable que desaparecen cuando el túnel sube, mientras que una ruta blackhole produciría tiempos de espera silenciosos en su lugar.

Busque el tipo en todas las tablas antes de culpar al extremo remoto. La regla que selecciona la tabla importa tanto como la ruta que contiene, y una ruta añadida a la tabla principal no ayudará a un cliente cuya regla de política envía su tráfico a otro sitio.

Un vecino muerto produce el mismo error en Ethernet

Cuando la ruta seleccionada usa una puerta de enlace en el enlace, la entrega necesita una dirección de capa de enlace resuelta. El núcleo envía una solicitud de vecino ARP o IPv6, y si no llega respuesta el paquete no se puede tramar. El envío falla entonces con EHOSTUNREACH aunque la ruta en sí sea válida.

La tabla de vecinos nombra la etapa. INCOMPLETE significa que una resolución aún está en curso, FAILED significa que el último intento no obtuvo respuesta, y REACHABLE o STALE significa que el núcleo tiene una dirección utilizable. Una entrada FAILED para la puerta de enlace VPN es un problema de entrega local, no una prueba sobre el lado lejano del túnel.

Lea la entrada del siguiente salto real, no la de la dirección de internet remota. Una dirección remota normalmente se alcanza a través de un router, así que no tendrá su propio registro ARP; preguntar por uno es un error de categoría que envía a la gente a buscar una entrada ausente que nunca debió existir.

Informes remotos y errores UDP asíncronos

EHOSTUNREACH también puede llegar de fuera. Un router que no puede reenviar el paquete puede enviar ICMP host unreachable, y el núcleo pasa ese informe al socket que posee el flujo. En ese caso la ruta y el vecino están bien, y el fallo pertenece a un salto más allá de la red local.

UDP dificulta la atribución. Un error devuelto por una llamada posterior de envío o recepción puede referirse a un datagrama anterior, así que la dirección y la hora de la llamada que falla pueden no coincidir con el paquete que desencadenó el informe. Un socket UDP conectado recibe el error una vez, y un socket no conectado puede no verlo nunca.

Por eso el momento pertenece a la evidencia. Anote cuándo apareció el error, qué dirección de par usó el socket y si el túnel acababa de reconectarse. Una ráfaga justo después de un cambio de ruta apunta a la tabla local; un error aislado minutos dentro de un flujo estable apunta a un informe de ruta.

Separe las capas antes de cambiar la criptografía

Tres preguntas clasifican el error. ¿Eligió el núcleo una ruta que rechaza el destino? ¿Eligió una ruta válida pero no resolvió el siguiente salto? ¿O llegó un informe desde más allá de la red local? Solo el tercer caso puede implicar el extremo lejano del túnel, y aun así no implica el cifrado.

Los problemas de autenticación y negociación aparecen como errores propios después de que el transporte llega al par. Cambiar un cifrado o reinstalar el cliente no puede arreglar una ruta unreachable local, y destruye la evidencia de ruta y vecino que necesitaría para la causa real.

Registre el destino, el namespace, la tabla seleccionada, el siguiente salto, el estado del vecino y la hora del error antes del primer cambio. Vuelva a ejecutar la misma consulta tras la corrección; una ruta que ahora apunta al túnel y una entrada de vecino que ahora se resuelve son una prueba más fuerte que un ping correcto a una dirección no relacionada.