Escribir el extremo de la VPN en la lista de servidores de Minecraft parece lógico y falla siempre, porque esa dirección termina el túnel en lugar de alojar el juego. Un jugador conectado a la misma VPN ya tiene una ruta hacia el host del juego, así que la entrada debe nombrar el host y el puerto en el que escucha el juego. Acierta esos dos y el resto del problema es disponibilidad normal del servicio, una lista de comprobación mucho más corta de lo que parece al principio.

Dos direcciones, dos tareas

Una dirección es infraestructura pública: el extremo de transporte que lleva paquetes cifrados entre pares. La otra es una dirección privada de la máquina que ejecuta el servidor dedicado. No son intercambiables, y sustituir una por otra produce una conexión rechazada o un tiempo de espera agotado que parece un problema de cortafuegos.

RoleAddressWhere it belongs
Public transport endpoint203.0.113.40VPN client configuration, never the game
Game host on the VPN10.60.0.20Server address field, with the port
Player peer10.60.0.30Assigned by the tunnel, nothing to type

Con el puerto predeterminado, el jugador escribe 10.60.0.20:25565 y nada más. La página de descarga del servidor Java de Mojang indica 25565 como puerto predeterminado, y al operador que cambió el puerto hay que creerle en lugar de dudar de él por un tutorial antiguo.

Convierte esa dirección en un servicio real

Una dirección alcanzable es necesaria y no suficiente. El servidor dedicado tiene que estar en marcha, tiene que ser compatible con la versión que ejecuta el cliente del jugador y tiene que escuchar en una dirección a la que el túnel pueda entregar. Un proceso ligado solo a loopback no se vuelve alcanzable porque alguien haya añadido otra dirección a la máquina.

Confirma el escucha antes de tocar un cortafuegos:

ss -lntp | grep 25565
nc -vz 10.60.0.20 25565

La primera línea muestra a qué se ha ligado realmente el proceso, y la segunda muestra si un par puede completar el saludo TCP. Cuando la vinculación es 127.0.0.1, ninguna cantidad de configuración de VPN cambia el resultado, y ese único detalle explica una cantidad sorprendente de informes de «la VPN está rota».

Política de pares, cortafuegos y ruta de vuelta

Dos preguntas de permisos se sientan encima del escucha. La configuración de pares de la VPN tiene que permitir tráfico entre los dos pares, y el cortafuegos del host del juego tiene que aceptar el puerto del juego desde ese par. Mantén ambos acotados al servicio del juego y a los pares autorizados en lugar de desactivar el cortafuegos del host, que cambia una regla de dos líneas por un problema mucho mayor. Las reglas estrechas son además la única versión de esto que supera una revisión de seguridad sin un párrafo de justificación.

Luego recuerda qué demuestra un ping correcto. Llegar a la puerta de enlace de la VPN, o recibir respuesta del host del juego, solo demuestra que ICMP cruzó el camino. Una conexión de juego necesita el puerto concreto abierto en ambas direcciones, y la ruta de vuelta importa tanto como la de ida.

Cuando el servidor está detrás de la puerta de enlace

El ejemplo anterior tiene el servidor de juego como par, lo que mantiene trivial el plan de direcciones. Si el servidor vive en una LAN detrás de una puerta de enlace VPN, el jugador necesita la dirección privada enrutable del servidor, la puerta de enlace necesita el reenvío configurado para esa LAN, y el host de la LAN necesita una ruta de vuelta hacia el cliente tunelizado. Si te pierdes la ruta de vuelta, el saludo muere a mitad de camino, que es el fallo más confuso de los tres.

No copies la dirección de par del ejemplo en otra máquina para imitar esta topología. Las direcciones de un ejemplo describen roles, y reutilizar una en dos roles crea un solapamiento que el enrutamiento no puede resolver.

Descubrimiento, cuentas y qué no cambiar

El descubrimiento automático de LAN es una comodidad construida sobre anuncios. Una VPN enrutada no tiene por qué transportar esas difusiones, así que una entrada ausente en la lista de LAN no dice nada sobre si la dirección privada explícita funciona. Escribe la dirección y luego juzga. Si conecta, el hueco de descubrimiento es una molestia de usabilidad y no un fallo, y puede documentarse como tal en lugar de investigarse.

Mantén intactas también la autenticación normal de la cuenta y la política de admisión del juego. Una ruta privada que funciona concede un camino, no una pertenencia, y ningún reordenamiento de prioridades de adaptador sustituye a identificar el destino que el cliente debería estar usando.

Artículos relacionados