5:27 p.m.
Tengo en dos Entidades diferentes, 2 servidores Jabber (Openfire
4.6.3) en ambos casos montado en un contenedor LXC con Debian 10. Pero
dichos servidores Jabber no quieren comunicarse entre si, ya verifique
que en ambos servidores Openfire tengan configurada la opción de que
permitan todas las conexiones con cualquier servidor remoto.
Desde Servidor 1:
1) Comprobando resolución DNS hacia servidor 2
root@jabber:/etc# nslookup -querytype=SRV _xmpp-server._tcp.dlg.pri.minag.gob.cu
Server: 192.168.5.2
Address: 192.168.5.2#53
Non-authoritative answer:
_xmpp-server._tcp.dlg.pri.minag.gob.cu service = 5 0 5269
jabber.dlg.pri.minag.gob.cu.
Authoritative answers can be found from:
jabber.dlg.pri.minag.gob.cu internet address = 172.18.145.7
root@jabber:/etc#
2) Comprobando acceso al puerto 5269 tcp
root@jabber:/etc# telnet jabber.dlg.pri.minag.gob.cu 5269
Trying 172.18.145.7...
Connected to jabber.dlg.pri.minag.gob.cu.
Escape character is '^]'.
Desde Servidor 2:
1) Comprobando resolución DNS hacia servidor 1
root@jabber:/etc# nslookup -querytype=SRV _xmpp-server._tcp.pri.eicma.cu
Server: 192.168.2.2
Address: 192.168.2.2#53
Non-authoritative answer:
_xmpp-server._tcp.pri.eicma.cu service = 0 5 5269 jabber.pri.eicma.cu.
Authoritative answers can be found from:
jabber.pri.eicma.cu internet address = 172.16.66.7
root@jabber:/etc#
2) Comprobando acceso al puerto 5269 tcp
root@jabber:/etc# telnet jabber.pri.eicma.cu 5269
Trying 172.16.66.7...
Connected to jabber.pri.eicma.cu.
Escape character is '^]'.
Al parecer todo está bien, pero cuando un usuario conectado al
servidor 1, le enviar una solicitud a un usuario que está conectado al
servidor 2, esta llega sin problemas! Pero la solicitud desde desde
servidor 2 hacia el servidor 1, nunca llega! Y como resultado, la
comunicación no funciona.
Ideas???
--
Ing. Eduardo R. Barrera Pérez
Administrador de Redes y Servicios Telemáticos
Pinar del Río. Cuba.
Teléfonos: +53-52696879
E-mail: ebprz78(a)gmail.com
6:42 p.m.
En 16 de agosto de 2021 5:28:01 p. m. "Eduardo R. Barrera Pérez"
<ebprz78(a)gmail.com> escribió:
Tengo en dos Entidades diferentes, 2 servidores Jabber (Openfire
4.6.3) en ambos casos montado en un contenedor LXC con Debian 10. Pero
dichos servidores Jabber no quieren comunicarse entre si, ya verifique
que en ambos servidores Openfire tengan configurada la opción de que
permitan todas las conexiones con cualquier servidor remoto.
Desde Servidor 1:
1) Comprobando resolución DNS hacia servidor 2
root@jabber:/etc# nslookup -querytype=SRV
_xmpp-server._tcp.dlg.pri.minag.gob.cu
Server: 192.168.5.2
Address: 192.168.5.2#53
Non-authoritative answer:
_xmpp-server._tcp.dlg.pri.minag.gob.cu service = 5 0 5269
jabber.dlg.pri.minag.gob.cu.
Authoritative answers can be found from:
jabber.dlg.pri.minag.gob.cu internet address = 172.18.145.7
root@jabber:/etc#
2) Comprobando acceso al puerto 5269 tcp
root@jabber:/etc# telnet jabber.dlg.pri.minag.gob.cu 5269
Trying 172.18.145.7...
Connected to jabber.dlg.pri.minag.gob.cu.
Escape character is '^]'.
Desde Servidor 2:
1) Comprobando resolución DNS hacia servidor 1
root@jabber:/etc# nslookup -querytype=SRV _xmpp-server._tcp.pri.eicma.cu
Server: 192.168.2.2
Address: 192.168.2.2#53
Non-authoritative answer:
_xmpp-server._tcp.pri.eicma.cu service = 0 5 5269 jabber.pri.eicma.cu.
Authoritative answers can be found from:
jabber.pri.eicma.cu internet address = 172.16.66.7
root@jabber:/etc#
2) Comprobando acceso al puerto 5269 tcp
root@jabber:/etc# telnet jabber.pri.eicma.cu 5269
Trying 172.16.66.7...
Connected to jabber.pri.eicma.cu.
Escape character is '^]'.
Al parecer todo está bien, pero cuando un usuario conectado al
servidor 1, le enviar una solicitud a un usuario que está conectado al
servidor 2, esta llega sin problemas! Pero la solicitud desde desde
servidor 2 hacia el servidor 1, nunca llega! Y como resultado, la
comunicación no funciona.
Ideas???
--
Ing. Eduardo R. Barrera Pérez
Administrador de Redes y Servicios Telemáticos
Pinar del Río. Cuba.
Teléfonos: +53-52696879
E-mail: ebprz78(a)gmail.com
_______________________________________________
Gutl-l mailing list -- gutl-l(a)listas.jovenclub.cu
To unsubscribe send an email to gutl-l-leave(a)listas.jovenclub.cu
Firewall, Nat, certificados, las causas pueden ser varias, compruebe en los
log que error se puede estar presentando.
Salu2.
7:15 p.m.
Firewall, Nat, certificados, las causas pueden ser varias, compruebe
en los
log que error se puede estar presentando.
Salu2.
Bueno Firewal, NAT, no creo! ambos servidores Jabber están por detrás
cad uno de un pfsense y como mostré en el correo anterior, la
comunicación hacia el puerto 5269 tcp funciona en ambos sentidos.
Los certificados, claro que son autofirmados, se generan
automáticamente durante el proceso de instlación de OpenFire y ambos
servidores fueron instalados hace poco, así que no hay razón para que
los certificados hayan expirado.
Ambos servidores están sincronizados (fecha y hora) desde una misma
fuente! Pero bueno, mirando los log del ambos servidores
(/var/log/openfire/all.log)
En el servidor 1 (jabber.pri.eicma.cu)
veo lo siguiente:
2021.08.16 18:50:53 WARN [pool-26-thread-3]:
org.jivesoftware.openfire.server.ServerDialback[Acting as Originating
Server: Create Outgoing Session from: pri.eicma.cu to RS at:
dlg.pri.minag.gob.cu (port: 5269)] - Unable to create a new outgoing
session
2021.08.16 18:50:53 WARN [pool-26-thread-3]:
org.jivesoftware.openfire.session.LocalOutgoingServerSession[Create
outgoing session for: pri.eicma.cu to dlg.pri.minag.gob.cu] - Unable
to create a new session: Dialback (as a fallback) failed.
2021.08.16 18:50:53 WARN [pool-26-thread-3]:
org.jivesoftware.openfire.session.LocalOutgoingServerSession[Authenticate
local domain: 'pri.eicma.cu' to remote domain: 'dlg.pri.minag.gob.cu']
- Unable to authenticate: Fail to create new session.
Al momento después de haber intentado enviar una solicitud usando el
cliente pidgin versión 2.14.5 desde una cuenta de usuario en Servidor
1 a otra cuenta de usuario en servidor 2
Y en los Log del Servidor 2, veo lo siguiente
2021.08.16 18:50:53 WARN [Server SR - 298821458]:
org.jivesoftware.openfire.server.ServerDialback[Acting as Receiving
Server: Validate domain:dlg.pri.minag.gob.cu(id 5gc5mmmf04) for OS:
pri.eicma.cu] - Unable to validate domain: An exception occurred while
verifying the dialback key.
java.io.EOFException: input contained no data
Veo que habla que no puede validar el dominio!! Supongo que tiene que
ver con los certificados, pero en ambos servidores Openfire, desde la
consola de administración en el apartado de Configuración de
Servidores remotos, está habilitado desde luego el puerto 5269, y en
las configuración avanzadas, la politica STARTTLS esta en Opcional, la
Autenticación Mutua la he deshabilitado en ambos servidores, en
Verificación de cadena de certificados he marcado: Permitir
certificados auto-firmados y desmarcado: Verificar que el certificado
es válido en este momento (basado en los valores de los campos
'notBefore' y 'notAfter' del certificado) y los Protocolos de
Cifrado, los he marcado todos, pero aún así sigue dándome el error en
los log que les muestro arriba!
Saludos...
--
Ing. Eduardo R. Barrera Pérez
Administrador de Redes y Servicios Telemáticos
Pinar del Río. Cuba.
Teléfonos: +53-52696879
E-mail: ebprz78(a)gmail.com
8:52 p.m.
donde se podria encontrar un tutorial de como configurar S2S esto con
openfire o ejabberd.. siempre me ha interesado conectar 2 server jabber
y lo he intentado pero no lo he logrado.. saludos
El 16/8/2021 a las 19:15, Eduardo R. Barrera Pérez escribió:
> Firewall, Nat, certificados, las causas pueden ser varias,
compruebe en los
>
> log que error se puede estar presentando.
>
> Salu2.
Bueno Firewal, NAT, no creo! ambos servidores Jabber están por detrás
cad uno de un pfsense y como mostré en el correo anterior, la
comunicación hacia el puerto 5269 tcp funciona en ambos sentidos.
Los certificados, claro que son autofirmados, se generan
automáticamente durante el proceso de instlación de OpenFire y ambos
servidores fueron instalados hace poco, así que no hay razón para que
los certificados hayan expirado.
Ambos servidores están sincronizados (fecha y hora) desde una misma
fuente! Pero bueno, mirando los log del ambos servidores
(/var/log/openfire/all.log)
En el servidor 1 (jabber.pri.eicma.cu)
veo lo siguiente:
2021.08.16 18:50:53 WARN [pool-26-thread-3]:
org.jivesoftware.openfire.server.ServerDialback[Acting as Originating
Server: Create Outgoing Session from: pri.eicma.cu to RS at:
dlg.pri.minag.gob.cu (port: 5269)] - Unable to create a new outgoing
session
2021.08.16 18:50:53 WARN [pool-26-thread-3]:
org.jivesoftware.openfire.session.LocalOutgoingServerSession[Create
outgoing session for: pri.eicma.cu to dlg.pri.minag.gob.cu] - Unable
to create a new session: Dialback (as a fallback) failed.
2021.08.16 18:50:53 WARN [pool-26-thread-3]:
org.jivesoftware.openfire.session.LocalOutgoingServerSession[Authenticate
local domain: 'pri.eicma.cu' to remote domain: 'dlg.pri.minag.gob.cu']
- Unable to authenticate: Fail to create new session.
Al momento después de haber intentado enviar una solicitud usando el
cliente pidgin versión 2.14.5 desde una cuenta de usuario en Servidor
1 a otra cuenta de usuario en servidor 2
Y en los Log del Servidor 2, veo lo siguiente
2021.08.16 18:50:53 WARN [Server SR - 298821458]:
org.jivesoftware.openfire.server.ServerDialback[Acting as Receiving
Server: Validate domain:dlg.pri.minag.gob.cu(id 5gc5mmmf04) for OS:
pri.eicma.cu] - Unable to validate domain: An exception occurred while
verifying the dialback key.
java.io.EOFException: input contained no data
Veo que habla que no puede validar el dominio!! Supongo que tiene que
ver con los certificados, pero en ambos servidores Openfire, desde la
consola de administración en el apartado de Configuración de
Servidores remotos, está habilitado desde luego el puerto 5269, y en
las configuración avanzadas, la politica STARTTLS esta en Opcional, la
Autenticación Mutua la he deshabilitado en ambos servidores, en
Verificación de cadena de certificados he marcado: Permitir
certificados auto-firmados y desmarcado: Verificar que el certificado
es válido en este momento (basado en los valores de los campos
'notBefore' y 'notAfter' del certificado) y los Protocolos de
Cifrado, los he marcado todos, pero aún así sigue dándome el error en
los log que les muestro arriba!
Saludos...
9:06 p.m.
El 16/8/21 a las 20:52, Leanny escribió:
donde se podria encontrar un tutorial de como configurar S2S esto con
openfire o ejabberd.. siempre me ha interesado conectar 2 server jabber
y lo he intentado pero no lo he logrado.. saludos
El 16/8/2021 a las 19:15, Eduardo R. Barrera Pérez escribió:
>> Firewall, Nat, certificados, las causas pueden ser varias, compruebe
>> en los
>>
>> log que error se puede estar presentando.
>>
>> Salu2.
> Bueno Firewal, NAT, no creo! ambos servidores Jabber están por detrás
> cad uno de un pfsense y como mostré en el correo anterior, la
> comunicación hacia el puerto 5269 tcp funciona en ambos sentidos.
>
> Los certificados, claro que son autofirmados, se generan
> automáticamente durante el proceso de instlación de OpenFire y ambos
> servidores fueron instalados hace poco, así que no hay razón para que
> los certificados hayan expirado.
>
> Ambos servidores están sincronizados (fecha y hora) desde una misma
> fuente! Pero bueno, mirando los log del ambos servidores
> (/var/log/openfire/all.log)
>
> En el servidor 1 (jabber.pri.eicma.cu)
>
> veo lo siguiente:
>
> 2021.08.16 18:50:53 WARN [pool-26-thread-3]:
> org.jivesoftware.openfire.server.ServerDialback[Acting as Originating
> Server: Create Outgoing Session from: pri.eicma.cu to RS at:
> dlg.pri.minag.gob.cu (port: 5269)] - Unable to create a new outgoing
> session
> 2021.08.16 18:50:53 WARN [pool-26-thread-3]:
> org.jivesoftware.openfire.session.LocalOutgoingServerSession[Create
> outgoing session for: pri.eicma.cu to dlg.pri.minag.gob.cu] - Unable
> to create a new session: Dialback (as a fallback) failed.
> 2021.08.16 18:50:53 WARN [pool-26-thread-3]:
> org.jivesoftware.openfire.session.LocalOutgoingServerSession[Authenticate
> local domain: 'pri.eicma.cu' to remote domain:
'dlg.pri.minag.gob.cu']
> - Unable to authenticate: Fail to create new session.
>
> Al momento después de haber intentado enviar una solicitud usando el
> cliente pidgin versión 2.14.5 desde una cuenta de usuario en Servidor
> 1 a otra cuenta de usuario en servidor 2
>
> Y en los Log del Servidor 2, veo lo siguiente
>
> 2021.08.16 18:50:53 WARN [Server SR - 298821458]:
> org.jivesoftware.openfire.server.ServerDialback[Acting as Receiving
> Server: Validate domain:dlg.pri.minag.gob.cu(id 5gc5mmmf04) for OS:
> pri.eicma.cu] - Unable to validate domain: An exception occurred while
> verifying the dialback key.
> java.io.EOFException: input contained no data
>
>
> Veo que habla que no puede validar el dominio!! Supongo que tiene que
> ver con los certificados, pero en ambos servidores Openfire, desde la
> consola de administración en el apartado de Configuración de
> Servidores remotos, está habilitado desde luego el puerto 5269, y en
> las configuración avanzadas, la politica STARTTLS esta en Opcional, la
> Autenticación Mutua la he deshabilitado en ambos servidores, en
> Verificación de cadena de certificados he marcado: Permitir
> certificados auto-firmados y desmarcado: Verificar que el certificado
> es válido en este momento (basado en los valores de los campos
> 'notBefore' y 'notAfter' del certificado) y los Protocolos de
> Cifrado, los he marcado todos, pero aún así sigue dándome el error en
> los log que les muestro arriba!
>
>
> Saludos...
>
_______________________________________________
Gutl-l mailing list -- gutl-l(a)listas.jovenclub.cu
To unsubscribe send an email to gutl-l-leave(a)listas.jovenclub.cu
Eso no tiene
ciencia, en el correo principal de Eduardo, está
prácticamente explicado y comprobado todo lo que se necesito, así de
siempre, dos servidores, que por red se ven y tiene abierto su puerto
5269, y que ambos se comunican, luego viene la parte del dns, y que
ambos se resuelven entre ellos, y el SRV correspondiente para la
localización del servicio en la red. Listo siempre que se cumplan esas
condiciones los dos servidores se van a comunicar, el problema de
eduardo ya lo explique en un correo anterior, y tiene que ver que un
subdominio forma parte del otro, y eso no se puede validar correctamente
cuando los certificados son autogenerados y autofirmados,
automáticamente en el proceso de instalación. y uno entra en el wildcard
del otro. Salu2.
--
Arian Molina Aguilera
Administrador de Redes y Servicios Telemáticos
Linux Usuario Registrado #392892
Telfs: +53(7)696-7510 ext 236
email: linuxcuba(a)teknik.io
“Nunca consideres el estudio como una obligación,
sino como una oportunidad para penetrar en el bello
y maravilloso mundo del saber. Albert Einstein”
8:54 p.m.
donde se podria encontrar un tutorial de como configurar S2S con
openfire o ejabberd.. siempre me ha interesado conectar 2 server jabber
y lo he intentado pero no lo he logrado.. saludos
El 16/8/2021 a las 19:15, Eduardo R. Barrera Pérez escribió:
> Firewall, Nat, certificados, las causas pueden ser varias,
compruebe en los
>
> log que error se puede estar presentando.
>
> Salu2.
Bueno Firewal, NAT, no creo! ambos servidores Jabber están por detrás
cad uno de un pfsense y como mostré en el correo anterior, la
comunicación hacia el puerto 5269 tcp funciona en ambos sentidos.
Los certificados, claro que son autofirmados, se generan
automáticamente durante el proceso de instlación de OpenFire y ambos
servidores fueron instalados hace poco, así que no hay razón para que
los certificados hayan expirado.
Ambos servidores están sincronizados (fecha y hora) desde una misma
fuente! Pero bueno, mirando los log del ambos servidores
(/var/log/openfire/all.log)
En el servidor 1 (jabber.pri.eicma.cu)
veo lo siguiente:
2021.08.16 18:50:53 WARN [pool-26-thread-3]:
org.jivesoftware.openfire.server.ServerDialback[Acting as Originating
Server: Create Outgoing Session from: pri.eicma.cu to RS at:
dlg.pri.minag.gob.cu (port: 5269)] - Unable to create a new outgoing
session
2021.08.16 18:50:53 WARN [pool-26-thread-3]:
org.jivesoftware.openfire.session.LocalOutgoingServerSession[Create
outgoing session for: pri.eicma.cu to dlg.pri.minag.gob.cu] - Unable
to create a new session: Dialback (as a fallback) failed.
2021.08.16 18:50:53 WARN [pool-26-thread-3]:
org.jivesoftware.openfire.session.LocalOutgoingServerSession[Authenticate
local domain: 'pri.eicma.cu' to remote domain: 'dlg.pri.minag.gob.cu']
- Unable to authenticate: Fail to create new session.
Al momento después de haber intentado enviar una solicitud usando el
cliente pidgin versión 2.14.5 desde una cuenta de usuario en Servidor
1 a otra cuenta de usuario en servidor 2
Y en los Log del Servidor 2, veo lo siguiente
2021.08.16 18:50:53 WARN [Server SR - 298821458]:
org.jivesoftware.openfire.server.ServerDialback[Acting as Receiving
Server: Validate domain:dlg.pri.minag.gob.cu(id 5gc5mmmf04) for OS:
pri.eicma.cu] - Unable to validate domain: An exception occurred while
verifying the dialback key.
java.io.EOFException: input contained no data
Veo que habla que no puede validar el dominio!! Supongo que tiene que
ver con los certificados, pero en ambos servidores Openfire, desde la
consola de administración en el apartado de Configuración de
Servidores remotos, está habilitado desde luego el puerto 5269, y en
las configuración avanzadas, la politica STARTTLS esta en Opcional, la
Autenticación Mutua la he deshabilitado en ambos servidores, en
Verificación de cadena de certificados he marcado: Permitir
certificados auto-firmados y desmarcado: Verificar que el certificado
es válido en este momento (basado en los valores de los campos
'notBefore' y 'notAfter' del certificado) y los Protocolos de
Cifrado, los he marcado todos, pero aún así sigue dándome el error en
los log que les muestro arriba!
Saludos...
10:25 a.m.
El 16/8/21, Leanny <leannype(a)nauta.cu> escribió:
donde se podria encontrar un tutorial de como configurar S2S con
openfire o ejabberd.. siempre me ha interesado conectar 2 server jabber
y lo he intentado pero no lo he logrado.. saludos
Hola colega!! bueno para el S2S entre 2 servidores Jabber, solo tienes
que tener configurados correctamente los registros de tipo SRV en
ambos servidores DNS en cada extremo y permitir las conexiones TCP al
puerto 5269 en ambos extremos! Solo eso necesitas, a no ser que te
pase lo que me está sucediendo a mi en estos momentos con un servidor
Jabber en particular.
Saludos...
--
Ing. Eduardo R. Barrera Pérez
Administrador de Redes y Servicios Telemáticos
Pinar del Río. Cuba.
Teléfonos: +53-52696879
E-mail: ebprz78(a)gmail.com
9:02 p.m.
El 16/8/21 a las 19:15, Eduardo R. Barrera Pérez escribió:
> Firewall, Nat, certificados, las causas pueden ser varias,
compruebe en los
>
> log que error se puede estar presentando.
>
> Salu2.
Bueno Firewal, NAT, no creo! ambos servidores Jabber están por detrás
cad uno de un pfsense y como mostré en el correo anterior, la
comunicación hacia el puerto 5269 tcp funciona en ambos sentidos.
Los certificados, claro que son autofirmados, se generan
automáticamente durante el proceso de instlación de OpenFire y ambos
servidores fueron instalados hace poco, así que no hay razón para que
los certificados hayan expirado.
Ambos servidores están sincronizados (fecha y hora) desde una misma
fuente! Pero bueno, mirando los log del ambos servidores
(/var/log/openfire/all.log)
En el servidor 1 (jabber.pri.eicma.cu)
veo lo siguiente:
2021.08.16 18:50:53 WARN [pool-26-thread-3]:
org.jivesoftware.openfire.server.ServerDialback[Acting as Originating
Server: Create Outgoing Session from: pri.eicma.cu to RS at:
dlg.pri.minag.gob.cu (port: 5269)] - Unable to create a new outgoing
session
2021.08.16 18:50:53 WARN [pool-26-thread-3]:
org.jivesoftware.openfire.session.LocalOutgoingServerSession[Create
outgoing session for: pri.eicma.cu to dlg.pri.minag.gob.cu] - Unable
to create a new session: Dialback (as a fallback) failed.
2021.08.16 18:50:53 WARN [pool-26-thread-3]:
org.jivesoftware.openfire.session.LocalOutgoingServerSession[Authenticate
local domain: 'pri.eicma.cu' to remote domain: 'dlg.pri.minag.gob.cu']
- Unable to authenticate: Fail to create new session.
Al momento después de haber intentado enviar una solicitud usando el
cliente pidgin versión 2.14.5 desde una cuenta de usuario en Servidor
1 a otra cuenta de usuario en servidor 2
Y en los Log del Servidor 2, veo lo siguiente
2021.08.16 18:50:53 WARN [Server SR - 298821458]:
org.jivesoftware.openfire.server.ServerDialback[Acting as Receiving
Server: Validate domain:dlg.pri.minag.gob.cu(id 5gc5mmmf04) for OS:
pri.eicma.cu] - Unable to validate domain: An exception occurred while
verifying the dialback key.
java.io.EOFException: input contained no data
Veo que habla que no puede validar el dominio!! Supongo que tiene que
ver con los certificados, pero en ambos servidores Openfire, desde la
consola de administración en el apartado de Configuración de
Servidores remotos, está habilitado desde luego el puerto 5269, y en
las configuración avanzadas, la politica STARTTLS esta en Opcional, la
Autenticación Mutua la he deshabilitado en ambos servidores, en
Verificación de cadena de certificados he marcado: Permitir
certificados auto-firmados y desmarcado: Verificar que el certificado
es válido en este momento (basado en los valores de los campos
'notBefore' y 'notAfter' del certificado) y los Protocolos de
Cifrado, los he marcado todos, pero aún así sigue dándome el error en
los log que les muestro arriba!
Saludos...
ahí tienes el problema a eso me refería en los logs siempre está la
respuesta, El problema dialback eso sucede cuando los certificados son
autofirmados, y un servidor el dominios es subdominio del otro.
Realmente hace tiempo que no lidio con ese problema y no recuerdo que
hacía, pero eso ocurre porque el subdominio pri.minag.gob.cu esta
incluido en el de delegación dlg.pri.minag.gob.cu, creo que la solución
es agregar el certificado manualmente de un servidor en el otro y
viceversa. no estoy seguro pero por ahí anda la cosa.
Salu2.
--
Arian Molina Aguilera
Administrador de Redes y Servicios Telemáticos
Linux Usuario Registrado #392892
Telfs: +53(7)696-7510 ext 236
email: linuxcuba(a)teknik.io
“Nunca consideres el estudio como una obligación,
sino como una oportunidad para penetrar en el bello
y maravilloso mundo del saber. Albert Einstein”
10:20 a.m.
>
ahí tienes el problema a eso me refería en los logs siempre está la
respuesta, El problema dialback eso sucede cuando los certificados son
autofirmados, y un servidor el dominios es subdominio del otro.
Realmente hace tiempo que no lidio con ese problema y no recuerdo que
hacía, pero eso ocurre porque el subdominio pri.minag.gob.cu esta
incluido en el de delegación dlg.pri.minag.gob.cu, creo que la solución
es agregar el certificado manualmente de un servidor en el otro y
viceversa. no estoy seguro pero por ahí anda la cosa.
Salu2.
Um!! bueno la verdad es que no se porque ocurre esto, pues en la VPN
Nacional de la que soy parte, existen otros muchos servidores Jabber,
muchos en mi misma provincia y otros en otras como es lógico y mi
servidor jabber se comunica actualmente con muchos otros servidores
aparentemente sin ninguna dificultad.
Muchos de estos servidores Jabbers (ya sean Openfire o Ejabberd) están
configurados para funcionar usando como dominio el propio dominio de
correo y no el FQDN del propio servidor, es el caso de estos 2
servidores Jabber que estoy tratando de lograr que se comuniquen.
1) Servidor 1
FQDN: jabber.pri.eicma.cu
Dominio para servicio XMPP: pri.eicma.cu
2) Servidor 2
FQDN: jabber.dlg.pri.minag.gob.cu
Dominio para servicio XMPP: dlg.pri.minag.gob.cu
Muchos servidores jabber en la VPN nuestra, están configurados de esta
manera y en estos momentos el jabber.pri.eicma.cu se comunica bien con
muchos otros servidores, este problema, se me ha presetando ahora
después que pase el contenedor a Debian 10 y OpenFire (cosa que hice
el mes pasado) ya que anteriormente estaba usando Ejabberd sobre
Debian 9 y no presentaba este problema en la comunicasión S2S entre
los servidores Jabber de la EICMA y el Jabber de la Delegación Prov,
del MINAG, el cual siempre fue un Openfire, lo que este último estaba
en Debian 8 y con una versión de Openfire vieja.
Es por eso, que los monte ambos, desde cero, usando la ultima versión
de OpenFire. Bueno, veré como obtengo los certificados esos y a ver si
eso me me dices me ayuda a resolver el problema!
Saludos...
--
Ing. Eduardo R. Barrera Pérez
Administrador de Redes y Servicios Telemáticos
Pinar del Río. Cuba.
Teléfonos: +53-52696879
E-mail: ebprz78(a)gmail.com
6:09 p.m.
En 17 de agosto de 2021 10:21:28 a. m. "Eduardo R. Barrera Pérez"
<ebprz78(a)gmail.com> escribió:
>>
> ahí tienes el problema a eso me refería en los logs siempre está la
> respuesta, El problema dialback eso sucede cuando los certificados son
> autofirmados, y un servidor el dominios es subdominio del otro.
> Realmente hace tiempo que no lidio con ese problema y no recuerdo que
> hacía, pero eso ocurre porque el subdominio pri.minag.gob.cu esta
> incluido en el de delegación dlg.pri.minag.gob.cu, creo que la solución
> es agregar el certificado manualmente de un servidor en el otro y
> viceversa. no estoy seguro pero por ahí anda la cosa.
>
> Salu2.
>
Um!! bueno la verdad es que no se porque ocurre esto, pues en la VPN
Nacional de la que soy parte, existen otros muchos servidores Jabber,
muchos en mi misma provincia y otros en otras como es lógico y mi
servidor jabber se comunica actualmente con muchos otros servidores
aparentemente sin ninguna dificultad.
Muchos de estos servidores Jabbers (ya sean Openfire o Ejabberd) están
configurados para funcionar usando como dominio el propio dominio de
correo y no el FQDN del propio servidor, es el caso de estos 2
servidores Jabber que estoy tratando de lograr que se comuniquen.
1) Servidor 1
FQDN: jabber.pri.eicma.cu
Dominio para servicio XMPP: pri.eicma.cu
2) Servidor 2
FQDN: jabber.dlg.pri.minag.gob.cu
Dominio para servicio XMPP: dlg.pri.minag.gob.cu
Muchos servidores jabber en la VPN nuestra, están configurados de esta
manera y en estos momentos el jabber.pri.eicma.cu se comunica bien con
muchos otros servidores, este problema, se me ha presetando ahora
después que pase el contenedor a Debian 10 y OpenFire (cosa que hice
el mes pasado) ya que anteriormente estaba usando Ejabberd sobre
Debian 9 y no presentaba este problema en la comunicasión S2S entre
los servidores Jabber de la EICMA y el Jabber de la Delegación Prov,
del MINAG, el cual siempre fue un Openfire, lo que este último estaba
en Debian 8 y con una versión de Openfire vieja.
Es por eso, que los monte ambos, desde cero, usando la ultima versión
de OpenFire. Bueno, veré como obtengo los certificados esos y a ver si
eso me me dices me ayuda a resolver el problema!
Saludos...
--
Ing. Eduardo R. Barrera Pérez
Administrador de Redes y Servicios Telemáticos
Pinar del Río. Cuba.
Teléfonos: +53-52696879
E-mail: ebprz78(a)gmail.com
_______________________________________________
Gutl-l mailing list -- gutl-l(a)listas.jovenclub.cu
To unsubscribe send an email to gutl-l-leave(a)listas.jovenclub.cu
Este es un tema del tratamiento que le da Java a los certificados
autofirmados como ya expliqué, openfire está desarrollado Java, habría que
ver sin versión de Java jre empleada en el servidor puede influir en esto.
Y la forma que se autogeneran los certificados autofirmados, quizás porque
son del tipo wildcard, se me ocurre generar certificado propio que solo
incluya el FQDN del host en su dn y no del tipo *.PRI.minag.cu, que es el
dominio más bajo. Generalo para jabber.pri.minag.cu elimina el por defecto
y añade después el generado de forma externa con openssl.
Prueba y comenta.
12:03 a.m.
no es mejor usar ejabberd???... o con ejabberd tambien puede pasar lo
mismo de los certificados?..
saludos
El 17/8/2021 a las 18:09, Arian Molina Aguilera escribió:
En 17 de agosto de 2021 10:21:28 a. m. "Eduardo R. Barrera
Pérez"
<ebprz78(a)gmail.com> escribió:
>>>
>> ahí tienes el problema a eso me refería en los logs siempre está la
>> respuesta, El problema dialback eso sucede cuando los certificados son
>> autofirmados, y un servidor el dominios es subdominio del otro.
>> Realmente hace tiempo que no lidio con ese problema y no recuerdo que
>> hacía, pero eso ocurre porque el subdominio pri.minag.gob.cu esta
>> incluido en el de delegación dlg.pri.minag.gob.cu, creo que la solución
>> es agregar el certificado manualmente de un servidor en el otro y
>> viceversa. no estoy seguro pero por ahí anda la cosa.
>>
>> Salu2.
>>
>
> Um!! bueno la verdad es que no se porque ocurre esto, pues en la VPN
> Nacional de la que soy parte, existen otros muchos servidores Jabber,
> muchos en mi misma provincia y otros en otras como es lógico y mi
> servidor jabber se comunica actualmente con muchos otros servidores
> aparentemente sin ninguna dificultad.
>
> Muchos de estos servidores Jabbers (ya sean Openfire o Ejabberd) están
> configurados para funcionar usando como dominio el propio dominio de
> correo y no el FQDN del propio servidor, es el caso de estos 2
> servidores Jabber que estoy tratando de lograr que se comuniquen.
>
> 1) Servidor 1
>
> FQDN: jabber.pri.eicma.cu
> Dominio para servicio XMPP: pri.eicma.cu
>
> 2) Servidor 2
>
> FQDN: jabber.dlg.pri.minag.gob.cu
> Dominio para servicio XMPP: dlg.pri.minag.gob.cu
>
> Muchos servidores jabber en la VPN nuestra, están configurados de esta
> manera y en estos momentos el jabber.pri.eicma.cu se comunica bien con
> muchos otros servidores, este problema, se me ha presetando ahora
> después que pase el contenedor a Debian 10 y OpenFire (cosa que hice
> el mes pasado) ya que anteriormente estaba usando Ejabberd sobre
> Debian 9 y no presentaba este problema en la comunicasión S2S entre
> los servidores Jabber de la EICMA y el Jabber de la Delegación Prov,
> del MINAG, el cual siempre fue un Openfire, lo que este último estaba
> en Debian 8 y con una versión de Openfire vieja.
>
> Es por eso, que los monte ambos, desde cero, usando la ultima versión
> de OpenFire. Bueno, veré como obtengo los certificados esos y a ver si
> eso me me dices me ayuda a resolver el problema!
>
> Saludos...
>
> --
> Ing. Eduardo R. Barrera Pérez
> Administrador de Redes y Servicios Telemáticos
> Pinar del Río. Cuba.
> Teléfonos: +53-52696879
> E-mail: ebprz78(a)gmail.com
> _______________________________________________
> Gutl-l mailing list -- gutl-l(a)listas.jovenclub.cu
> To unsubscribe send an email to gutl-l-leave(a)listas.jovenclub.cu
Este es un tema del tratamiento que le da Java a los certificados
autofirmados como ya expliqué, openfire está desarrollado Java, habría
que ver sin versión de Java jre empleada en el servidor puede influir
en esto. Y la forma que se autogeneran los certificados autofirmados,
quizás porque son del tipo wildcard, se me ocurre generar certificado
propio que solo incluya el FQDN del host en su dn y no del tipo
*.PRI.minag.cu, que es el dominio más bajo. Generalo para
jabber.pri.minag.cu elimina el por defecto y añade después el generado
de forma externa con openssl.
Prueba y comenta.
_______________________________________________
Gutl-l mailing list -- gutl-l(a)listas.jovenclub.cu
To unsubscribe send an email to gutl-l-leave(a)listas.jovenclub.cu
12:35 a.m.
No voy a entrar en un debate, pero las ventajes de openfire vs ejabberd es
muy superior en estos tiempos, la facilidad de su consola web no tiene
igual, así como la gran cantidad de plugins que podemos usar, incluso de
tener junto a este tu propio jitsi o servidor de videoconferencias. Lo del
certificado es una nimiedad que solo afecta a unos poco sin acceso directo
en sus servidores y dominios a internet para tener un certificado válido de
let's encrypt.
Puede resolverse como indique antes, usar openssl y general el certificado
autofirmados propio para el FQDN del servidor o dominio, y no wildcard como
lo ganera openfire desde su consola.
Salu2.
4:06 p.m.
hola, mi comentario no fue x saber cual es mejor, sino con el tema de
los certificados, si no da ese problema de los certificados entre 2
server ejabberd entonces lo ideal seria montarlo en ejabberd asi evitas
todo el problema de los certificados.
saludos
El 18/8/2021 a las 00:35, Arian Molina Aguilera escribió:
No voy a entrar en un debate, pero las ventajes de openfire vs
ejabberd es muy superior en estos tiempos, la facilidad de su consola
web no tiene igual, así como la gran cantidad de plugins que podemos
usar, incluso de tener junto a este tu propio jitsi o servidor de
videoconferencias. Lo del certificado es una nimiedad que solo afecta
a unos poco sin acceso directo en sus servidores y dominios a internet
para tener un certificado válido de let's encrypt.
Puede resolverse como indique antes, usar openssl y general el
certificado autofirmados propio para el FQDN del servidor o dominio, y
no wildcard como lo ganera openfire desde su consola.
Salu2.
_______________________________________________
Gutl-l mailing list -- gutl-l(a)listas.jovenclub.cu
To unsubscribe send an email to gutl-l-leave(a)listas.jovenclub.cu
20
days inactive
22
days old
12 comments
3 participants
participants (3)
-
Arian Molina Aguilera -
Eduardo R. Barrera Pérez -
Leanny