Limitación al acceso remoto al manager.conf
TelecoSilvia
Me gustaría abrir un acceso a un servidor que tenemos en el ...
"cloud" hacia el manager de asterisk.
He hecho una redirección de un puerto externo hacia el 5038 de la
centralita. Pensaba crear una serie de limitaciones de acceso con
iptables pero me encuentro que directamente no se puede acceder
externamente a este puerto.
Los paquetes tcp llegan a la centralita con lo que entiendo que el
puerto externo funciona correctamente.
La configuración del manager la tengo así:
[xxxxxxxxxxx]
secret=xxxxxxxxxxx
deny=0.0.0.0/0.0.0.0
permit=ippublica/255.255.255.255
read = system,call,log,verbose,command,agent,user
write = system,call,log,verbose,command,agent,user
Aunque también he probado sin el deny y incluso con
permit=0.0.0.0/0.0.0.0
También veo que aunque ponga varias lineas de permit por ejemplo:
permit=192.168.1.0/255.255.255.0
permit=127.0.0.1/255.255.255.0
permit=192.168.2.0/255.255.255.0
Asterisk solo muestra la última:
*CLI> manager show user xxxxxxxxxxx
*CLI>
username: xxxxxxxxxxx
secret: <Set>
deny: 0.0.0.0/0.0.0.0
permit: 192.168.2.0/255.255.255.0
read: system,call,log,verbose,command,agent,user
write: system,call,log,verbose,command,agent,user
displayconnects: no
CLI>
Si hago una connexión des de la red local con un telnet iplocal 5038
funciona.
Con lo que no tengo mucha idea más de como solucionarlo.
Iñaki Baz Castillo
<teleco...@gmail.com> escribió:
> He hecho una redirección de un puerto externo hacia el 5038 de la
> centralita. Pensaba crear una serie de limitaciones de acceso con
> iptables pero me encuentro que directamente no se puede acceder
> externamente a este puerto.
>
> Los paquetes tcp llegan a la centralita con lo que entiendo que el
> puerto externo funciona correctamente.
¿Responde algo Asterisk a esa conexión TCP/AMI?
--
Iñaki Baz Castillo
<i...@aliax.net>
TelecoSilvia
On 22 Juny, 13:16, Iñaki Baz Castillo <i...@aliax.net> wrote:
> El día 22 de junio de 2011 11:54, TelecoSilvia
Iñaki Baz Castillo
<teleco...@gmail.com> escribió:
> Nada.
¿Pero se establece la conexión TCP y el cliente envía datos AMI al
5038 de Asterisk? ¿o ni siquiera se establece la conexión TCP?
TelecoSilvia
Trying ippublica...
telnet: Unable to connect to remote host: Connection timed out
sgg@host:~$
En el asterisk
root@host:/etc/asterisk# ngrep -P ' ' -W byline -T port 5038
interface: eth0 (192.168.1.0/255.255.255.0)
filter: (ip or ip6) and ( port 5038 )
##
2 received, 0 dropped
On 22 Juny, 13:18, Iñaki Baz Castillo <i...@aliax.net> wrote:
> El día 22 de junio de 2011 13:17, TelecoSilvia
Cristian Luna
--
Este email pertenece a la lista de Asterisk-ES (http://www.asterisk-es.org)
~~~ Normas de la lista Asterisk-ES: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
http://comunidad.asterisk-es.org/index.php?title=Lista:normas-asterisk-es
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
- Para anular la suscripción: asterisk-es...@googlegroups.com
TelecoSilvia
centralita.
On 22 Juny, 13:48, Cristian Luna <lunacrist...@gmail.com> wrote:
> Desde donde originas la conexión TCP tenes filtrado el trafico saliente?
>
> > sgg@host:~$ telnet ippublica puerto
> > Trying ippublica...
> > telnet: Unable to connect to remote host: Connection timed out
> > sgg@host:~$
>
> > En el asterisk
> > root@host:/etc/asterisk# ngrep -P ' ' -W byline -T port 5038
> > interface: eth0 (192.168.1.0/255.255.255.0)
> > filter: (ip or ip6) and ( port 5038 )
> > ##
> > 2 received, 0 dropped
>
> > On 22 Juny, 13:18, Iñaki Baz Castillo <i...@aliax.net> wrote:
> > > El día 22 de junio de 2011 13:17, TelecoSilvia
> > > <telecosil...@gmail.com> escribió:
>
> > > > Nada.
>
> > > ¿Pero se establece la conexión TCP y el cliente envía datos AMI al
> > > 5038 de Asterisk? ¿o ni siquiera se establece la conexión TCP?
>
> > > --
> > > Iñaki Baz Castillo
> > > <i...@aliax.net>
>
> > --
> > Este email pertenece a la lista de Asterisk-ES (http://www.asterisk-es.org
> > )
>
> > ~~~ Normas de la lista Asterisk-ES: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Iñaki Baz Castillo
<teleco...@gmail.com> escribió:
> No, y como ves con el ngrep llegan los dos paquetes de petición a la
> centralita.
Llega un intento de conexión TCP, pero no se establece por lo que no
llegan datos a nivel de aplicación (AMI en este caso).
Yo haría un tcpdump en la centralita:
tcpdump -i any -n port 5038
e intenta conectar por telnet desde el exterior. Así veremos mejor qué
ocurre (ngrep está bien si se ha llegado a establecer la conexión TCP,
si no, sirve de poco).
samuel
Pongo con 5037 como ejemplo:
centralita: nc -l -p 5037
remoto: nc ipcentralita 5037
a partir de ese momento debería tener un socket que escribiendo en la máquina remota debería aparecer en el servidor. Mirando con ngrep también podrás ver los paquetes.
sort!
Samuel.
--
Este email pertenece a la lista de Asterisk-ES (http://www.asterisk-es.org)
~~~ Normas de la lista Asterisk-ES: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Angel Elena
Hmm, el proveedor no te estará filtrando el tráfico ???
Me topé en una ocasión con un appliance radware (en modo transparente,
teóricamente) que me filtraba / modificaba el tráfico en el datacenter
del cloud.... un aplicativo cliente / servidor que usaba el puerto 10000
udp y de 10 conexiones, me llegaban 3.
TelecoSilvia
como de costumbre, jejeje
Iñaki Baz Castillo
<teleco...@gmail.com> escribió:
> Gracias crakcs! Voy a hacer más pruebas y a increpar a el proveedor
> como de costumbre, jejeje
tcpdump tcpdump ;)
TelecoSilvia
tcpdump: verbose output suppressed, use -v or -vv for full protocol
decode
listening on any, link-type LINUX_SLL (Linux cooked), capture size
65535 bytes
16:43:55.420796 IP 80.25.180.5.48346 > 192.168.1.250.5038: Flags [S],
seq 1222075610, win 5840, options [mss 1360,sackOK,TS val 6972046 ecr
0,nop,wscale 7], length 0
16:43:55.420831 IP 192.168.1.250.5038 > 80.25.180.5.48346: Flags [R.],
seq 0, ack 1222075611, win 0, length 0
16:43:58.424505 IP 80.25.180.5.48346 > 192.168.1.250.5038: Flags [S],
seq 1222075610, win 5840, options [mss 1360,sackOK,TS val 6972796 ecr
0,nop,wscale 7], length 0
16:43:58.424532 IP 192.168.1.250.5038 > 80.25.180.5.48346: Flags [R.],
seq 0, ack 1, win 0, length 0
16:44:04.418513 IP 80.25.180.5.48346 > 192.168.1.250.5038: Flags [S],
seq 1222075610, win 5840, options [mss 1360,sackOK,TS val 6974296 ecr
0,nop,wscale 7], length 0
16:44:04.418544 IP 192.168.1.250.5038 > 80.25.180.5.48346: Flags [R.],
seq 0, ack 1, win 0, length 0
^C
6 packets captured
6 packets received by filter
0 packets dropped by kernel
On 22 Juny, 16:03, Iñaki Baz Castillo <i...@aliax.net> wrote:
> El día 22 de junio de 2011 15:54, TelecoSilvia
Iñaki Baz Castillo
> root@host:/# tcpdump -i any -n port 5038
> tcpdump: verbose output suppressed, use -v or -vv for full protocol
> decode
> listening on any, link-type LINUX_SLL (Linux cooked), capture size
> 65535 bytes
> 16:43:55.420796 IP 80.25.180.5.48346 > 192.168.1.250.5038: Flags [S],
> seq 1222075610, win 5840, options [mss 1360,sackOK,TS val 6972046 ecr
> 0,nop,wscale 7], length 0
> 16:43:55.420831 IP 192.168.1.250.5038 > 80.25.180.5.48346: Flags [R.],
> seq 0, ack 1222075611, win 0, length 0
> 16:43:58.424505 IP 80.25.180.5.48346 > 192.168.1.250.5038: Flags [S],
> seq 1222075610, win 5840, options [mss 1360,sackOK,TS val 6972796 ecr
> 0,nop,wscale 7], length 0
> 16:43:58.424532 IP 192.168.1.250.5038 > 80.25.180.5.48346: Flags [R.],
> seq 0, ack 1, win 0, length 0
> 16:44:04.418513 IP 80.25.180.5.48346 > 192.168.1.250.5038: Flags [S],
> seq 1222075610, win 5840, options [mss 1360,sackOK,TS val 6974296 ecr
> 0,nop,wscale 7], length 0
> 16:44:04.418544 IP 192.168.1.250.5038 > 80.25.180.5.48346: Flags [R.],
> seq 0, ack 1, win 0, length 0
Buff, ni idea. Prueba lo siguiente si te es posible:
- Apaga el asterisk un ratito.
- En el server Asterisk:
~# nc -l -p 5038 IP_PRIVADA_DE_ESTE_SERVER
- En el server remoto:
~# telnet IP_PUBLICA_DEL_ASTERISK 5038
- Si se establece la conexión, escribe "hay vida más allá de asterisk".
- ¿Llega eso al server asterisk? debería pintarse en pantalla.
TelecoSilvia
un nat de otro puerto al 5038.
El sistema está en megaproducción o sea que lo pruebo mañana. Si les
paro el asterisk ahora creo que me cortan la cabeza.
:P
On 22 Juny, 16:59, Iñaki Baz Castillo <i...@aliax.net> wrote:
> 2011/6/22 TelecoSilvia <telecosil...@gmail.com>:
TelecoSilvia
----------------------------------------
root@host:/etc/asterisk# nc -l -p 5038 &
[1] 1703
root@host:/etc/asterisk# ps
PID TTY TIME CMD
1703 pts/0 00:00:00 nc
1712 pts/0 00:00:00 ps
23415 pts/0 00:00:00 su
23424 pts/0 00:00:00 bash
root@host:/etc/asterisk# netstat -nel
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address
State User Inode
tcp 0 0 0.0.0.0:5038 0.0.0.0:*
LISTEN 0 20652058
root@host:/etc/asterisk# tcpdump -i any -n port 5038
decode
listening on any, link-type LINUX_SLL (Linux cooked), capture size
65535 bytes
seq 2019503517, win 5840, options [mss 1360,sackOK,TS val 7669371 ecr
seq 2432391856, ack 2019503518, win 5792, options [mss 1460,sackOK,TS
val 800552955 ecr 7669371,nop,wscale 6], length 0
17:30:27.951514 IP 80.25.180.5.43349 > 192.168.1.250.5038: Flags [S],
seq 2019503517, win 5840, options [mss 1360,sackOK,TS val 7670121 ecr
seq 2432391856, ack 2019503518, win 5792, options [mss 1460,sackOK,TS
val 800553700 ecr 7669371,nop,wscale 6], length 0
17:30:28.171747 IP 192.168.1.250.5038 > 80.25.180.5.43349: Flags [S.],
seq 2432391856, ack 2019503518, win 5792, options [mss 1460,sackOK,TS
val 800553755 ecr 7669371,nop,wscale 6], length 0
17:30:33.950585 IP 80.25.180.5.43349 > 192.168.1.250.5038: Flags [S],
seq 2019503517, win 5840, options [mss 1360,sackOK,TS val 7671621 ecr
seq 2432391856, ack 2019503518, win 5792, options [mss 1460,sackOK,TS
val 800555199 ecr 7669371,nop,wscale 6], length 0
17:30:34.571701 IP 192.168.1.250.5038 > 80.25.180.5.43349: Flags [S.],
seq 2432391856, ack 2019503518, win 5792, options [mss 1460,sackOK,TS
val 800555355 ecr 7669371,nop,wscale 6], length 0
17:30:47.371700 IP 192.168.1.250.5038 > 80.25.180.5.43349: Flags [S.],
seq 2432391856, ack 2019503518, win 5792, options [mss 1460,sackOK,TS
val 800558555 ecr 7669371,nop,wscale 6], length 0
^C
9 packets captured
13 packets received by filter
----------------------------------------------
sgg@OptiFuture:~$ telnet ippublica puerto
Trying ippublica...
hay alguien al otro lado
Iñaki Baz Castillo
> 17:30:24.971280 IP 80.25.180.5.43349 > 192.168.1.250.5038: Flags [S],
> seq 2019503517, win 5840, options [mss 1360,sackOK,TS val 7669371 ecr
> 0,nop,wscale 7], length 0
El primero es el intento de conexión TCP desde el server remoto (un
SYN). Fíjate que llega al server Asterisk, y anuncia un número de
secuencia de 2019503517 (esto es el número inicial de secuencia de
datos TCP desde el server remoto al asterisk).
> 17:30:24.971324 IP 192.168.1.250.5038 > 80.25.180.5.43349: Flags [S.],
> seq 2432391856, ack 2019503518, win 5792, options [mss 1460,sackOK,TS
> val 800552955 ecr 7669371,nop,wscale 6], length 0
Ahora el server asterisk le response un ACK indicando 2019503518, o
sea, el siguiente número de secuencia TCP que espera recibir del
remoto. A su vez, el server asterisk le indica al remoto (SYN) el
número de secuencia TCP en la comunicación en sentido asterisk ->
remoto: 2432391856.
> 17:30:27.951514 IP 80.25.180.5.43349 > 192.168.1.250.5038: Flags [S],
> seq 2019503517, win 5840, options [mss 1360,sackOK,TS val 7670121 ecr
> 0,nop,wscale 7], length 0
Aquí el remoto envía una retransmisión del primer paquete TCP, o sea,
el SYN inicial. Fíjate que sigue anunciando seq 2019503517, y que no
incluye un ACK para reconocer el número de secuencia enviado por el
server asterisk, etc.
O sea, el intento de conexión del remoto llega a Asterisk. Las
respuestas de Asterisk, pese a ir encaminadas a la IP y puerto del
remoto, no llegan. Esto puede ser un problema de dos tipos (igual hay
más):
1) Tienes un horrible firewall en el server asterisk que no permite el
tráfico TCP saliente ni siquiera como respuesta a una conexión
iniciada/iniciándose desde el exterior (esto es muy raro de ver creo
yo, habría que configurar el firewall con muy mala leche). O puede que
sea que el remoto tiene un firewall que NO permite tráfico TCP
entrante de respuesta a un intento de conexión TCP hacia fuera (más
posible que lo primero). En este punto, yo probaría a tratar de hacer
la conexión desde cualquier otra IP del mundo.
2) Un problema de routing IP. Comprueba las routas en el server
asterisk o en el supuesto router. Lo que está claro es que la
respuesta TCP del server no llega al remoto.
Lo que sí es seguro es que el problema no tiene nada que ver con
Asterisk ni la configuración de AMI puesto que ni se ha podido llegar
a ese nivel (en realidad no se ha establecido ni la conexión TCP).
Sir Brain Colward
2011/6/22 TelecoSilvia <teleco...@gmail.com>:
--
Este email pertenece a la lista de Asterisk-ES (http://www.asterisk-es.org)
~~~ Normas de la lista Asterisk-ES: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Iñaki Baz Castillo
<col...@gmail.com> escribió:
> Pero si te fijas en la traza inicial cuando viene el paquete de conexión con
> el flag SYN, el servidor le responde siempre con un paquete con el flag
> RESET activo. O sea, que aparte de un tema de routing, algo le está parando.
> O bien el asterisk corta la conexión directamente o bien iptables.
Humm, no dudo en absoluto de lo que dices pero, ¿dónde ves el bit
RESET? ¿qué símbolo lo está representando en la salida de tcpdump? (lo
digo porque no lo sé).
Pero me mosquea una cosa: si es un RESET, ¿por qué el remoto vuelve a
enviar un intento de conexión al de *3* segundos con exactametne el
mismo valor de secuencia (que se supone es aleatorio en cada inicio de
conexión)?
Iñaki Baz Castillo
De hecho, se supone que el bit RESET se activa para indicar que no hay
ningún servicio escuchando en el puerto contactado. Si lo pruebo con
mi host veo claramente esto:
00:52:10.024838 IP MI_IP.48410 > MI_SERVER.9999: S
2108481433:2108481433(0) win 14600 <mss 1402,sackOK,timestamp 1186890
0,nop,wscale 7>
00:52:10.024974 IP MI_SERVER.9999 > MI_IP.48410: R 0:0(0) ack 2108481434 win 0
Ahí veo claramente la "R" en la respuesta. Pero en el caso que nos
ocupa no es ni parecido.
TelecoSilvia
Teniendo en cuenta que en el asterisk para hacer las pruebas había
abierto todo con el iptables:
Chain INPUT (policy ACCEPT)
target prot opt source destination
Chain FORWARD (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
Me decanto por un problema en el firewall del cliente o en el router
del proveedor.
Voy a probar de acceder desde otras ip's y ha pelearme con ello.
Cierro el thearth porque efectivamente no tiene nada que ver con
asterisk.
Thanks!
On 23 Juny, 00:54, Iñaki Baz Castillo <i...@aliax.net> wrote:
> El día 23 de junio de 2011 00:41, Iñaki Baz Castillo <i...@aliax.net> escribió:
>
> > El día 22 de junio de 2011 23:53, Sir Brain Colward
Sir Brain Colward
Iñaki Baz Castillo
Disculpad el top posting. Cosas dr android...
Fíjate que en la traza última de Silvia no hay ningún flag R.
El 23/06/2011 20:10, "Sir Brain Colward" <col...@gmail.com> escribió:Me baso en esto:16:43:55.420831 IP 192.168.1.250.5038 > 80.25.180.5.48346: Flags [R.],Y el que el remoto vuelva a intentar confirma que no le llegan los paquetes, ni aún con el reset.Por lo que yo creo que hay/había dos problemas. Uno de enrutado/firewall y otro en el propio asterisk.Pero bueno, dejemos que primero resuelva el enrutado/firewall y ya si sigue con problemas, analizaremos los nuevos problemas.Sir Brain Colward
2011/6/23 Iñaki Baz Castillo <i...@aliax.net>
>
> El día 22 de junio de 2011 23:53, Sir Brain Colward
> <col...@gmail.com> escribió:
> > Pero si ...
> Iñaki Baz Castillo
> <i...@aliax.net>
>
> --
> Este email pertenece a la lista de Asterisk-ES (http://www.asterisk-es.org)
>
> ~~~ Normas de...
--
Este email pertenece a la lista de Asterisk-ES (http://www.asterisk-es.org)
~~~ Normas de la...
Sir Brain Colward
Su prefieres, podemos seguir debatiendo esto fuera de lista, porque me parece ya off-topic (a no ser que alguien esté interesado en estas rayadas).
Sir Brain Colward
Juan Medina
Hola, yo tenia el mismo problema y lo solucione siguiendo lo que dicen
en esta pagina:
http://www.didww.com/Knowledgebase/sip_with_firewall_nat_using_asterisk/
espero te sirva de algo.