Problemas con IP alias y "bindaddr" en sip.conf
Iñaki Baz Castillo
una IP alias.
Supongamos el servidor con las IP's:
- eth0: 22.22.22.10
- eth0:1 22.22.22.1
Si pongo en sip.conf:
bindaddr = 22.22.22.1
entonces Asterisk sólo permite tráfico SIP con destino la IP alias 22.22.22.1
(parece correcto), rechazando el tráfico a la 22.22.22.10 con "403
Forbidden", perfecto.
Pero si pongo en sip.conf:
bindaddr = 0.0.0.0 (en todos los interfaces)
entonces resulta que Asterisk sólo permite tráfico SIP con destino la IP
22.22.22.10, prohibiendo con "403" el tráfico a la IP alias 22.22.22.1.
Esto no tiene sentido alguno.
¿Alguien se ha encontrado con esto y lo puede confirmar?
--
Iñaki Baz Castillo
<ib...@xtratelecom.es>
Raúl Alexis Betancor Santana
> Hola, he comprobado un comportamiento bastante fuera de lugar cuando se usa
> una IP alias.
>
> Supongamos el servidor con las IP's:
>
> - eth0: 22.22.22.10
> - eth0:1 22.22.22.1
>
> Si pongo en sip.conf:
> bindaddr = 22.22.22.1
> entonces Asterisk sólo permite tráfico SIP con destino la IP alias
> 22.22.22.1 (parece correcto), rechazando el tráfico a la 22.22.22.10 con
> "403 Forbidden", perfecto.
>
> Pero si pongo en sip.conf:
> bindaddr = 0.0.0.0 (en todos los interfaces)
> entonces resulta que Asterisk sólo permite tráfico SIP con destino la IP
> 22.22.22.10, prohibiendo con "403" el tráfico a la IP alias 22.22.22.1.
> Esto no tiene sentido alguno.
Si tiene sentido, todo el del mundo, Asterisk no soporta multihoming, es un
tema que se ha discutido hasta la saciedad.
> ¿Alguien se ha encontrado con esto y lo puede confirmar?
Te lo confirmo, te lo confirmo, incluso intentamos corregir ese comportamiento
del chan_sip, pero no hay tutía, como una interfaz tenga más de una IP,
Asterisk hace guarradas a tutiplen.
Son cutres a mas no poder.
--
Raúl Alexis Betancor Santana
Dimensión Virtual
Germán Aracil Boned
adicional para dar servicio y no he intentado hacerlo con la primera ip.
De todas formas.. creas la ruta correcta para que por el interface
eth0:1 tenga salida a internet u otras redes a las que precises acceder ?
Raúl Alexis Betancor Santana escribió:
--
-
-------------------------------------
Germán Aracil Boned
Director de Sistemas
Zoon Suite S.L.
www.zoonsuite.com
963146030 - General
963146031 - Asistencia de incidencias
963146032 - FAX
-------------------------------------
-
davidp
> Si pongo en sip.conf:
> bindaddr = 22.22.22.1
> entonces Asterisk sólo permite tráfico SIP con destino la IP alias 22.22.22.1
> (parece correcto), rechazando el tráfico a la 22.22.22.10 con "403
> Forbidden", perfecto.
"escuchara" conexiones por esa IP, y no aceptara conexiones por otras
IPs, pero a un nivel más bajo. Es decir: no que te devuelva un "403
forbidden", sino que simplemente no escuchara las peticiones que le
llegan por esa otra IP.
davidp.
Elio Rojano
http://www.sinologic.net/
Iñaki Baz Castillo
> > Pero si pongo en sip.conf:
> > bindaddr = 0.0.0.0 (en todos los interfaces)
> > entonces resulta que Asterisk sólo permite tráfico SIP con destino la IP
> > 22.22.22.10, prohibiendo con "403" el tráfico a la IP alias 22.22.22.1.
> > Esto no tiene sentido alguno.
>
> Si tiene sentido, todo el del mundo, Asterisk no soporta multihoming, es un
> tema que se ha discutido hasta la saciedad.
Vaya, pensaba que lo que no soportaba era multihoming un poco más "complejo",
qué mal...
> > ¿Alguien se ha encontrado con esto y lo puede confirmar?
>
> Te lo confirmo, te lo confirmo, incluso intentamos corregir ese
> comportamiento del chan_sip, pero no hay tutía, como una interfaz tenga más
> de una IP, Asterisk hace guarradas a tutiplen.
Confirmado queda, gracias.
Iñaki Baz Castillo
Tendría sentido, pero como dice Elio, sinceramente yo sólo confiaría en
Iptables para ese cometido, y nunca en la capa de aplicación.
davidp
On 21 ene, 09:36, Elio Rojano <hel...@gmail.com> wrote:
> Madre mía... utiliza un bindaddr=0.0.0.0 y usa el iptables como todo el
> mundo! >:)
>
ocurre ;-)
davidp.
David Calvache
>
> Supongamos el servidor con las IP's:
>
> - eth0: 22.22.22.10
> - eth0:1 22.22.22.1
>
>
> bindaddr = 0.0.0.0 (en todos los interfaces)
> entonces resulta que Asterisk sólo permite tráfico SIP con destino la IP
> 22.22.22.10, prohibiendo con "403" el tráfico a la IP alias 22.22.22.1.
> Esto no tiene sentido alguno.
heartbeat el que levanta la interfaz eth0:1 Asterisk si responde a la
vez a ambas ip estando bindeado a 0.0.0.0.
En otra maquina yo tengo tambien levantadas ips virtuales y asterisk
tambien me constesta a ambas ips, lo que si es cierto es que asterisk
solo devuelve el trafico a traves de la ip no virtual.
Es decir, tenemos una extension registrada con la 22.22.22.1 y el
audio pasando por asterisk y los paquetes de subida trabajan con la
22.22.22.1 y en los paquetes de bajada le llegan al telefono desde la
22.22.22.10.
Si en mi caso funciona , no entiendo porque a ti no. Y ya puesto al
caso,¿como podria hacer para que en ambos casos el asterisk me
devolviera el trafico por la ip no virtual?
Iñaki Baz Castillo
> Es decir, tenemos una extension registrada con la 22.22.22.1 y el
> audio pasando por asterisk y los paquetes de subida trabajan con la
> 22.22.22.1 y en los paquetes de bajada le llegan al telefono desde la
> 22.22.22.10.
Gracias por el dato.
> Si en mi caso funciona , no entiendo porque a ti no.
Porque mi tfno está detrás de NAT, así que si envío un REGISTER a la IP1 y
Asterisk me devuelve desde la IP2, la respuesta no va a pasar el NAT.
> Y ya puesto al
> caso,¿como podria hacer para que en ambos casos el asterisk me
> devolviera el trafico por la ip no virtual?
Creo que Raúl tiene "buenas" experiencias tratando de lograr eso... XD
Julian J. M.
> El Friday 23 January 2009 10:31:57 David Calvache escribió:
>> Si en mi caso funciona , no entiendo porque a ti no.
>
> Porque mi tfno está detrás de NAT, así que si envío un REGISTER a la IP1 y
> Asterisk me devuelve desde la IP2, la respuesta no va a pasar el NAT.
Con iptables se puede reescribir la IP de origen y forzarla a la de la
IP virtual (eth0:1), pero claro entonces las peticiones a la IP real
(eth0) tendrán el mismo problema ;)
Una ñapa, la verdad, aunque no creo que sea muy complicado parchear esto.
Julian J. M.
Raúl Alexis Betancor Santana
> Mmmm, perdonad que pregunte una cosa, pero en el caso de que sea
> heartbeat el que levanta la interfaz eth0:1 Asterisk si responde a la
> vez a ambas ip estando bindeado a 0.0.0.0.
Nadie ha dicho que no responda, se ha dicho que no lo hace como debe.
> En otra maquina yo tengo tambien levantadas ips virtuales y asterisk
> tambien me constesta a ambas ips, lo que si es cierto es que asterisk
> solo devuelve el trafico a traves de la ip no virtual.
Equilicua ... asterisk solo devuelve tráfico por la IP "primaria" del interfaz,
ignorando totalmente por que IP le llegó y por tanto saltandose el estandar a
saco.
> Es decir, tenemos una extension registrada con la 22.22.22.1 y el
> audio pasando por asterisk y los paquetes de subida trabajan con la
> 22.22.22.1 y en los paquetes de bajada le llegan al telefono desde la
> 22.22.22.10.
Y te funciona por la simple magia de que ambas IP's son del mismo rango y
porque en la respuesta SDP Asterisk pone la IP primaria como IP de Media y es
ahí donde el teléfono mandará el tráfico RTP y desde donde Asterisk se lo
enviará al terminal.
De hecho el dialog SIP suele palmarla.
> Si en mi caso funciona , no entiendo porque a ti no. Y ya puesto al
> caso,¿como podria hacer para que en ambos casos el asterisk me
> devolviera el trafico por la ip no virtual?
Si haces trazas SIP, verás que "te funciona" de chiripa.
--
Raúl Alexis Betancor Santana
Dimensión Virtual S.L.
Raúl Alexis Betancor Santana
> Creo que Raúl tiene "buenas" experiencias tratando de lograr eso... XD
La única forma semi-limpia de que funcione, es usar siproxd y colgarlo de
ambas IP's y hacer que el flujo sea:
Asterisk <-> siproxd <-> UAC/UAS
Y la config es bastante guarra.
David Calvache
> Si haces trazas SIP, verás que "te funciona" de chiripa.
>
aceptable :)
Iñaki Baz Castillo
> > Es decir, tenemos una extension registrada con la 22.22.22.1 y el
> > audio pasando por asterisk y los paquetes de subida trabajan con la
> > 22.22.22.1 y en los paquetes de bajada le llegan al telefono desde la
> > 22.22.22.10.
>
> Y te funciona por la simple magia de que ambas IP's son del mismo rango y
> porque en la respuesta SDP Asterisk pone la IP primaria como IP de Media y
> es ahí donde el teléfono mandará el tráfico RTP y desde donde Asterisk se
> lo enviará al terminal.
> De hecho el dialog SIP suele palmarla.
Respuesta chorra en plan pro-Asterisk:
"seguro que eso lo puedes corregir con un AGI"
ops...
Raúl Alexis Betancor Santana
> Una ñapa, la verdad, aunque no creo que sea muy complicado parchear esto.
uy, uy, uy ... que me digas tú que parchear chan_sip no es complicado .. XDD
... hay prácticamente que reescribirlo, porque para empezar hay cosas que
siendo "la misma" las hacen de 3 o 4 formas diferentes, en función del fulano
que desarrolló esa parte.
Saludos
Iñaki Baz Castillo
> El Friday 23 January 2009 11:16:24 Julian J. M. escribió:
> > Una ñapa, la verdad, aunque no creo que sea muy complicado parchear esto.
>
> uy, uy, uy ... que me digas tú que parchear chan_sip no es complicado ..
> XDD ... hay prácticamente que reescribirlo, porque para empezar hay cosas
> que siendo "la misma" las hacen de 3 o 4 formas diferentes, en función del
> fulano que desarrolló esa parte.
¿Para qué desarrollar SIP teniendo IAX? IAX es mejor porque permite infinitas
cosas menos que SIP y además emula el sistema de telefonía analógico
prehistórico (señalización y media por el mismo canuto) haciéndose
anti-nescalable para su uso en terminales.
Pero eso da igual porque "IAX es mejor para el NAT..."