Resumiendo mi requisito aquí.
Configure la configuración del clúster de Ejabberd en el balanceador de carga de aplicaciones de AWS y luego registre 10.000 usuarios con la solicitud de API de Ejabberd. Una vez creadas las cuentas de usuario, inicie sesión con esos usuarios, cree salas y realice la prueba de chat con varias salas con múltiples cuentas de usuario.
Resumiendo la configuración del clúster Ejabberd existente.
He configurado la configuración del clúster Ejabberd con dos nodos en la instancia de AWS. Luego, creé un balanceador de carga de aplicaciones de AWS con dos grupos objetivo, un grupo objetivo con el número de puerto 5280 (URL de administrador) y otro grupo objetivo 5222 (autenticación de cliente XMPP). Luego, registraré al usuario ejabberd con la siguiente solicitud de API (puedo crear 10.000 cuentas con script).
http://<AWS Load balancer domain name>:5280/api/register
{
"user": "test_user1",
"host": "<AWS Load balancer domain name>",
"password": "********"
}
Hasta aquí, la configuración de Ejabberd funciona bien (he creado un host virtual con el nombre de dominio del balanceador de carga de AWS en el archivo de configuración de Ejabberd: “/opt/ejabberd/conf/ejabberd.yml”).
Cuando intento autenticar al usuario registrado con el cliente Pidgin XMPP, no puedo autenticar al usuario registrado con el nombre de dominio del equilibrador de carga.
He notado que los servidores de Ejabberd reciben la solicitud de la dirección IP privada interna del balanceador de carga de AWS (no del nombre de dominio real del balanceador de carga), por lo tanto, la autenticación de ejabberd no funciona con el balanceador de carga de aplicaciones de AWS.
Por favor ayúdenme a cumplir este requisito.
Respuesta1
Cuando intento autenticar al usuario registrado con el cliente Pidgin XMPP, no puedo autenticar al usuario registrado con el nombre de dominio del equilibrador de carga.
¿Por qué no? Debes editar tu publicación y mostrar los mensajes registrados con respecto a ese intento de autenticación.
No sé sobre el equilibrio de carga de AWS, pero solo mencionaré un razonamiento extraño:
He notado que los servidores de Ejabberd reciben la solicitud de la dirección IP privada interna del balanceador de carga de AWS (no del nombre de dominio real del balanceador de carga), por lo tanto, la autenticación de ejabberd no funciona con el balanceador de carga de aplicaciones de AWS.
Umm... Siempre y cuando ejabberd reciba las estrofas XMPP que intentan autenticarse y proporcionen las credenciales de cuenta correctas, no importa de dónde viene esa conexión ni a qué interfaz exacta se conecta (5222 oyente, 5280, 127.0 .0.1, o cualquier otra dirección donde ejabberd esté escuchando).
Por ejemplo, esos son los mensajes que se registran cuando se registra una cuenta e inicia sesión correctamente:
2020-12-04 12:16:08.006547+01:00 [info] The account user2@localhost
was registered from IP address 127.0.0.1
2020-12-04 12:16:13.502761+01:00 [info] (<0.675.0>)
Accepted connection 127.0.0.1:46309 -> 127.0.0.1:5222
2020-12-04 12:16:13.607712+01:00 [info] (tls|<0.675.0>)
Accepted c2s DIGEST-MD5 authentication for user2@localhost by mnesia backend from 127.0.0.1
2020-12-04 12:16:13.650407+01:00 [info] (tls|<0.675.0>)
Opened c2s session for user2@localhost/tka1
¿Están realmente registradas sus cuentas? ¿Cómo estás seguro? ¿Están registrados con el host correcto?
Puede verificar las cuentas en ejabberd WebAdmin, o volcar la base de datos en un archivo de texto y mirar la tabla passwd, o usar ejabberdctl debug o live y el comando:
(ejabberd@localhost)3> mnesia:dirty_read(passwd,mnesia:dirty_first(passwd)).
[{passwd,{<<"user2">>,<<"localhost">>},
<<"mypass11'a},ca">>}]