Los clientes de OpenVPN no se ven entre sí: ¿subred o net30?

Dos fallas no relacionadas producen la misma queja. En la primera, un cliente no llega a otro ni por dirección de túnel, porque las direcciones no están en una sola subred o el servidor no reenvía el tráfico entre pares. En la segunda, ping funciona y la lista de dispositivos de la aplicación queda vacía, porque el descubrimiento depende de broadcast que un túnel de capa 3 no puede transportar. Un solo ping las separa, y la solución de cada una no se parece en nada a la de la otra.

Un solo ping parte el problema en dos

Desde un cliente, haga ping a la dirección de túnel del otro cliente, no a su nombre ni a su dirección de LAN. Si falla, el problema es el reenvío o el direccionamiento y el descubrimiento es irrelevante hasta que se corrija. Si funciona, el reenvío ya funciona y lo que falta es broadcast o resolución de nombres.

ip addr show tun0

Lea la interfaz del cliente antes que nada, porque la máscara de red nombra la topología. Una /24 u otra máscara de subred significa un pool compartido; una /30 con dirección de par significa el diseño antiguo punto a punto, donde cada cliente tiene exactamente un vecino, el servidor.

net30 frente a subred, leído desde el lado del cliente

Con net30 el servidor reparte un bloque pequeño por cliente, así que no existe una ruta hacia la dirección de túnel de otro cliente salvo que el servidor la reenvíe. Con subred todo el pool es una red, cada cliente puede dirigirse a cualquier otro y el servidor reenvía entre ellos. Por eso una configuración de servidor puede verse sana mientras los ping entre pares fallan: nada está roto, simplemente los clientes no están en una sola red. El cliente ve un enlace que funciona y una dirección de par que no responde, lo que se lee como un cortafuegos pero es un diseño de direccionamiento.

Cambiar la directiva es una edición del lado del servidor más un reinicio, y se aplica a la siguiente conexión, no a las sesiones ya establecidas. Vuelva a conectar los clientes antes de juzgar el cambio. Si un equipo regenera la configuración desde una interfaz web, anote la directiva, el archivo y la fecha, y haga la edición mediante la interfaz cuando exista, porque una reconstrucción sobrescribirá una edición manual en el siguiente guardado.

client-to-client es una puerta aparte

Incluso dentro de una sola subred el servidor descarta los paquetes que llegan de un cliente y van dirigidos a otro, salvo que client-to-client esté activado. Esa palabra clave convierte al servidor en un reenviador del tráfico entre pares en lugar de un extremo que solo lo acepta. Es la segunda condición que la gente pasa por alto tras arreglar la topología.

No se extiende a broadcast. El ajuste reenvía unicast entre clientes; no convierte el túnel en un segmento compartido, y ninguna cantidad de ello entregará una consulta de descubrimiento multicast a todos los pares.

TUN frente a TAP, y qué puede transportar cada uno

Puentear un dispositivo tap hacia la LAN coloca a los clientes remotos en el dominio de broadcast de la oficina, lo que resuelve el descubrimiento por completo. El precio son las plataformas que no implementan TAP, un puente que debe existir en el servidor y un dominio de fallo donde una tormenta de broadcast en el cable de la oficina alcanza cada portátil remoto.

Para dos o tres estaciones de trabajo que necesitan resolución de nombres, una entrada hosts o una dirección unicast es mucho más barata que un puente. Recurra a TAP cuando un protocolo que no puede sustituir dependa del descubrimiento de capa 2, y no antes.

Clientes de la misma subred sin puente

Asignar una dirección del rango de la LAN no pone al cliente en el cable. El servidor enruta entre túnel y Ethernet, así que el ARP para esa dirección se detiene en la interfaz del servidor y el resto de la LAN nunca sabe dónde vive.

ip neigh add proxy 10.50.1.250 dev eth0

Proxy ARP cierra esa brecha haciendo que el servidor responda en nombre del cliente. Para un rango, parpd gestiona las entradas a medida que los clientes entran y salen, mientras que el sysctl net.ipv4.conf.eth0.proxy_arp=1 responde por todo lo que se enruta a otro sitio, lo cual es lo bastante amplio como para crear sus propias sorpresas en un segmento ocupado.

Elija la ruta que elija, quite NAT entre el túnel y el cable. Una regla MASQUERADE oculta exactamente la pregunta de direccionamiento que intenta responder. También deja a la siguiente persona una topología sobre la que no puede razonar desde el lado del cliente.

Antes de cambiar nada, capture un intento en el servidor con tcpdump -ni tun0 y confirme si el paquete del par llega siquiera. Que llegue y se descarte apunta a client-to-client; que nunca llegue apunta a topología o enrutamiento. El manual de OpenVPN 2.6 documenta ambas palabras clave y la topología predeterminada, algo que conviene contrastar con su versión antes de copiar una línea de un mensaje de foro.

• La interfaz tun muestra una máscara de pool en lugar de un par /30.
• Un ping directo a la otra dirección de túnel funciona antes de probar el descubrimiento.
• La configuración del servidor incluye client-to-client siempre que los pares deban intercambiar paquetes.
• Nombre el protocolo de descubrimiento que está probando en lugar de decir que la aplicación falla.
• Use TAP solo si todas las plataformas cliente del grupo lo admiten.
• Mantenga NAT fuera del camino entre túnel y LAN cuando importe el alcance dentro de la misma subred.