Um dos problemas do uso de NATs é o tratamento de conexões iniciadas por um host que está fora da NAT. Utilizando como exemplo a imagem do início deste capítulo, onde temos o host A em uma rede privada com NAT e o host B conectado diretamente à rede pública, o problema acontece quando a conexão inicial parte do host B. O host B tentará contatar o host A utilizando o IP 139.130.1.1. Através deste IP os pacotes chegarão até o roteador com a NAT, porém ele não saberá para qual host da rede interna estes pacotes devem ser redire- cionados. Se a conexão parte do host A, entretanto, não há problemas, pois a NAT cria sua tabela e consegue tratar todos os pacotes posteriores.
Domínio de
endereço privado Internet pública
10.0.0.1
Host A
192.9.200.1
Host B
Origem: 10.0.0.1/2000
Destino: 192.9.200.1/80 Origem: Destino: 192.9.200.1/80139.130.1.1/3000
Origem: 192.9.200.1
Destino: 10.0.0.1/2000 Origem: 192.9.200.1/80Destino: 139.130.1.1/3000
Site NAT
NAT Binding
10.0.0.1/2000 139.130.1.1/3000
E como ficaria a situação se os dois hosts estão atrás de uma NAT? Neste caso nenhum dos dois pode iniciar a comunicação. As soluções serão tratadas na sequência deste capítulo. Outro problema no uso de NATs é que elas estabelecem o mapeamento de portas exami- nando o cabeçalho dos pacotes que são transmitidos. Isso funciona bem para a maioria das aplicações, porém apresenta problemas com protocolos que utilizam portas dinâmicas e/ou incluem a informação da porta utilizada na área de dados do pacote (payload). E este é jus- tamente o caso dos padrões de videoconferência H.323 e SIP, onde as conexões RTP utilizam portas dinâmicas, que são definidas pelos protocolos durante o estabelecimento da sessão, onde são trocadas mensagens que contém o valor da porta na área de dados da mensagem. Figura 5.19
NAT do tipo Port
Restricted Cone.
Figura 5.20 Pacotes através
Ad m in is tr aç ão d e V id eo co nf er ênci a
O exemplo abaixo mostra uma mensagem INVITE do SIP, que contém dados tanto das portas utilizadas quanto dos IPs na área de dados da mensagem. Em uma mensagem como essa, a NAT conseguiria apenas modificar IP e porta do cabeçalho, mas todos os valores de IP e porta exibidos no exemplo permaneceriam iguais.
INVITE sip:206@192.168.0.30:10455 SIP/2.0
Via: SIP/2.0/UDP 192.168.0.24:5060;branch=z9hg4bkz9hg4bkf8e2c7ca Via: SIP/2.0/UDP 192.168.0.24:5060 From: <sip215@192.168.0.154;tag=414d5646-ad-407469a8 To: <sip:206@192.168.0.154> Contact: sip:215@192.168.0.24
Soluções
q
Alternativas para a solução do problema: 1 Protocolo H.460
2 Criado para firewall / NAT traversal com o padrão H.323. 2 Utiliza um servidor que age como um proxy.
1 STUN (Session Traversal Utilities for NAT)
2 Servidor externo auxilia descoberta de IP público. 2 Não pode ser utilizado com NAT simétrica. 1 TURN (Traversal Using Relays around NAT)
2 Utiliza um servidor que age como um proxy. 1 ICE (Interactive Connectivity Establishment)
2 STUN + TURN.
A seguir estão descritas as principais formas para permitir que videoconferências atra- vessem firewalls e NATs: H.460, STUN, TURN e ICE.
Protocolo H.460
O H.460 é uma série de extensões ao padrão H.323 estabelecida pela ITU para possibilitar que videoconferências H.323 “atravessem” firewalls e NATs. A implementação do H.460 inclui um servidor localizado na rede pública (fora da NAT/firewall) que age como um proxy para todo o tráfego da videoconferência. Os terminais se registram neste servidor e abrem canais de comunicação direta com o servidor. Ou seja, os terminais não se comunicam dire- tamente, mas através do servidor H.460.
A grande vantagem desta abordagem é que não é necessário criar regras especiais nos firewalls e também não é necessário que o firewall entenda o protocolo H.323. Basta configurar o firewall para que ele permita a comunicação com o servidor H.460 (um servidor confiável).
Este método é simples de ser implementado e utilizado, o que o torna bastante prático para ambientes com poucos terminais e videoconferências rápidas. Ele se torna uma solução pro- blemática especialmente quando existe um grande número de terminais fazendo ligações ao mesmo tempo (a largura de banda do servidor pode não ser suficiente).
Ca pí tu lo 5 - R ed es d e c om pu ta do re s e v id eo co nf er ên ci a
STUN
Session Traversal Utilities for NAT (STUN) é um mecanismo definido na RFC 5389 que permite que entidades atrás de NATs descubram seus endereços públicos e com isso viabiliza video- conferências entre elas. Seu funcionamento é baseado em um modelo cliente-servidor, onde o cliente (um terminal de videoconferência) troca mensagens com um servidor (localizado na rede pública) para descobrir informações como:
1 Seu IP público;
1 O tipo de NAT na qual o cliente se encontra;
1 O mapeamento que o NAT está utilizando para este cliente.
Além disso, o protocolo também possibilita outras facilidades, como manter o mapeamento do NAT sempre ativo, para que não ocorram falhas na comunicação.
O STUN foi inicialmente definido na RFC 3489, e costuma ser chamado de “classic STUN”. Esta versão do protocolo provê todas as funcionalidades mencionadas, e pode ser utilizado de forma independente de outros protocolos. Porém, foi descoberto que esta versão do protocolo não é adequada em muitos casos, pois há casos em que a solução funciona e há casos em que não funciona. E nos casos em que não funciona não há nada que possa ser feito. Em função desse e de outros problemas, o STUN foi novamente especificado na RFC 5389, onde passou a ser apenas uma ferramenta utilizada como parte de uma solução de NAT traversal completa (como o ICE, que será descrito na sequência).
O principal problema do STUN é que não funciona com NAT simétrica, que é um tipo de NAT muito utilizado. O problema é que a associação feita no NAT entre um terminal e o servidor STUN não pode ser utilizada para conexão entre este terminal e outro, ou seja, não pode ser utilizada para a videoconferência. Isso ocorre porque o NAT simétrico cria diferentes associações para cada conexão, mesmo para duas conexões feitas com um só terminal (que está atrás da NAT).
Por exemplo, as soluções que utilizam um servidor externo apenas para tarefas como des- coberta do IP público (ex. STUN): dessa forma, o terminal 1 descobre o IP externo e interno do terminal 2 e os utiliza adequadamente.
Dados multimídia Servidor da rede pública NAT / Firewall Rede interna NAT / Firewall Rede interna No site “No Jitter”,
assista ao “Video Tunnels Through the Firewall”.
v
Figura 5.21 Solução com servidor externo.
Ad m in is tr aç ão d e V id eo co nf er ênci a
TURN
Traversal Using Relays around NAT (TURN) é uma extensão do protocolo STUN, incluindo as mensagens TURN, que são em grande parte mensagens no formato STUN. Este protocolo é definido na RFC 5766.
Assim como no STUN, o TURN utiliza um servidor em uma área pública para permitir que os clientes façam conexões através de NATs. O TURN permite que um host atrás de um NAT (o cliente) solicite que outro host (o servidor) funcione como um servidor de relay, de redirecionamento de mensagens. O cliente pode então utilizar o servidor para redirecionar pacotes para outros clientes e controlar como este redirecionamento é feito. Com o uso deste servidor, mensagens podem ser trocadas bidirecionalmente entre dois clientes. A desvantagem do uso do TURN é que o uso de um servidor de redirecionamento pode gerar problemas de atraso, jitter e outros problemas de rede e também necessita que o servidor tenha uma grande largura de banda disponível.
ICE
Interactive Connectivity Establishment (ICE) é especificado na RFC 5245 e define uma técnica de NAT traversal para transmissões UDP estabelecidas em um modelo de oferta e resposta. O modelo oferta e resposta é feito basicamente com o uso do protocolo SDP, onde são inseridos diversos IPs e portas, que são encaminhados para um cliente testar se é possível estabelecer uma conexão com eles. Esses IPs são definidos com uso do STUN. Além disso, o ICE também utiliza o TURN quando necessário.
Simplificadamente, o ICE é uma solução completa de NAT traversal que utiliza o STUN sempre que possível e o TURN quando necessário (quando não é possível estabelecer uma conexão direta entre os dois hosts e então é necessário um servidor de relay). O ICE ainda não está maduro, e não é adotado largamente na indústria, criando um problema no seu uso.