terça-feira, 7 de agosto de 2012

NAT Transversal ou Encapsulamento UDP

Fala Galera blz?

Estudando IPSec, para desempenhar minhas novas atividades, conheci uma forma de NAT em que a tradução do endereço IP não é realizada através das portas de comunicação, o NAT-T é uma técnica onde os dois equipamentos que estão configurados para se conectar utilizando IPSec verificam inicialmente se são compatíveis com a tecnologia, em seguida os dois equipamentos devem detectar se existe ou não a tradução de endereços e em que parte do caminho a tradução ocorre. Por fim, deve-se negociar os parâmetros do protocolo (portas utilizadas para encapsulamento, utilização de cookies, etc) e em seguida iniciar a transmissão de dados utilizando pacotes encapsulados.

Toda essa negociação e troca de cookies (arquivos de texto contendo informações sobre a transmissão) se deve porque o ESP (Encapsulating Security Payload) que é o protocolo responsável por transmitir o payload do pacote IPSec não utiliza o mesmo conceito de portas utilizado nos protocolos TCP e UDP e, portanto, não é possível fazer a tradução de endereço através do NAT Tradicional.
No NAT Transversal cada conexão é enviada com os respectivos dados de tradução (porta de origem: porta de destino) e a resposta só é enviada após a recepção da primeira conexão. Desta forma é configurado um novo NAT a cada conexão entre cliente e servidor IPSec. Neste conceito existem três tipos de NAT-T:
No Full Cone NAT também conhecido como NAT 1 para 1, nele  o cliente utiliza um endereço IP1:Porta1 para se comunicar com um servidor pelo IP2:porta2 sendo a resposta deste servidor enviada para a porta IP2:Porta2 e assim por diante, nesta forma de NAT o cliente pode contactar mais de um servidor em paralelo (1 para muitos).
No Restricted Cone NAT vemos que a comunicação se dá por duas portas mas apenas entre cliente e servidor (1 para 1). Caso um segundo servidor tentar responder o pacote será dropado pelo dispositivo que está fazendo o NAT-T.
No Port Restricted Cone NAT vemos que a restrição agora é por porta, onde apenas uma é utilizada para a comunicação entre cliente e servidor, no caso acima o servidor deve utilizar a porta que recebeu a comunicação para responder ao cliente e o Server 2 deve aguardar a conexão do cliente para então poder se comunicar.

Este terceiro caso é muito semelhante ao restricted cone, sendo a única diferença que o vinculo 1 para 1 é vinculado a porta, enquanto no restricted cone o vínculo é cliente servidor.

Além do ESP protocolos não vinculados a conexão como SIP e P2P também utilizam o NAT-T como uma forma de fazer NAT sem manter preso o número de porta a aplicação

A nível de sistemas operacionais, Windows a partir da versão 200 e XP (Artigo Microsoft Article ID: 818043) suportam nativamente o NAT-T para conexões VPN, como o applience que estou estudando também suporta nativamente este protocolo todos os sistemas Linux também suportam esta tecnologia.

O NAT-T está definido na RFC3947 que está na sessão de links abaixo.

Este conceito de NAT é muito semelhante ao modelo tradicional, eu compreendi claramente a diferença ao considera-lo orientado a pacotes, até por isso é chamado de encapsulamento UDP por alguns fabricantes.

Grande abraaaaço!

Fonte:
RFC 3947: http://www.ietf.org/rfc/rfc3947.txt
Artigo Microsoft ID818043: http://support.microsoft.com/kb/818043/en-us
Wikipedia EN: http://en.wikipedia.org/wiki/Network_address_translation
Wikipedia PT: http://pt.wikipedia.org/wiki/NAT_transversal
Materiais eLearning Sonicwall disponíveis em https://www.mysonicwall.com/Login.asp
(É necessário se registrar para ter acesso ao conteúdo).

Nenhum comentário: