Por qué fallan las búsquedas de nombres en un túnel OpenVPN enrutado

Un host responde al ping por dirección y falla toda búsqueda por nombre. El túnel está levantado y la ruta existe, así que la conclusión natural es que la VPN está mal configurada. Una conclusión más útil es que la búsqueda nunca fue enrutable: un túnel enrutado transporta unicast IP, mientras que la consulta era una difusión que buscaba un segmento que no existe al otro lado. En cuanto el desajuste de capas se hace visible, las soluciones se ordenan solas por coste.

Mito: el túnel está roto porque fallan los nombres

El síntoma convence porque todo lo que hay por encima de la capa de nombres funciona. Las direcciones se enrutan, la interfaz está levantada y el par responde a un ping. Lo que falló es un mecanismo de descubrimiento que nunca tuvo un camino por un enlace punto a punto, y eso es una afirmación distinta de un túnel roto. Separar esas dos afirmaciones es la mayor parte del diagnóstico.

Tratarlo como una avería del túnel lleva a editar el perfil sin efecto alguno. Añadir opciones, cambiar el cifrado o reinstalar el cliente deja la difusión exactamente donde estaba.

Nombra el mecanismo que falló antes de nombrar la solución. Una búsqueda que usa difusión necesita un segmento, mientras que una búsqueda que usa un resolutor necesita una dirección a la que preguntar.

Qué transporta TUN y qué no

Un dispositivo TUN es una interfaz IP, y eso es lo que lo hace enrutable. OpenVPN entrega al cliente una dirección y un conjunto de rutas, y desde ahí el cliente envía datagramas a un par. Nada en ese modelo crea un enlace compartido donde cada host oye cada trama.

El tráfico de descubrimiento no encaja en absoluto en ese modelo. Las consultas de nombre antiguas de Windows, los anuncios SSDP y las peticiones mDNS se envían a todos en un segmento en lugar de a un solo destino. Un enlace enrutado no tiene ningún «todos» al que enviar. Cada uno de esos mecanismos presupone un medio compartido.

El túnel puede por tanto estar sano mientras el descubrimiento falla por completo. Esa frase es la que hay que retener cuando alguien informa de que la VPN está caída.

El puente funciona eliminando la frontera

Un dispositivo TAP transporta tramas, y un puente lo engancha a un segmento LAN real. El cliente tiene entonces una dirección en ese segmento y escucha su tráfico de difusión. Por eso el puente parece curar el problema de los nombres. También hace que el cliente dependa de ese segmento para el direccionamiento.

La cura es eliminar la frontera de enrutamiento, no una capacidad nueva de nombres dentro del túnel. Todo lo que el segmento difunde ahora cruza también el enlace.

Para un laboratorio pequeño es un intercambio justo. En una plantilla distribuida rara vez lo es.

Empujar DNS y WINS es la reparación más estrecha

Dale al cliente un sitio concreto al que preguntar. dhcp-option DNS y dhcp-option DOMAIN apuntan los nombres internos a un servidor que conoce la zona, y un cliente Windows que aún depende de NetBIOS puede recibir un servidor WINS de la misma manera. El túnel sigue enrutado y el segmento se queda donde corresponde.

Dos condiciones deciden si eso funciona. El servidor nombrado debe responder por la zona, y la consulta debe estar permitida a través del túnel.

Prueba el resolutor desde el cliente y no desde el propio shell del servidor. Un resolutor que funciona en local no dice nada sobre lo que transporta el túnel.

Averigua qué capa falló

Haz ping a la dirección primero, luego resuelve el nombre y lee qué servidor respondió. Una respuesta negativa de un servidor que no aloja la zona se ve distinta de una consulta que nunca salió de la máquina. Un nombre que resuelve pero rechaza conexiones es un tercer problema por completo.

El multicast está detrás del mismo muro. Un grupo como 224.0.0.251 no se reenvía por un túnel enrutado de forma predeterminada, y una ruta para el grupo no basta sin un camino consciente de multicast o un reflector en la LAN.