Hola, tengo una duda de concepto sobre el ALG para SIP que implementan algunos routers.
Ya os comenté que el SpeedTouch no mantiene el puerto abierto y redirigido, y mi duda es si debería o no hacerlo.
Es decir, para realizar llamadas y solventar el NAT el router ALG sólo tiene que interceptar el INVITE y cambiar el Contact y SDP. En ese momento se produce una conexión UDP que dura poco y se mantiene el keepalive UDP del router (normalmente 20-30 segundos creo).
Pero pare recibir llamadas es necesario que el router, al detectar un REGISTER saliente (con éxito) deje el puerto abierto y redirigido al host local indefinidamente. Pero claro, el router no puede saber cuándo se envía un un-REGISTER ya que desde un mismo dispositivo SIP puede haber varias cuentas registradas. Y dudo muchísimo que el router almacena datos SIP para saber qué cuentas se han registrado.
Y por supuesto, el cliente SIP no tiene razón alguna para enviar ningún tipo de keepalive (sólo lo haría si usa STUN).
Sólo se me ocurre poner la periodicidad del REGISTER a menos tiempo del keepalive UDP del router (o aumentar éste si se puede), pero me parece una guarrada (sobre todo porque el proxy SIP puede limitar el tiempo mínimo de entre registros)
O sea, mi conclusión un poco alarmista es que el ALG de los routers sólo sirve para corregir el NAT en llamadas salientes.
¿Me equivoco en algo? ¿es correcta mi conclusión?
Gracias por cualquier explicación.
Hola Iñaki,
Hola, tengo una duda de concepto sobre el ALG para SIP que implementan algunos routers.
Ya os comenté que el SpeedTouch no mantiene el puerto abierto y redirigido, y mi duda es si debería o no hacerlo.
Es decir, para realizar llamadas y solventar el NAT el router ALG sólo tiene que interceptar el INVITE y cambiar el Contact y SDP. En ese momento se produce una conexión UDP que dura poco y se mantiene el keepalive UDP del router (normalmente 20-30 segundos creo).
Pero pare recibir llamadas es necesario que el router, al detectar un REGISTER saliente (con éxito) deje el puerto abierto y redirigido al host local indefinidamente. Pero claro, el router no puede saber cuándo se envía un un-REGISTER ya que desde un mismo dispositivo SIP puede haber varias cuentas registradas. Y dudo muchísimo que el router almacena datos SIP para saber qué cuentas se han registrado.
Y por supuesto, el cliente SIP no tiene razón alguna para enviar ningún tipo de keepalive (sólo lo haría si usa STUN).
Sólo se me ocurre poner la periodicidad del REGISTER a menos tiempo del keepalive UDP del router (o aumentar éste si se puede), pero me parece una guarrada (sobre todo porque el proxy SIP puede limitar el tiempo mínimo de entre registros)
O sea, mi conclusión un poco alarmista es que el ALG de los routers sólo sirve para corregir el NAT en llamadas salientes.
¿Me equivoco en algo? ¿es correcta mi conclusión?
Por normal general, el ALG de los routers no sirve para nada... bueno, sí, para joder las cosas :-/
Para mantener la traslación de NAT activa en el router puedes usar:
http://www.openser.org/docs/modules/1.2.x/nathelper.html#AEN218
Pero, según lo que reescriba el ALG y dependiendo de como tengas configurado el nat_uac_test() puede que nathelper no detecte que ese equipo está detrás de un NAT y no le envíe ningún keepalive.
Ciertamente, un router tiene que enrutar, nada más!!.
Saludos JesusR.
------------------------------------ Jesus Rodriguez VozTelecom Sistemas, S.L. jesusr@voztele.com http://www.voztele.com Tel. 902360305 -------------------------------------
El Jueves, 22 de Noviembre de 2007, Jesus Rodriguez escribió:
Por normal general, el ALG de los routers no sirve para nada... bueno, sí, para joder las cosas :-/
Me voy dando cuenta a palos, dos de dos.
Para mantener la traslación de NAT activa en el router puedes usar:
http://www.openser.org/docs/modules/1.2.x/nathelper.html#AEN218
Pero, según lo que reescriba el ALG y dependiendo de como tengas configurado el nat_uac_test() puede que nathelper no detecte que ese equipo está detrás de un NAT y no le envíe ningún keepalive.
Ahí está el problema. Entiendo yo que si el router ALG hace bien dicha función el paquete "aparenta" llegar a OpenSer desde una IP pública a todos los efectos (como con STUN), así que no se mantendría el keepalive por OPTIONS entrantes periódicos.
Aunque en el router rancio que tengo (SpeedTouch ST350v6), es curioso ver que el mensaje SIP sale nateado por un puerto público (por ejemplo 14000) pero en el "Contact" indica otro puerto (14002 por ejemplo).
Y como hago un nat_uac_test("19") se compara la IP origen con la del Contact y no coinciden y se mantendría el keepalive, pero de pura pura chiripa. ¿Es normal que indiquen un puerto en el Contact y salgan por otro? (apuesto a que es otra cagada).
Ciertamente, un router tiene que enrutar, nada más!!.
En el mundo de fantasía del IETF puede ser. pero aquí abajo existe el NAT, los pseudo-administradores de sistemas que bloquean los pings "por seguridad", e incluso los que no configuran keepalive UDP en sus firewall y es **imposible** usar un dispositivo SIP UDP desde dentro (lo he visto ya en varios sitios y casi me echo a llorar).
En fin...
Buena noches.
El Wednesday 21 November 2007 14:10:45 Iñaki Baz Castillo escribió:
Hola, tengo una duda de concepto sobre el ALG para SIP que implementan algunos routers.
Todavía no he encontrado uno que lo implemente bien.
Ya os comenté que el SpeedTouch no mantiene el puerto abierto y redirigido, y mi duda es si debería o no hacerlo.
No debe, más allá del tiempo de keepalive
Es decir, para realizar llamadas y solventar el NAT el router ALG sólo tiene que interceptar el INVITE y cambiar el Contact y SDP. En ese momento se produce una conexión UDP que dura poco y se mantiene el keepalive UDP del router (normalmente 20-30 segundos creo).
Pero pare recibir llamadas es necesario que el router, al detectar un REGISTER saliente (con éxito) deje el puerto abierto y redirigido al host local indefinidamente. Pero claro, el router no puede saber cuándo se envía un un-REGISTER ya que desde un mismo dispositivo SIP puede haber varias cuentas registradas. Y dudo muchísimo que el router almacena datos SIP para saber qué cuentas se han registrado.
Pero es que entonces ya no es un "router" propiamente dicho, es algo "más avanzado" un transparent proxy sip, que los hay.
Y por supuesto, el cliente SIP no tiene razón alguna para enviar ningún tipo de keepalive (sólo lo haría si usa STUN).
A no ser que le fuerces a ello, como los Grandstream, que se pueden forzar para enviar keepalives y así mantener abiertos siempre los puertos en los routers.
Sólo se me ocurre poner la periodicidad del REGISTER a menos tiempo del keepalive UDP del router (o aumentar éste si se puede), pero me parece una guarrada (sobre todo porque el proxy SIP puede limitar el tiempo mínimo de entre registros)
O sea, mi conclusión un poco alarmista es que el ALG de los routers sólo sirve para corregir el NAT en llamadas salientes.
Alarmista no .. es la realidad.
¿Me equivoco en algo? ¿es correcta mi conclusión?
En lo que te equivocas, querido Iñaki, es en seguir insistiendo en resolver el problema de los NAT desde el lado del cliente, deja de comerte la cabeza con cada posible combinación de NAT y usa nathelper y rtpproxy.
El día que tengamos IPv6 de forma masiva y los fabricantes de los cacharros SIP actualicen las firmwares, se acabaron los problemas de NAT, a no ser que el administrador de turno se quiera complicar la vida.
Saludos
El Thursday 22 November 2007 08:33:44 Raúl Alexis Betancor Santana escribió:
Ya os comenté que el SpeedTouch no mantiene el puerto abierto y redirigido, y mi duda es si debería o no hacerlo.
No debe, más allá del tiempo de keepalive
Me lo temía, pues vaya invento... (aunque ya, que sólo es un router...).
Pero es que entonces ya no es un "router" propiamente dicho, es algo "más avanzado" un transparent proxy sip, que los hay.
¿Pero los hay embebidos en una cajita que se parezca a un router ADSL (y que haga de router ADSL)?
Y por supuesto, el cliente SIP no tiene razón alguna para enviar ningún tipo de keepalive (sólo lo haría si usa STUN).
A no ser que le fuerces a ello, como los Grandstream, que se pueden forzar para enviar keepalives y así mantener abiertos siempre los puertos en los routers.
Buen dato, busqué esa opción por instinto en otros modelos sin éxito.
¿Me equivoco en algo? ¿es correcta mi conclusión?
En lo que te equivocas, querido Iñaki, es en seguir insistiendo en resolver el problema de los NAT desde el lado del cliente, deja de comerte la cabeza con cada posible combinación de NAT y usa nathelper y rtpproxy.
Lo uso, lo uso. El problema es que el ALG funciona por defecto en muchos routers quieras o no (salvo que lo desactives, que igual no siempre se puede si por ejemplo el router no lo gestionas tú). Es decir, yo si llega un INVITE desde/a un usuario en NAT aplico RtpProxy estupendamente. El problema es que si hay un router ALG por medio haciendo de las suyas es imposible detectarlo en OpenSer.
El día que tengamos IPv6 de forma masiva y los fabricantes de los cacharros SIP actualicen las firmwares, se acabaron los problemas de NAT, a no ser que el administrador de turno se quiera complicar la vida.
Esperaré hasta entonces XD
El Thursday 22 November 2007 08:27:43 Iñaki Baz Castillo escribió:
¿Pero los hay embebidos en una cajita que se parezca a un router ADSL (y que haga de router ADSL)?
Cualquier cacharro embedido que corra linux y tenga un modem ADSL incorporado o la opción de engancharle uno por USB o Ethernet, tipo los soekris, los linksys wrt54g o los irongate. En los que puedes instalar sipd en una firmware modificada.
Saludos
El día que tengamos IPv6 de forma masiva y los fabricantes de los cacharros SIP actualicen las firmwares, se acabaron los problemas de NAT, a no ser que el administrador de turno se quiera complicar la vida.
Ojalá tengas razón....mucho me temo que la frase " con IPv6 desaparecerá el NAT" nunca se cumplirá :(
Yo creo que cada vez los routers tendran más software SIP embebido dando por culo.....a ver si ICE se implanta y funciona tan bien como teóricamente parece..
Saludos, sAmuel.
Hola,
El día que tengamos IPv6 de forma masiva y los fabricantes de los cacharros SIP actualicen las firmwares, se acabaron los problemas de NAT, a no ser que el administrador de turno se quiera complicar la vida.
Ojalá tengas razón....mucho me temo que la frase " con IPv6 desaparecerá el NAT" nunca se cumplirá :(
Yo creo que cada vez los routers tendran más software SIP embebido dando por culo.....a ver si ICE se implanta y funciona tan bien como teóricamente parece..
ICE me da que se convertirá en otro dolor de cabeza... es *muy* complicado!.
Saludos JesusR.
------------------------------------ Jesus Rodriguez VozTelecom Sistemas, S.L. jesusr@voztele.com http://www.voztele.com Tel. 902360305 -------------------------------------
ICE me da que se convertirá en otro dolor de cabeza... es *muy* complicado!.
totalmente de acuerdo.....has visto la interoperabilidad de las diferentes implementacinoes en el último SIPit? tenemos (rtp|media)proxy para rato...
saludos, samuel
Hola Samuelm
ICE me da que se convertirá en otro dolor de cabeza... es *muy* complicado!.
totalmente de acuerdo.....has visto la interoperabilidad de las diferentes implementacinoes en el último SIPit?
No, no lo había visto... lo acabo de mirar y es alucinante:
Support for various things in the endpoints: 10% ICE (but there was no interoperability - see below) 0% ICE-TCP
Y este párrafo es matador:
We had a multiparty sesssion for a full morning focusing on NAT traversal. Basic use of STUN with SIP is hightly interoperable. No two implementations of TURN could even start trying to talk to each other (each having implemented to different points in the recent torrent of changes). I don't think we'll get much implementation feedback until the spec stops making big changes so frequently. No two implementations of ICE worked together. The closest was between two implementations that have worked in the past, but failed during this session when the connectivity checks arrived before the SDP.
tenemos (rtp|media)proxy para rato...
Ya te digo, para mucho rato!
Saludos JesusR.
------------------------------------ Jesus Rodriguez VozTelecom Sistemas, S.L. jesusr@voztele.com http://www.voztele.com Tel. 902360305 -------------------------------------
Hola,
Ya os comenté que el SpeedTouch no mantiene el puerto abierto y redirigido, y mi duda es si debería o no hacerlo.
No debe, más allá del tiempo de keepalive
Exacto. Fuerza el keepalive desde la red (si puedes detectar que el UA está detrás de NAT porque si un ALG hace bien su trabajo el nathelper ni se entera) y como último extremo fuerzalo desde el UA.
[...]
O sea, mi conclusión un poco alarmista es que el ALG de los routers sólo sirve para corregir el NAT en llamadas salientes.
Alarmista no .. es la realidad.
¿Me equivoco en algo? ¿es correcta mi conclusión?
En lo que te equivocas, querido Iñaki, es en seguir insistiendo en resolver el problema de los NAT desde el lado del cliente, deja de comerte la cabeza con cada posible combinación de NAT y usa nathelper y rtpproxy.
El día que tengamos IPv6 de forma masiva y los fabricantes de los cacharros SIP actualicen las firmwares, se acabaron los problemas de NAT, a no ser que el administrador de turno se quiera complicar la vida.
Mmmmm... yo no estoy tan seguro :) .
De una forma u otra y mejor o peor el NAT actual es un sistema de seguridad (me refiero a NAT simétrico). Cualquier administrador tendrá miedo de tener todos sus equipos con direccionamiento público y accesible... eso ya te implica políticas de seguridad, restricciones de acceso, firewalls, etc, etc y estoy seguro que miles y miles de pymes y particulares dejarían toda su red completamente abierta.
De todas formas, desde hace años soy uno de los convencidos de que la migración a IPv6 tiene que hacerse sí o sí a pesar de todo lo que conlleva en positivo y en negativo.
Saludos JesusR.
------------------------------------ Jesus Rodriguez VozTelecom Sistemas, S.L. jesusr@voztele.com http://www.voztele.com Tel. 902360305 -------------------------------------
El Thursday 22 November 2007 16:13:37 Jesus Rodriguez escribió:
Exacto. Fuerza el keepalive desde la red (si puedes detectar que el UA está detrás de NAT porque si un ALG hace bien su trabajo el nathelper ni se entera) y como último extremo fuerzalo desde el UA.
Entonces ¿alguien puede explicar para qué demonios inventaron el ALG para SIP si se va a cargar las entrantes sí o sí?
Es que manda ******, si el router no mete las narices al menos nos queda la posibilidad de proxy RTP y keepalive por la evidente detección de NAT en el proxy. Pero si el router se las da de listo y aplica ALG entonces nos fastidia de todas todas las entrantes !!!
De una forma u otra y mejor o peor el NAT actual es un sistema de seguridad (me refiero a NAT simétrico). Cualquier administrador tendrá miedo de tener todos sus equipos con direccionamiento público y accesible...
Pero al menos será más viable poner una regla para permitir el tráfico entrante UDP en un rango de puertos y configurar los dispositivos SIP de la LAN para que usen ese intervalo como puertos RTP.
eso ya te implica políticas de seguridad, restricciones de acceso, firewalls, etc, etc
Y sobre todo: implica "saber" XD
Saludos.
2007/11/22, Iñaki Baz Castillo ibc@in.ilimit.es:
El Thursday 22 November 2007 16:13:37 Jesus Rodriguez escribió:
Exacto. Fuerza el keepalive desde la red (si puedes detectar que el UA está detrás de NAT porque si un ALG hace bien su trabajo el nathelper ni se entera) y como último extremo fuerzalo desde el UA.
Entonces ¿alguien puede explicar para qué demonios inventaron el ALG para SIP si se va a cargar las entrantes sí o sí?
Es que manda ******, si el router no mete las narices al menos nos queda la posibilidad de proxy RTP y keepalive por la evidente detección de NAT en el proxy. Pero si el router se las da de listo y aplica ALG entonces nos fastidia de todas todas las entrantes !!!
Era la única manera de hacer que SIP funcionara "más facilemente" teniendo en cuenta que no había ningún estándard aceptable para solucionar el problema de NAT
De una forma u otra y mejor o peor el NAT actual es un sistema de seguridad (me refiero a NAT simétrico). Cualquier administrador tendrá miedo de tener todos sus equipos con direccionamiento público y accesible...
Pero al menos será más viable poner una regla para permitir el tráfico entrante UDP en un rango de puertos y configurar los dispositivos SIP de la LAN para que usen ese intervalo como puertos RTP.
eso ya te implica políticas de seguridad, restricciones de acceso, firewalls, etc, etc
Y sobre todo: implica "saber" XD
Saludos.
-- Iñaki Baz Castillo ibc@in.ilimit.es
Users-es mailing list Users-es@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/users-es
Hola,
El Thursday 22 November 2007 16:13:37 Jesus Rodriguez escribió:
Exacto. Fuerza el keepalive desde la red (si puedes detectar que el UA está detrás de NAT porque si un ALG hace bien su trabajo el nathelper ni se entera) y como último extremo fuerzalo desde el UA.
Entonces ¿alguien puede explicar para qué demonios inventaron el ALG para SIP si se va a cargar las entrantes sí o sí?
Es que manda ******, si el router no mete las narices al menos nos queda la posibilidad de proxy RTP y keepalive por la evidente detección de NAT en el proxy. Pero si el router se las da de listo y aplica ALG entonces nos fastidia de todas todas las entrantes !!!
Lo mejor es:
- Que tus UA usen un puerto de origen diferente al 5060
- Que tu proxy escuche en un puerto que NO sea el 5060
De esta forma podrás evitarte un montón de ALGs que sólo usan como referencia el puerto de origen y/o destino para detectar que estás pasando un paquete SIP y modificarlo... aunque hay otros que intentan ser más listos todavía y miran el payload del UDP y a esos no los engañas :-/
De una forma u otra y mejor o peor el NAT actual es un sistema de seguridad (me refiero a NAT simétrico). Cualquier administrador tendrá miedo de tener todos sus equipos con direccionamiento público y accesible...
Pero al menos será más viable poner una regla para permitir el tráfico entrante UDP en un rango de puertos y configurar los dispositivos SIP de la LAN para que usen ese intervalo como puertos RTP.
eso ya te implica políticas de seguridad, restricciones de acceso, firewalls, etc, etc
Y sobre todo: implica "saber" XD
/me fully agrees :)
Saludos JesusR.
------------------------------------ Jesus Rodriguez VozTelecom Sistemas, S.L. jesusr@voztele.com http://www.voztele.com Tel. 902360305 -------------------------------------
El Thursday 22 November 2007 16:56:15 Jesus Rodriguez escribió:
Lo mejor es:
Que tus UA usen un puerto de origen diferente al 5060
Que tu proxy escuche en un puerto que NO sea el 5060
De esta forma podrás evitarte un montón de ALGs que sólo usan como referencia el puerto de origen y/o destino para detectar que estás pasando un paquete SIP y modificarlo... aunque hay otros que intentan ser más listos todavía y miran el payload del UDP y a esos no los engañas :-/
Anda, esa es buena, no se me había ocurrido probar :)
El Thursday 22 November 2007 16:56:15 Jesus Rodriguez escribió:
Entonces ¿alguien puede explicar para qué demonios inventaron el ALG para SIP si se va a cargar las entrantes sí o sí?
Bueno, definitivamente se me ha ido la pelota y he escrito en sip-implementaros atreviéndome a dar alguna solución para este tema, supongo que se preguntarán "¿¿pero quién coño es éste??".
Bueno, por si os interesa (o si os queréis reír un rato):
https://lists.cs.columbia.edu/pipermail/sip-implementors/2007-November/01790...
El Friday 23 November 2007 12:12:52 Iñaki Baz Castillo escribió:
El Thursday 22 November 2007 16:56:15 Jesus Rodriguez escribió:
Entonces ¿alguien puede explicar para qué demonios inventaron el ALG para SIP si se va a cargar las entrantes sí o sí?
Bueno, definitivamente se me ha ido la pelota y he escrito en sip-implementaros atreviéndome a dar alguna solución para este tema, supongo que se preguntarán "¿¿pero quién coño es éste??".
Bueno, por si os interesa (o si os queréis reír un rato):
https://lists.cs.columbia.edu/pipermail/sip-implementors/2007-November/0179 04.html
Bueno, voy mejorando. Ahora ya no recibo redirecciones a RFC's, sino a drafts XDDDD
http://www.ietf.org/internet-drafts/draft-ietf-sip-outbound-11.txt
sr-users-es@lists.kamailio.org
-
Iñaki Baz Castillo -
Iñaki Baz Castillo -
Jesus Rodriguez -
Raúl Alexis Betancor Santana -
samuel