Dos dudas sobre la configuración de VoIP en Movistar

Hola!

Este es un post que bien podría haber sido un mensaje directo a @furny, pero prefiero expresarlo aquí, por si a alguien más le ha surgido la misma duda y/o tiene la respuesta. Para la configuración del teléfono (VoIP) en telefónica movistar / O2, usamos RIP como protocolo dinámico para el descubrimiento de rutas, y así obtener una IP interna (del segmento 10.0.0.0/:cool: para nuestra "interfaz" VoIP. Hasta aquí, todo correcto. Sin embargo, hay dos reglas de firewall que me matan y no consigo entender del todo.

La primera, aceptar el tráfico de esa red en el chain de input:
Código:
/ip firewall filter 
add action=accept chain=input comment="allow voip traffic" in-interface=vlan-voip-o2 src-address=10.0.0.0/8
Esta es la que más me mata. ¿porqué necesita esa VLAN y el tráfico que viene de esa subred, acceso a mi propio router? Me explico: no estamos hablando de una regla en el chain de forward, con destino mi LAN, sino una regla específica para que esa subred acceda al propio router, en el chain de input ¿qué sentido tiene? ¿Lo necesita el propio RIP, como protocolo, para trabajar?

Asociado a esta, viene la segunda:
Código:
/ip firewall nat 
add action=masquerade chain=srcnat comment=masquerade-voip out-interface=vlan-voip-o2
¿Por qué necesitamos enmascarar el tráfico que sale por esa VLAN? Es decir, si ya tenemos una IP privada interna del segmento 10.0.0.0/8 que nos ha entregado el cliente DHCP levantado sobre esa VLAN, y RIP ha hecho lo propio para crear una tabla de rutas donde el destino de esos paquetes sigue siendo ese mismo segmento de red, y además tenemos una VLAN dedicada (es decir, este tráfico no va a cambiar la IP privada por la IP pública de la parte de internet, ese tráfico va por otro lado), ¿cual es el propósito de ese masquerade? ¿Cuál es la IP pública por la que se está cambiando (un masquerade / src-nat no deja de ser eso) esa IP privada? Entiendo que, al estar detrás de un NAT, y no tener una IP pública como tal para el VoIP, nos hace falta un masquerade. Pero, ¿no se supone que toda esa red es privada de telefónica, y que nosotros tenemos IP's finales no nateadas dentro de ese segmento, que justo para eso tienen una VLAN aparte, en lugar de mezclar el tráfico con el de internet? ¿Cómo se relaciona esto con el helper de SIP que trae el router? ¿tiene relación alguna o son cosas distintas?

La configuración que tenemos en los manuales funciona, y está mas que probada, pero por más vueltas que le doy, siempre me quedan esas dos dudas bailando.

Si alguien tiene una idea muy clara del porqué de estas dos cosas, le agradecería lo compartiera con nosotros.

Saludos!
 
Te intento responder a bote pronto, pero lo estudio y repaso y después, si acaso doy una respuesta más detallada:

VOIP va en realidad, en Telefónica al menos, por multicast. Esto es así para permitir que varios teléfonos conectados a la LAN puedan participar de las conversaciones (lo cuento así para simplificar el tema). Cuando es multicast (por UDP) no se manda a una dirección específica de la LAN, sino a las reservadas de multicast (que depende del tipo de multicast que se use, para detalle posterior). Por eso van "dirigidas al router" y el router debe aceptarlo en nombre de todos los suscriptores posteriores (lo mismo pasa con IPTV: que hay que aceptar el acceso al router de vlan2, para que le lleve al IGMP-proxy).

Además, el protocolo de control es SIP, que va por arriba, nivel 7, con su helper, que esta en el router. Este helper es para permitir varias conversaciones simultáneas paralelas u otras gracias, como conferencia a varios, etc.

SIP además se encarga de la señalización, entre otras cosas. Y tiene que atravesar el NAT. Ahora no recuerdo como iba todo ello, pero creo que puede usar TCP, UDP u otros. En el caso de Telefónica creo que lo recomendado es UDP, y eso uso. Y para ello, viene el masquerade, que, en definitiva, no es tanto para enmascarar nada, sino para encaminar adecuadamente cada una de esas posibles llamadas, a través de numeros de puertos, desde una determinada conexión "externa", la que te ha asignado el servidor de telefónica al hacer el /ip dhcp-client.

Esta es la explicación simple. Para una más profesional y certera, si quieres, déjame que me repase el SIP, que lo tengo muy olvidado.

Saludos!!
 
Es suficiente, pero si algún día tienes un rato libre y quieres profundizar en el tema, yo encantado. Ahora me encajan más esas dos reglas, tiene sentido, cuando metes el multicast de por medio.

Saludos!
 
Si quieres, puedes sustituir la regla firewall por esta:

/ip firewall filter
add action=accept chain=input comment="allow voip traffic" in-interface=vlan-voip-o2 src-address=10.0.0.0/8 dst-address-type=!unicast

e incluso puedes eliminar el término src-address=10.0.0.0/8, para admitir, si acaso te diera problemas en el futuro, tráfico desde otros servidores de Telefónica, si los cambiaran. Así, solo permites la entrada de tráfico multicast y broadcast, que es lo que en realidad interesa.

Saludos!
 
Arriba