¿Lista de juegos LAN vacía con OpenVPN? Revise la ruta de descubrimiento

Hacer ping a la dirección de túnel de otro jugador y ver su juego alojado son dos logros distintos. La lista del lobby suele depender de un intercambio de descubrimiento escrito para una sola red local, mientras que la sesión de juego es una conexión normal a una dirección y un puerto. Tratar una lista vacía como un fallo de enrutamiento te envía hacia un puente que quizá no necesites, así que separa las dos preguntas antes de cambiar nada.

Separe unirse a una sesión de encontrarla

Una unión fallida apunta a rutas, reglas de cortafuegos y un servicio que escucha. Una unión correcta con una lista vacía apunta al descubrimiento o a la dirección que lleva el anuncio. Esos dos resultados conducen a trabajos completamente distintos, y solo puedes distinguirlos probando el primero a propósito.

Anota el resultado antes de tocar la configuración de la VPN. Es la prueba más barata de toda la investigación y elimina la mitad del espacio de diseño. Anota también la dirección que usaste, porque se convierte en el punto de referencia para cada prueba posterior. Sin esa línea en tus notas, la siguiente comparación es una conjetura.

Prueba una unión directa antes de tocar el túnel

Si el juego ofrece una opción de conexión directa, usa la dirección de túnel del anfitrión y el puerto documentado del juego, y deja intactas la autenticación propia del juego y las reglas de cortafuegos del anfitrión. Una unión correcta reduce el problema al descubrimiento. Una unión fallida sigue necesitando su propia investigación, y ningún relé la arreglará.

No supongas que el puerto de descubrimiento y el puerto de sesión son el mismo número. Los juegos suelen anunciarse en un puerto UDP y aceptar jugadores en otro, y un relé construido para el equivocado produce una lista que sigue vacía.

Comprueba también qué adaptador eligió el proceso de alojamiento. Un proceso ligado a la dirección de la LAN doméstica anunciará esa dirección, y el jugador remoto no puede enrutar hacia ella aunque llegue el anuncio. La lista puede llenarse y la unión puede fallar solo por ese motivo.

Entiende dónde se detiene la difusión

Un túnel TUN enrutado transporta paquetes IP entre pares y no reproduce la difusión local en la red de cada par. La dirección de difusión limitada 255.255.255.255 se queda dentro de la interfaz que la emite, y una difusión dirigida a la subred es un caso aparte, no una licencia general para que los routers inunden anuncios.

Eso es una propiedad del diseño, no un defecto que se parchee con una opción. OpenVPN y su opción client-to-client gobierna el tráfico entre pares dentro del túnel y no es un relé de descubrimiento, aunque se proponga para ese fin en muchos hilos. Un relé es un componente aparte con su propia configuración y sus propios modos de fallo. Suponer que una opción existente ya lo cubre es la forma más habitual de que esta investigación se atasque.

El descubrimiento por multicast tiene el mismo problema con otra clase de direcciones, y necesita enrutamiento multicast o un relé en lugar de una excepción de difusión.

Cuando un relé esté justificado, mantenlo estrecho

Si el descubrimiento automático es un requisito, identifica primero el intercambio real: difusión o multicast, dirección de destino, puerto UDP, la interfaz que lo envía y la dirección dentro de la respuesta. Un relé adecuado al protocolo y limitado a esos cinco hechos es mucho más estrecho que extender un segmento Ethernet entero.

Reenviar el paquete sin cambios puede seguir siendo insuficiente. Si la carga útil le dice al receptor que se conecte a una dirección que no puede alcanzar, el relé entrega una respuesta inútil, por eso conviene probar la interfaz propia del juego o el ajuste de dirección anunciada antes de que exista ningún relé.

Limita el relé a las interfaces y pares que lo necesitan, y define cómo encuentran las respuestas al solicitante. Repetir difusiones no relacionadas expone otros servicios locales y crea bucles que después son dolorosos de depurar.

Puente solo cuando el diseño necesite Ethernet

Las tramas Ethernet viajan dentro de TAP, así que un túnel TAP puede pertenecer a un dominio de difusión deliberadamente puenteado. Simplemente cambiar dev tun por dev tap no construye ese puente, no hace compatible la configuración del servidor y no hace que la aplicación elija la nueva interfaz. La guía de puentes de OpenVPN describe el arreglo más amplio, no una cura para un lobby vacío.

El puente también aplana el plan de direcciones, por eso la decisión merece una razón más allá de la impaciencia. Dos redes que estaban separadas se convierten en una, y cada servicio de cada lado empieza a ver las difusiones del otro lado. Esa consecuencia pertenece al registro de cambios antes de que alguien la active. No hay ninguna regla que obligue a los clientes de juego a estar en un rango 192.168; elige un plan sin solapamiento y comprueba las restricciones del juego concreto en lugar de renumerar el túnel porque lo hizo una publicación de foro.

Al final mantén separados los dos resultados: si se puede unir al anfitrión y si la respuesta de descubrimiento anuncia un destino que el otro jugador realmente puede usar. Arreglar el segundo sin confirmar el primero es como la gente acaba manteniendo un puente para un problema que nunca tuvo que ver con la difusión.