El premio de este mes es para nuestro querido amigo Aitor Enzunza, que el otro día dejó un comentario genial en nuestro post de Eric Ros.

Como merece la pena su contenido lo plasmamos aquí y se lleva el premio del mes de febrero consistente en un iPod Shuffle y un Ncora Pack 🙂

_20150316_203043.JPG

Gracias por tu apoyo Aitor!

Hola Eric,

Gran aportacion. Se tiende, erroneamente, a pensar que los equipos de videoconferencia se conectan a la red y funcionan automágicamente. Los protocolos de comunicaciones de video (principalmente H.323 y SIP) son relativamente antiguos y no estaban pensados para funcionar en infraestructuras con NAT, por lo que ha habido que recurrir a un sinfín de trucos en los equipos perimetrales para sortear los problemas existentes.

Déjame hacer unas puntualizaciones.

Por un lado, hay que tener en cuenta que la inspección H.323 RAS (Registration Admission Status) es únicamente necesaria si se realiza un registro en un gatekeeper H.323 ubicado al otro lado del firewall; si no es así, la inspección no realiza ninguna función porque el tráfico de tipo RAS no va a existir.

No es habitual utilizar la figura del gatekeeper en redes de colaboración/videoconferencia relativamente pequeñas, que es un elemento que realiza funciones de directorio de «endpoints» y permite, entre otras cosas, limitar el ancho de banda utilizado para cada uno de los destinos. Si nuestro gatekeeper (GnuGK, Cisco VCS, Lifesize Clearsea… incluso un router Cisco configurado adecuadamente) está en una red alcanzable sin NAT no será necesario ningún truco para que funcione correctamente.

Por otro lado, en tu ejemplo se ha habilitado la inspección por defecto, es decir, se inspeccionará todo el tráfico que atraviesa el firewall buscando los patrones que identifiquen el tráfico para el que se desea realizar ciertas funciones adicionales (en este caso, H.323). Yo recomiendo que se cree una «policy» especifica que se corresponda exclusivamente con el tráfico que controlamos mediante una ACL (el de nuestros equipos de videoconferencia), tanto en dirección saliente como entrante. Esto liberará la CPU del firewall para que podamos dedicarla a otros menesteres.

Por último, decir que también existe la misma función para el tráfico SIP (también ampliamente utilizado en sistemas de videoconferencia) en los firewalls Cisco ASA. Asimismo, otros fabricantes tienen sus propias inspecciones para facilitar el tráfico de videoconferencia: en los Fortigate no hay que hacer nada para que funcione (solo un VIP para el equipo de video y permitirle la salida con un NAT), en Watchguard hay que habilitar una regla de tipo H323_ALG (o SIP_ALG, lo que vayamos a usar) para los equipos de videoconferencia… por poner un par de ejemplos, todos los fabricantes de equipos «stateful» se han enfrentado a este problema y lo han solucionado de una u otra manera.

Un fuerte abrazo, compañeros (y un besi, claro),

tor

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Post Relacionados: