Velocity y Paper: comprueba que nadie entra sin pasar por el proxy
Antes de abrir una red con Velocity y Paper, comprueba dos cosas por separado: que los jugadores entran por el proxy con la identidad correcta y que nadie puede llegar directamente a los servidores de juego desde una red no autorizada. El reenvío moderno añade una comprobación del origen de los datos del jugador, pero no sustituye al cortafuegos. La guía de seguridad de Velocity recomienda combinar esas protecciones.
Esta guía propone una prueba de aceptación para responsables de comunidades que preparan una red Java con cuentas autenticadas. Llamaremos backend a cada servidor Paper situado detrás del proxy, por ejemplo el lobby o el survival. El alcance es Paper actual con Velocity modern forwarding; las redes con clientes antiguos, Floodgate o servidores modded necesitan revisar además su compatibilidad y su flujo de identidad. No hemos ejecutado este ensayo en tu infraestructura.
Dibuja el recorrido que vas a comprobar
Escribe una ficha con el punto de entrada público, los backends y sus puertos, las direcciones que utiliza el proxy para alcanzarlos y quién administra cada regla de red. Incluye cualquier segunda dirección pública de las máquinas. Un nombre DNS cómodo para los jugadores no demuestra que las otras rutas estén cerradas.
Para el ejemplo, imagina una red con un proxy, un lobby y un survival. La decisión de apertura exige que funcionen los dos recorridos previstos: conexión inicial al lobby y traslado al survival. No basta con que aparezca la red en la lista multijugador.
Añade a la ficha:
- Compilaciones de Velocity y Paper y versiones de los plugins implicados en acceso o permisos.
- Un responsable del ensayo y otro de autorizar la apertura, aunque ambos papeles recaigan en la misma persona.
- Una cuenta de prueba con inventario y permisos conocidos, sin privilegios administrativos innecesarios.
- El procedimiento para recuperar la configuración anterior manteniendo el acceso público cerrado.
Si estás encargando la infraestructura gestionada, esta ficha sirve para acordar qué rutas y evidencias debe entregar el equipo técnico.
Elige el aislamiento para tu despliegue
La documentación de Velocity contempla escuchar en 127.0.0.1 cuando proxy y backends comparten una máquina de confianza, o utilizar un túnel cifrado entre máquinas. En una instalación distribuida también debes mantener las reglas de red alineadas con los proxies autorizados. Consulta las opciones de aislamiento antes de aplicar una receta.
En la ficha, convierte la elección en una condición verificable: «el puerto del survival solo acepta conexiones desde el recorrido autorizado». Pide al administrador que documente cómo se cumple, incluidas las reglas del proveedor y cualquier publicación de puertos de contenedores. Estar en el mismo servidor físico no basta para dar por válida una receta de localhost en cualquier arquitectura.
No abras temporalmente el backend a todo Internet para resolver un fallo de conexión del proxy. Mantén el bloqueo y comprueba primero direcciones, puerto, interfaz de escucha y ruta desde el origen autorizado. Prueba únicamente sistemas propios o para los que tengas autorización.
Revisa la autenticación sin confundir los tres ajustes
En el diseño de este artículo, online-mode = true en velocity.toml hace que el proxy autentique a los jugadores. El archivo también define player-info-forwarding-mode = "modern" y la ubicación del secreto mediante forwarding-secret-file. Son opciones documentadas en la referencia de Velocity.
En cada backend, la configuración oficial de modern forwarding indica online-mode=false en server.properties y settings.bungeecord: false en spigot.yml. El backend delega la autenticación en el proxy; este paso solo tiene sentido dentro del diseño protegido que estás comprobando.
En config/paper-global.yml, revisa estas claves existentes, sin sustituir todo el archivo:
| Clave | Condición para este diseño |
|---|---|
proxies.velocity.enabled | true |
proxies.velocity.online-mode | true, igual que en el proxy |
proxies.velocity.secret | Coincide con el secreto configurado en Velocity |
La referencia global de Paper documenta cómo estos ajustes afectan a los datos y UUID del jugador. El UUID es el identificador que debes comprobar, además del nombre visible. No confundas proxies.velocity.online-mode con el online-mode de server.properties: en este diseño tienen valores distintos por motivos distintos.
Comprueba el secreto por un canal administrativo privado; en el informe solo anota «coincide» o «no coincide». No pegues su contenido en capturas, tickets o repositorios. Reinicia los componentes afectados dentro de la ventana de mantenimiento y vuelve a verificar la configuración aplicada.
Ejecuta una matriz de aceptación pequeña
Prepara dos puntos de prueba: uno externo a las redes autorizadas y otro desde el recorrido del proxy. Anota fecha, origen, destino y resultado observado. Los resultados de esta tabla son los esperados, no mediciones realizadas.
| Prueba | Resultado que permite continuar |
|---|---|
| Conexión legítima por el proxy | La cuenta entra al lobby y llega al survival |
| Comprobación de identidad en cada backend | UUID, inventario y permisos coinciden con lo previsto para esa cuenta y servidor |
| Conexión TCP directa desde fuera al puerto de cada backend | No se establece la conexión |
| Acceso desde el recorrido autorizado | El proxy alcanza cada backend previsto |
| Reinicio y repetición | Se mantienen tanto los accesos permitidos como los bloqueados |
La prueba negativa de red es más exigente que «Minecraft me expulsa». Si se establece TCP y después el juego rechaza al cliente, has observado un rechazo de aplicación; todavía no has demostrado el aislamiento de red acordado. Tampoco interpretes un tiempo de espera aislado como una prueba completa: confirma el destino y el funcionamiento del backend mediante la prueba positiva correspondiente.
En un entorno de ensayo aislado puedes añadir una comprobación del secreto: utiliza un proxy de prueba autorizado con un secreto deliberadamente distinto, verifica que no permite entrar y repite con el valor correcto. No cambies el secreto de producción para hacer esta prueba ni abras sus puertos. Registra solo el resultado.
Decide qué hacer cuando falla una comprobación
Si el lobby funciona y el survival no, compara las dos rutas y configuraciones. Ese contraste acota la investigación; no demuestra por sí solo qué ajuste falla. Si aparece un inventario vacío o un rango inesperado, detén la apertura e investiga la identidad y los datos asociados antes de crear perfiles nuevos o mover archivos de jugador.
Si una ruta directa sigue abierta, el resultado es «pendiente de corregir», aunque el reenvío moderno rechace la entrada. Si todo funciona antes del reinicio y cambia después, revisa qué configuración carga realmente el proceso y quién mantiene las reglas persistentes. Guarda el informe anterior y repite solo las pruebas afectadas junto con una conexión legítima completa.
La entrega final debe incluir la matriz cumplimentada, versiones, responsables, incidencias pendientes y condiciones de repetición: un nuevo backend, un cambio de alojamiento o un cambio de autenticación requieren revisar el recorrido. Este ensayo no certifica capacidad, protección frente a DDoS ni ausencia de fallos en plugins.
Para código propio que intervenga en accesos, permisos o identidad, acuerda también esas comprobaciones dentro del desarrollo de Minecraft. Mineando trabaja con proyectos pagados y alcance individual; el soporte posterior se acuerda por separado.
