Aspectos relativos à rede

Tradução do Endereço de Rede (NAT)

A videoconferência é normalmente reconhecida como um serviço difícil de negociar com a Tradução do Endereço de Rede (NAT) e os Firewalls. O padrão H.323 define um serviço que utiliza comunicação bi-direcional para configuração de chamadas com conexões caracterizadas pela utilização de portas dinâmicas e uma alta taxa de dados. Há tanto conexões paralelas UDP como TCP feitas nas portas dinamicamente negociadas. A situação é ainda mais complicada pela transmissão das informações dessa porta na seção de dados (payload) do stream de dados IP que faz essa negociação (RFC 2663). A dificuldade no desenvolvimento de aplicações de videoconferência é devido a complexidade do protocolo H.323, a sua dependência de alguns componentes utilizados (ex.: gatekeepers, MCUs, etc) e a variedade de implementações dos fornecedores.

A tecnologia dos firewalls foi desenvolvida para resolver importantes problemas de segurança, limitando o acesso a portas de redes internas pela filtração do tráfico de Internet que se dirige para dentro. O NAT fornece espaço de endereço de IP para rede interna quebrando uma única porta em múltiplas portas internas. Por causa do uso expandido de NAT e Firewalls, e por dar a característica dos sistemas de videoconferência, esses componentes particulares de rede e suas configurações tornaram-se um obstáculo para o desenvolvimento de sistemas de aplicação H.323. O NAT foi desenvolvido para permitir que múltiplos computadores dividam uma única conexão de IP. A tradução da Porta de Endereço de Rede (NAP) é a aplicação mais comumente usada. Ações seguras, como firewalls, são um produto derivado do método usado.

Como os requerimentos de videoconferência são incompatíveis com o NAT

Todas as aplicações TCP/IP dependem de roteadores de rede para controlar a direção dos pacotes de IP para garantir que cada pacote alcance o seu destino pretendido. Os roteadores que atuam na sua mais pura forma não são um problema para o tráfico H.323 em particular. O que freqüentemente causa problemas para o tráfico H.323 é um mecanismo para conservar espaço de endereçamento de IP chamado Tradução de Endereço de Rede ou NAT. O NAT efetua isso por compartilhar transparentemente um único endereço de IP com múltiplos hosts. Por traduzir o endereço de IP usado em uma rede privada para um endereço de IP adequado para a Internet pública, o roteador habilitado para NAT pode mapear endereços de IP privados e portas privadas para endereços de IP externos e portas externas e, então, suportar múltiplos endereços de IP privados.

O aspecto importante a lembrar da relação entre aplicações H.323 e o roteador de rede é que a aplicação está inconsciente de que o tráfico está rodando através de um aparelho NAT. Um outro problema existe porque o NAT normalmente estabelece o seu mapeamento de portas examinando o cabeçalho do pacote das aplicações. Enquanto isso funciona bem para a maioria das aplicações, o padrão H.323 requer endereço de IP e informação da porta a ser armazenada na porção de dados (payload) do pacote de IP.

Soluções para os problemas de videoconferência/NAT

A maioria das implementações NAT levam em consideração a configuração de algo chamado host DMZ ou, em outras palavras, passar todo tráfico que chega para um host interno em particular. Isso nem sempre acontece sem algumas modificações de pacotes que impediriam a comunicação H.323 e, certamente, introduziriam vulnerabilidades significantes na segurança de dentro de um sistema interno. Uma alternativa mais aceitável é uma aplicação que coloca gateway ou proxy que possa interpretar o tráfico de configuração da chamada e criar a configuração de porta requerida. A maioria dos clientes suportam proxies, mas requerem configuração de endereço.

O PhonePatch é um servidor proxy H.323 para Windows e Linux.

O Open H.323 Proxy é um solução de fonte aberta que utiliza as bibliotecas do Open H.323.

A comunidade do GnomeMeeting está promovendo uma alternativa para o NAT que permite que a sinalização de pacotes H.323 passe tranqüilamente (RFC 3103).