RCON en Minecraft: acepta la integración sin exponer la consola
Antes de aceptar una integración de Minecraft que utilice RCON, pide pruebas de que solo el servicio previsto puede llegar a la consola remota, de que la credencial se puede sustituir y de que los usuarios no pueden enviar comandos arbitrarios a través de la integración. Ejecutar un comando demuestra conectividad. Falta comprobar quién tiene ese acceso y qué puede hacer con él.
Esta guía está dirigida a responsables de comunidades que encargan una web, un bot o una herramienta de administración para un servidor Java/Paper. Propone un procedimiento de aceptación en un entorno de pruebas propio. No se ha ejecutado en tu infraestructura ni constituye una configuración completa de despliegue.
Decide si la función necesita acceso a la consola
Paper define enable-rcon como acceso remoto a la consola; rcon.password y rcon.port establecen la credencial y el puerto de escucha. El puerto predeterminado documentado es 25575. Consulta la referencia de propiedades de Paper. Trata esta conexión como una capacidad de administración al revisar el presupuesto.
Empieza por la operación que necesita el producto. Mostrar si un servidor está disponible y ejecutar tareas de mantenimiento son requisitos distintos. Pide al desarrollador que justifique el acceso a la consola y valore una interfaz más limitada. No actives RCON solo porque una plantilla de integración incluya un campo de contraseña.
Imagina una web de un evento desde la que el personal autorizado puede enviar un aviso de preparación predefinido. El navegador debería solicitar esa acción concreta. Un servicio de confianza comprueba la identidad del miembro del equipo, selecciona el servidor acordado y construye el comando permitido. Entregar al navegador la contraseña RCON o aceptar un campo de comandos libre ampliaría mucho el alcance de esa función.
Dibuja el recorrido real hasta el puerto
Anota el proceso de origen, la dirección de destino, el puerto y los controles de red intermedios. Incluye los contenedores y cualquier traducción de direcciones. Decir «está en la misma máquina» no aclara qué procesos pueden llegar a cada servicio.
Utiliza estas opciones como punto de partida, sujetas a la revisión del responsable de infraestructura:
| Ubicación de la integración | Límite de acceso que conviene acordar |
|---|---|
| Dentro del contenedor de Minecraft | No añadir una publicación de puerto en el host solo para esta conexión |
| En otro contenedor | Red de contenedores restringida deliberadamente; revisar todos los servicios conectados |
| En un proceso del host Docker | Valorar una publicación accesible desde el propio host si hace falta |
| En otra máquina | Definir una ruta privada autenticada y cifrada y limitar sus orígenes |
Son requisitos de arquitectura, no garantías de RCON. Cuando haga falta una ruta cifrada, habrá que proporcionarla y mantenerla por separado. Deja por escrito quién se encarga y qué muestra la integración cuando esa ruta no está disponible.
La entrada de jugadores es otro acceso distinto. Si utilizas Velocity, las pruebas de acceso directo a los backends revisan ese recorrido. Superarlas no demuestra que la consola remota esté aislada.
Revisa los puertos Docker antes de probar contraseñas
En una red bridge habitual de Docker, 25575:25575 publica el puerto TCP en direcciones del host. Docker documenta la vinculación a localhost y una excepción: antes de 28.0.0, otros equipos del mismo segmento podían alcanzar puertos publicados en localhost. Contrasta versión y rutas con la documentación de publicación de puertos.
No copies una asignación de puertos como solución universal. Pide que se explique por qué existe, qué familias de direcciones resultan accesibles y qué orígenes quedan bloqueados. Una publicación limitada al host tampoco aclara si hay servicios no deseados conectados a la red del contenedor.
Si utilizas itzg/minecraft-server, ten en cuenta su comportamiento: activa RCON por defecto para tareas operativas y admite RCON_PASSWORD_FILE. Sus responsables advierten sobre la publicación externa de RCON. Sigue su configuración específica, sin asumir los valores de un servidor instalado directamente.
Mantén la credencial fuera de la interfaz del producto
Acuerda dónde se guarda, qué servicio la lee y quién puede cambiarla. No debería aparecer en archivos del navegador, capturas, incidencias de soporte ni registros normales de la aplicación. Revisa también las copias de configuración: proteger el secreto durante la ejecución sirve de poco si un archivo descargable lo expone.
Para el cliente de diagnóstico del operador, mcrcon admite variables de entorno, incluida MCRCON_PASS. Esto evita escribir la contraseña literal como argumento del comando, pero no convierte el entorno en un almacén seguro. La entrega debe describir cómo se proporciona el secreto y quién puede leerlo, no limitarse al nombre de una variable.
Ensaya la sustitución de la credencial antes de aceptar el trabajo. Actualiza ambos extremos según el procedimiento del despliegue, vuelve a conectar y comprueba que la contraseña anterior no permite abrir una sesión nueva. Revisa por separado cómo se cierran las sesiones existentes: no des por hecho que el cambio las termina inmediatamente. Anota cualquier reinicio o ventana de mantenimiento necesarios.
Exige una matriz de aceptación pequeña y explícita
Haz las comprobaciones solo en sistemas y direcciones propios o para los que tengas autorización. Acuerda un comando de diagnóstico inocuo, como list, y registra origen, resultado esperado y resultado observado. No incluyas el secreto en las pruebas documentales.
| Comprobación | Resultado exigido |
|---|---|
| Servicio previsto, credencial correcta | Conecta y recibe la respuesta de diagnóstico esperada |
| Servicio previsto, credencial incorrecta | No puede autenticarse ni ejecutar el comando |
| Equipo de prueba fuera de la red permitida | No puede establecer la conexión RCON |
| Servicio ajeno próximo a la integración | Acceso denegado salvo inclusión expresa en el límite de confianza |
| Nueva conexión con la credencial antigua tras sustituirla | La autenticación falla |
| Usuario web sin el rol de personal necesario | La aplicación rechaza la acción antes de enviar un comando |
Repite las pruebas de acceso para cada dirección pública relevante, incluida IPv6 si está configurada, y después de recrear contenedores. Una captura del cortafuegos aporta menos evidencia que el resultado observado desde otro punto de prueba. A la inversa, una conexión fallida podría deberse a que el servidor está apagado: acompáñala de la conexión correcta desde el origen previsto.
Define qué significa que la operación haya terminado
La interfaz debe distinguir un fallo de conexión, un fallo de autenticación y una operación cuyo resultado se desconoce. El tutorial RCON de mctools señala que las respuestas de comandos pueden estar vacías. Por tanto, una respuesta vacía no basta como criterio de aceptación de una acción del producto.
En el ejemplo del aviso, comprueba que el mensaje acordado aparece en el servidor de pruebas. Si la comunicación se interrumpe después del envío, aplica la política de revisión o reintento pactada. La web no debería mostrar éxito solo por haber enviado datos. Registra quién solicitó la acción, qué operación permitida pidió, el destino y el resultado, sin guardar credenciales.
Acepta la entrega cuando pasen la matriz de acceso, la sustitución del secreto y la comprobación de la acción en las versiones acordadas. Al encargar integraciones de Minecraft a medida, lleva estas operaciones y límites a la definición del proyecto. Incluye despliegue y responsabilidades de red en el alcance de infraestructura gestionada. Mineando presupuesta proyectos de pago individualmente; mantenimiento y soporte se acuerdan por separado.
