Configurar nLogin en Bungeecord

Esta guía explica cómo configurar nLogin en una red Bungeecord, donde tienes múltiples servidores conectados a través de un proxy. La configuración en Bungeecord es más compleja que en servidor único, pero permite que los jugadores se autentiquen una sola vez y accedan a todos los servidores de la red.

¿Qué es una Red Bungeecord?

Bungeecord es un proxy que conecta múltiples servidores de Minecraft, permitiendo a los jugadores moverse entre ellos sin desconectarse. En este contexto, nLogin debe configurarse para sincronizar la autenticación entre todos los servidores.

Arquitectura de la Red

Una red típica con nLogin tiene esta estructura:

Bungeecord (Proxy)
├── Lobby (Servidor de autenticación)
├── Survival
├── Creative
└── Minigames

Los jugadores se conectan primero al proxy, son enviados al Lobby para autenticarse, y luego pueden acceder a los demás servidores.

Requisitos Previos

Antes de comenzar, asegúrate de tener:

Servidor Bungeecord o Waterfall funcionando
Al menos 2 servidores backend (Lobby + otro servidor)
MySQL o PostgreSQL para base de datos compartida
Acceso FTP o SSH a todos los servidores
Permisos administrativos completos

Instalación en Todos los Servidores

Paso 1: Instalar nLogin en Backend

Coloca nLogin.jar en la carpeta plugins de TODOS los servidores backend (Lobby, Survival, Creative, etc.). No instales nLogin en el proxy Bungeecord.

lobby/plugins/nLogin.jar
survival/plugins/nLogin.jar
creative/plugins/nLogin.jar
minigames/plugins/nLogin.jar

Paso 2: Primera Ejecución

Inicia cada servidor backend individualmente para generar los archivos de configuración. Luego detén todos los servidores.

Paso 3: Configurar Base de Datos MySQL

nLogin requiere una base de datos compartida en Bungeecord para sincronizar cuentas entre servidores.

Crear base de datos:

CREATE DATABASE nlogin_db;
CREATE USER 'nlogin_user'@'%' IDENTIFIED BY 'contraseña_segura';
GRANT ALL PRIVILEGES ON nlogin_db.* TO 'nlogin_user'@'%';
FLUSH PRIVILEGES;

Configuración del Servidor de Autenticación (Lobby)

El Lobby es donde los jugadores se autenticarán antes de acceder a otros servidores.

config.yml del Lobby

Edita lobby/plugins/nLogin/config.yml:

# Modo Bungeecord activado
bungeecord:
  enabled: true
  auth-server: true

# Configuración de base de datos MySQL
database:
  type: MYSQL
  host: localhost
  port: 3306
  database: nlogin_db
  username: nlogin_user
  password: contraseña_segura

# Tiempo de autenticación
login-timeout: 120

# Longitud de contraseña
min-password-length: 6
max-password-length: 32

# Sesiones
session-time: 600

# Bloqueo de movimiento
block-movement: true
block-commands: true

# Servidor de redirección después de login
redirect-server: survival

Configurar Spawns en Lobby

Posiciónate en el área de autenticación y ejecuta:

/nlogin spawn set firstjoin
/nlogin spawn set join

Esto asegura que los jugadores aparezcan en el área correcta para autenticarse.

Configuración de Servidores Backend

Los servidores adicionales (Survival, Creative, etc.) deben estar configurados para verificar autenticación pero no solicitar login.

config.yml de Servidores Backend

Edita el config.yml en cada servidor backend (excepto Lobby):

# Modo Bungeecord activado pero sin autenticación
bungeecord:
  enabled: true
  auth-server: false

# Misma base de datos que el Lobby
database:
  type: MYSQL
  host: localhost
  port: 3306
  database: nlogin_db
  username: nlogin_user
  password: contraseña_segura

# No bloquear movimiento en servidores backend
block-movement: false
block-commands: false

Configuración de Bungeecord

Archivo config.yml de Bungeecord

Edita config.yml del proxy Bungeecord:

# Habilitar IP forwarding (IMPORTANTE)
ip_forward: true

# Configuración de servidores
servers:
  lobby:
    motd: 'Servidor de Autenticación'
    address: localhost:25565
    restricted: false
  survival:
    motd: 'Servidor Survival'
    address: localhost:25566
    restricted: false
  creative:
    motd: 'Servidor Creative'
    address: localhost:25567
    restricted: false

# Servidor por defecto (Lobby)
default_server: lobby

# Prioridades de conexión
priorities:
- lobby
- survival
- creative

Configurar spigot.yml en Servidores Backend

En TODOS los servidores backend, edita spigot.yml:

settings:
  bungeecord: true

Esto permite que los servidores reciban información correcta del proxy.

Sincronización de Datos

Verificar Conexión a Base de Datos

En cada servidor backend, verifica que nLogin se conecte correctamente a MySQL revisando los logs:

[nLogin] Conectado a base de datos MySQL exitosamente

Probar Sincronización

Registra una cuenta en el Lobby: /register test123 test123
Cambia a otro servidor: /server survival
Verifica que no te pida login nuevamente
La sesión debe mantenerse automáticamente

Ejemplos de Uso en Bungeecord

Ejemplo 1: Jugador Nuevo en la Red

Situación: “NuevoPlayer” se conecta por primera vez a la red.

NuevoPlayer conecta a la IP del proxy
Bungeecord lo envía automáticamente al Lobby
Aparece en el spawn de firstjoin del Lobby
Ve mensaje: “Bienvenido! Usa /register <contraseña> ”
Ejecuta: /register mipass123 mipass123
Sistema registra la cuenta en MySQL
Es redirigido automáticamente al servidor Survival
Puede cambiar a cualquier servidor sin volver a autenticarse

Ejemplo 2: Jugador Regresa a la Red

Situación: “RegularPlayer” ya tiene cuenta y vuelve a conectarse.

RegularPlayer conecta al proxy
Es enviado al Lobby
Ve mensaje: “Usa /login <contraseña>”
Ejecuta: /login mipass123
nLogin verifica contraseña en MySQL
Crea sesión válida para toda la red
Es redirigido a Survival
Puede moverse libremente entre servidores

Ejemplo 3: Administrador Gestiona Cuentas

Situación: Administrador necesita cambiar contraseña desde servidor Creative.

Admin está en servidor Creative
Jugador “OlvidoPass” está en Survival
Admin ejecuta desde Creative: /nlogin changepass OlvidoPass nuevapass456
Cambio se guarda en MySQL
OlvidoPass puede usar nueva contraseña desde cualquier servidor

Ejemplo 4: Detectar Multicuentas en Red

Situación: Detectar si un jugador tiene cuentas alternativas.

Admin ejecuta: /nlogin dupeip SospechPlayer
Sistema consulta MySQL y muestra: “IP 10.0.0.50 - Cuentas: SospechPlayer, AltAccount1, AltAccount2”
Admin confirma multicuentas
Aplica medidas apropiadas en toda la red

Configuración Avanzada para Bungeecord

Servidor de Autenticación Dedicado

Puedes tener un servidor específico solo para autenticación:

# En Bungeecord config.yml
servers:
  auth:
    address: localhost:25565
    restricted: false

default_server: auth

# En auth/plugins/nLogin/config.yml
redirect-server: lobby  # Envía al lobby después de login

Múltiples Servidores de Autenticación

Para redes grandes con varios puntos de entrada:

# Lobby1 config.yml
bungeecord:
  enabled: true
  auth-server: true
redirect-server: survival1

# Lobby2 config.yml
bungeecord:
  enabled: true
  auth-server: true
redirect-server: survival2

Sesiones Persistentes

Configura sesiones más largas para usuarios frecuentes:

# En todos los servidores
session-time: 3600  # 1 hora de sesión
persistent-sessions: true

Solución de Problemas en Bungeecord

Causa: Base de datos no sincronizada o IP forwarding desactivado.

Solución:

Verifica ip_forward: true en config.yml de Bungeecord
Confirma bungeecord: true en spigot.yml de todos los backends
Verifica que todos usen la misma base de datos MySQL
Revisa credenciales de MySQL en todos los config.yml
Reinicia todos los servidores en orden: backends primero, proxy último

Problema: Base de Datos No Conecta

Causa: Configuración incorrecta de MySQL o firewall bloqueando conexiones.

Solución:

Verifica credenciales: usuario, contraseña, nombre de base de datos
Confirma que MySQL acepta conexiones remotas
Revisa firewall: puerto 3306 debe estar abierto
Prueba conexión manual desde cada servidor backend
Revisa logs de nLogin para errores específicos

Problema: Jugadores Atascados en Lobby

Causa: Servidor de redirección no configurado o inaccesible.

Solución:

Verifica redirect-server: survival en config.yml del Lobby
Confirma que el servidor de destino existe en Bungeecord
Verifica que el servidor de destino esté en línea
Prueba manualmente: /server survival
Revisa permisos de cambio de servidor

Problema: Sesiones No Persisten

Causa: Diferentes bases de datos o configuración inconsistente.

Solución:

Verifica que TODOS los servidores apunten a misma base de datos
Confirma credenciales idénticas en todos los config.yml
Revisa session-time esté configurado igual en todos
Elimina archivos database.db locales si existen
Reinicia la red completa

Problema: Errores de “Player Already Online”

Causa: Sesiones no limpias o desconexión incorrecta.

Solución:

Configura timeout de sesión apropiado
Usa comandos administrativos para limpiar sesión
Reinicia el servidor problemático
Verifica red para descartar problemas de latencia

Monitoreo y Mantenimiento

Monitorear Conexiones de Base de Datos

Revisa regularmente los logs de cada servidor:

grep "nLogin" logs/latest.log | grep "database"

Respaldos de Base de Datos

Configura respaldos automáticos diarios de MySQL:

#!/bin/bash
mysqldump -u nlogin_user -p'contraseña_segura' nlogin_db > backup_$(date +%Y%m%d).sql

Estadísticas de Uso

Monitorea cuentas registradas:

SELECT COUNT(*) FROM nlogin_accounts;

Ver últimas conexiones:

SELECT username, last_login FROM nlogin_accounts ORDER BY last_login DESC LIMIT 10;

Optimización de Rendimiento

Optimizar Conexiones MySQL

En config.yml de todos los servidores:

database:
  pool-size: 10
  connection-timeout: 5000
  max-lifetime: 1800000

Caché de Sesiones

Habilita caché para reducir consultas a base de datos:

cache:
  enabled: true
  size: 100
  expire-time: 300

Migración desde Servidor Único

Pasos para Migrar

Respaldar base de datos SQLite del servidor único
Instalar MySQL en la red
Convertir datos de SQLite a MySQL usando herramientas de nLogin
Configurar todos los servidores con nueva base de datos
Probar autenticación en entorno de prueba primero
Migrar en producción durante bajo tráfico

Integración con Plugins Adicionales

Con LuckPerms en Red

Usa MySQL compartido también para LuckPerms:

# En luckperms/config.yml de todos los servidores
storage-method: mysql
data:
  address: localhost:3306
  database: luckperms_db
  username: luckperms_user
  password: contraseña_luckperms

Con VelocityAuth

Si usas Velocity en lugar de Bungeecord, nLogin también es compatible con configuración similar.

Mejores Prácticas para Bungeecord

Base de datos dedicada: Usa servidor MySQL dedicado separado de servidores de juego.

Servidor de autenticación aislado: Mantén el Lobby solo para autenticación, sin otras actividades.

Monitoreo constante: Implementa herramientas para monitorear disponibilidad de MySQL.

Respaldos redundantes: Mantén múltiples copias de la base de datos en ubicaciones diferentes.

Red segura: Usa VPN o firewall para proteger comunicación entre servidores.

Sesiones razonables: No configures sesiones muy largas (máximo 1 hora recomendado).

Staff capacitado: Asegura que administradores entiendan arquitectura de la red.

Seguridad Adicional en Red

Proteger Comunicación Backend

Configura firewall para permitir solo comunicación entre servidores de tu red:

# Ejemplo con iptables
iptables -A INPUT -s IP_SERVIDOR_LOBBY -p tcp --dport 25565 -j ACCEPT
iptables -A INPUT -p tcp --dport 25565 -j DROP

Cifrado de Base de Datos

Configura MySQL con SSL para cifrar datos en tránsito:

database:
  use-ssl: true
  verify-certificate: true

Auditoría de Accesos

Habilita logs detallados:

logging:
  detailed: true
  log-logins: true
  log-register: true
  log-password-changes: true

Configurar nLogin en Bungeecord

¿Qué es una Red Bungeecord?

Arquitectura de la Red

Requisitos Previos

Instalación en Todos los Servidores

Paso 1: Instalar nLogin en Backend

Paso 2: Primera Ejecución

Paso 3: Configurar Base de Datos MySQL

Configuración del Servidor de Autenticación (Lobby)

config.yml del Lobby

Configurar Spawns en Lobby

Configuración de Servidores Backend

config.yml de Servidores Backend

Configuración de Bungeecord

Archivo config.yml de Bungeecord

Configurar spigot.yml en Servidores Backend

Sincronización de Datos

Verificar Conexión a Base de Datos

Probar Sincronización

Ejemplos de Uso en Bungeecord

Ejemplo 1: Jugador Nuevo en la Red

Ejemplo 2: Jugador Regresa a la Red

Ejemplo 3: Administrador Gestiona Cuentas

Ejemplo 4: Detectar Multicuentas en Red

Configuración Avanzada para Bungeecord

Servidor de Autenticación Dedicado

Múltiples Servidores de Autenticación

Sesiones Persistentes

Solución de Problemas en Bungeecord

Problema: Jugadores Piden Login en Cada Servidor

Problema: Base de Datos No Conecta

Problema: Jugadores Atascados en Lobby

Problema: Sesiones No Persisten

Problema: Errores de “Player Already Online”

Monitoreo y Mantenimiento

Monitorear Conexiones de Base de Datos

Respaldos de Base de Datos

Estadísticas de Uso

Optimización de Rendimiento

Optimizar Conexiones MySQL

Caché de Sesiones

Migración desde Servidor Único

Pasos para Migrar

Integración con Plugins Adicionales

Con LuckPerms en Red

Con VelocityAuth

Mejores Prácticas para Bungeecord

Seguridad Adicional en Red

Proteger Comunicación Backend

Cifrado de Base de Datos

Auditoría de Accesos