03 - natv0.8

NAT – Network Address Translation

O que é o NAT

• Técnica que altera, em trânsito os endereços do cabeçalho dos

datagramas IP

– De forma a que a origem sob o ponto de vista do destinatário não seja a real

– De forma a que o destino final seja uma máquina com endereço diferente do

originalmente indicado pelo remetente

• Viola uma regra fundamental assumida na criação do TCP/IP daí criar

complicações!

07-04-2011 ISEL/DEETC/SRT 2

Termos usados

• NATBox – Router com funcionalidades de NAT

• Inbound – Sentido do tráfego da Internet para rede atrás da NATBox

• Outbound – Sentido do tráfego da rede atrás da NATBox para a

Internet

• Endereço pré-NAT – Endereço antes de sofrer a conversão imposta

pelo processo de NAT

• Endereço pós-NAT – Endereço resultante da aplicação do processo de

NAT


Porquê NAT

• Motivação principal

– Escassez de endereços devido ao desperdício de endereços na

atribuição clássica por classes a cada entidade e do consumo

desproporcional praticado por muitas entidades

– A limitação de os ISPs fornecerem aos clientes residenciais apenas um endereço

IP por ligação e os clientes terem hoje em dia muitos equipamentos com

necessidade de conectividade

• Múltiplos PCs/MACs, PDAs, Playstations, MediaCenters, telefones IP, etc


Outras aplicações de NAT

• Na distribuição de serviço por diversas máquinas, em processos de balanceamento de carga (SLB)– Escalabilidade e disponibilidade

• Na compatibilização de redes que necessitem de se juntar apesar de terem planos de endereçamento sobrepostos– Double NAT

• Permitir o acesso público a serviços disponibilizados por máquinas com endereçamento privado– Mapeamentos estáticos de NAT


Variantes de NAT – IP estático

• Estático ao nível do IP

– Estáticamente é definido um mapeamento entre o endereço IP original (origem ou

destino) e o final

• Quando o tráfego atravessa a NATbox num sentido, o endereço original é substituído

pelo final, no sentido contrário é realizada a substituição inversa


Variantes de NAT – TCP/UDP estático

• Estático ao nível da camada de transporte– Estaticamente é definido um mapeamento entre o par formado pelo endereço IP

original e porto original e o IP/porto final (pós NAT)

• Quando o tráfego atravessa a NATBox num sentido, se o protocolo nível 4, o endereço IP e porto destino são os do mapeamento definido, o endereço e porto destino são substituídos pelos indicados no mapeamento. No sentido contrário é realizada a substituição inversa, aplicada agora ao endereço origem


Variantes de NAT – IP dinâmico

• Dinâmico ao nível do IP

– Processo idêntico ao da vertente estática, com a diferença de o endereço pós-

NAT não estar previamente definido, indo sendo dinamicamente alocado a partir

de um bloco (pool) de endereços


Variantes de NAT – TCP/UDP dinâmico

• Dinâmico ao nível da camada de transporte

– Processo idêntico ao da vertente estática, com o endereço pós- NAT a ser ou não

alocado a partir de um bloco, podendo agora o porto não condicionado pelo

mapeamento ser também potencialmente alterado para um valor diferente do

original (o sistema escolhe)


Necessidade de manter contexto

• Dependente da variante de NAT usada e da implementação particular

de NAT, diferentes níveis de contexto são necessários para fazer a

associação do tráfego de retorno ao original

– Variantes estáticas, dispensam a manutenção de contexto


Um só endereço representando muitos, como?

• A vertente mais comum de

NAT é usada na partilha de

um único endereço IP

exterior por múltiplas

máquinas, cada uma com o

seu endereço individual

interno

– A informação necessária

para realizar o mapeamento

do tráfego de volta (inbound)

é mantida no porto origem

pós-NAT que se tem de

manter único

NAT Box

IP Ext: 193.137.221.128

IP Int: 192.168.0.254/24

192.0.0.1

192.168.0.3192.168.0.1 192.168.0.2

193.0.0.1

192.168.0.1:1024->192.0.0.1:80 192.168.0.2:1024->192.0.0.1:80 192.168.0.2:1025->193.0.0.1:80

193.0.0.1:80->193.137.221.128:1025

192.0.0.1:80->193.137.221.128:1024

192.0.0.1:80->193.137.221.128:5001

NAT Translations

Proto InsideIP:Port -> OutsideIP:Port => LocalPubIP:Port -> OutsideIP:Port Expires

TCP 192.168.0.1:1024->192.0.0.1:80 => 193.137.221.128:1024->192.0.0.1:80 00:01:10

TCP 192.168.0.2:1024->192.0.0.1:80 => 193.137.221.128:5001->192.0.0.1:80 00:01:20

TCP 192.168.0.3:1025->193.0.0.1:80 => 193.137.221.128:1025->193.0.0.1:80 00:01:25


Porquê usar endereços privados atrás de NAT?

• Se se usar uns quaisquer, pode acontecer ter-se necessidade de

comunicar com a rede que os usa legalmente e não se consegue,

porque todas as máquinas da nossa rede assumem que conseguem

falar directamente com as máquinas da “sua” rede.

• Usar os blocos de endereços Private Networks (RFC1918) para

endereçar as redes internas

– 10.0.0.0/8 – 1 Classe A

– 172.16.0.0/12 – 16 Classes B

– 192.168.0.0/16 – 256 Classes C


O custo da transparência do NAT

• Recalculo de checksums

• Alteração de campos dos cabeçalhos

• Ajuste das mensagens de erro ICMP

• Manutenção de tabelas de mapeamento estáticas e dinâmicas


Implementação de NAT

• Campos dos cabeçalhos a alterar

– Time To Live e Checksum – Já anteriormente eram ajustados como parte do

processo de encaminhamento

– Endereços Origem e/ou Destino – Segundo a aplicação de NAT pretendida

– Portos Origem e/ou Destino – Dependendo da aplicação pretendida e da

própria gestão do sistema

• Manter quando possível, alterar para outro dentro da mesma gama quando

necessário (gamas no NAT Cisco IOS: 0-511, 512-1023 e 1024-65535)

– Checksum TCP/UDP – Sempre necessário devido à dependência deste dos

endereços origem/destino provocada pelo uso de pseudoheaders no cálculo


Pseudoheaders TCP/UDP

• O recalculo do checksum é realizado sobre o cabeçalho TCP/UDP, o pseudoheader respectivo e sobre os dados transportados

– Impensável para volumes de tráfego elevados pela computação necessária e atraso provocado

ReservedProtocol (from IP

Header)

0 8 16 24

Source Address (from IP Header)

Destination Address (from IP Header)

TCP Segment Length (computed) or

UDP Length (from IP Header)

TCP/UDP Pseudoheader


Transparência das mensagens de erro ICMP

• As mensagens de erro ICMP (unrechables, TTL expired, etc.) são recebidas pela NATBox dirigidas ao endereço pós-NAT e contendo a amostra do cabeçalho IP + 8 Bytes do datagrama IP que a provocou

– Há que fazer a associação desta à tabela de mapeamento NAT para saber para que endereço destino há-de ser alterada

• Usando os endereços da amostra do cabeçalho original e os portos TCP/UDP ou algo que forneça contexto do protocolo em questão (ex. ICMP identifier/seq.number), contidos nos 8 bytes adicionais

– Há que alterar a amostra da mensagem de erro, incluindo endereços, portos e checksums para que se mantenha a total transparência


Impacto do NAT no funcionamento das aplicações

• Aplicações que envolvem múltiplas ligações com parâmetros negociados no próprio protocolo não são suportadas sobre NAT directamente– As aplicações enviam os parâmetros sob o seu ponto de vista

• FTP – No comando PORT indica ao servidor externo o seu IP “pré-NAT” com o qual ele não tem conectividade

• Comunicações entre clientes que partilham, a algum nível dentro do domínio privado da rede, um equipamento realizando NAT– Algumas aplicações resolvem o problema usando um serviço de relay exterior

para resolverem o problema – Com sérios problemas de escalabilidade (ex. MSN Messenger)

• O funcionamento em válvula do NAT impossibilita em muitos casos as comunicações entre clientes atrás de NAT– X e Y podem fazer ligações para fora das suas redes (distintas), mas não se

conseguem ligar entre si


Soluções para os problemas levantados pelo NAT

• Duas técnicas seguidas para se atingir a total transparência das aplicações numa das situações anteriores– A “NAT Box” intercepta e manipula o protocolo em questão durante o processo

de NAT (tipicamente designado de fixup ou mangling)

• Não é universal, só funciona para os protocolos que a “NAT Box” saiba manipular

• Implica mais processamento, envolvendo em alguns casos a gestão adicional dos números de sequência TCP por o processo envolver o encurtar/alongar de segmentos

• Interpretando o protocolo, são automaticamente inseridas as entradas na tabela de mapeamento NAT para se aceitarem as novas ligações negociadas

– As aplicações usam técnicas/protocolos adicionais para se aperceberem da existência de NAT pelo meio, da forma como este está a ser realizado, de como as suas ligações são vistas do exterior e manipula na origem os parâmetros

• Não resolve o problema da abertura dos mapeamentos NAT para as ligações adicionais

• Mapeamento para aceitar ligações inbound conseguido à custa de datagramas sem conteúdo (keepalives) enviados de dentro (comum para UDP/VoIP)


STUN – Simple Transversal of UDP over NAT

• Protocolo usado para identificar a existência de NAT e o modo de

funcionamento deste no percurso entre a máquina onde é executado o

teste e determinado servidor STUN

• Definido no RFC3489

• Protocolo muito usado como auxiliar do VoIP/SIP

– Para experiências usar o WinSTUN


Classificação de tipos de NAT para UDP (STUN)

• Dependendo de que parâmetros são usados na NATBox para criar o contexto das ligações, validar e associar o tráfego inbound ao outbound, este terá algumas diferenças de comportamento com significado, especialmente na recepção de pacotes do exterior– Identificador completo

• origin session, origin side, target session, target side

– origin session – parâmetros do lado em que a ligação foi iniciada

• source IP, source port, dest IP, dest port

– target session – parâmetros vistos na interface de saída (pós-NAT)

• source IP, source port, dest IP, dest port

– Terminologia comum

• Symmetric, Port Restricted Cone, Address Restricted Cone, Full Cone


Tipos de NAT para UDP - Full Cone NAT

• Todos os pedidos do mesmo endereço e porto internos são mapeados

no mesmo endereço e porto externos.

• Uma máquina externa pode enviar pacotes para uma interna,

enviando-os para o endereço e porto externos mapeados.


Tipos de NAT para UDP - Address Restricted Cone NAT

• Todos os pedidos do mesmo endereço e porto internos são mapeados

no mesmo endereço e porto externos.

• Ao contrário do Full Cone NAT, uma máquina externa só pode enviar

pacotes até uma interna se foi anteriormente o destino de pacotes

enviados esta.


Tipos de NAT para UDP - Port Restricted Cone NAT

• Parecido ao Address Restricted Cone NAT, mas a restrição inclui agora

também o porto.

• Uma máquina externa só pode enviar pacotes até uma interna se foi

anteriormente o destino dum pacote enviado por esta com o porto

origem usado agora como destino.


Tipos de NAT para UDP - Symmetric NAT

• Pedidos do mesmo endereço e porto internos para determinado

destino são mapeados num único IP e porto externos. Se a mesma

máquina interna enviar um pacote com o mesmo endereço e porto para

um destino diferente é usado um novo (diferente) mapeamento.

• Só as máquinas exteriores que recebem pacotes das internas

conseguem enviar pacotes de volta á máquina interna


Hairpin

• É definida como uma sessão de NAT com necessidades de Hairpin

toda aquela que envolve dois equipamentos que partilham a algum

nível um equipamento realizando NAT

– Se não for suportada esta técnica, não é possível a comunicação directa entre

equipamentos nesta situação

– A “NAT Box” tem de identificar a situação e realizar virtualmente o duplo processo

NAT envolvido, como se se tratasse de dois equipamentos isolados realizando

NAT

– Situação comum quando são encadeados múltiplos equipamentos realizando

NAT dentro do domínio privado da rede e se recorre a servidores externos para

rendez-vous (ex: Messengers, P2P, STUN/VoIP)


Algoritmo STUN


Relação entre protocolos comuns e NAT

• Telnet

• SSH

• HTTP

• SMTP

• POP

• DNS

• SNMP

• FTP

• MSN Messenger

• VoIP/SIP

• IPSEC

• eDonkey2000

• BitTorrent


NAT vs Telnet, SSH, HTTP, SMTP ou POP

• Todos estes protocolos são baseados em transporte TCP

sendo suportados por uma única ligação originada do cliente

para o servidor

• Não têm qualquer problema no funcionamento sobre NAT


NAT vs DNS

• Sem problemas de maior

• Tende a criar muitas entradas de contexto

– Ajustar expiração para tempos razoáveis (5s a 10s ?)

• Em ambientes com servidores acessíveis através de IPs

internos e externos, via mapeamento estáticos

– Necessário o uso de “split views” ou de modulo “helper” que ajuste

os endereços dados aos clientes exterior

• Quando perguntam ao DNS por XPTO.DOMINIO.PT (tipo “A”), os clientes

internos obtêm o IP interno, os externos obtêm o Pós-NAT seja a diferença

feita pelo servidor DNS ou por alteração do conteúdo das mensagens DNS

na NATBox


NAT vs SNMP

• O SNMP funciona tipicamente sobre UDP com sequências de pedidos/respostas

• Pormenores a ter em conta para a coexistência com NAT– Não existindo ligação (UDP) o contexto do pacote enviado é mantido durante

determinado tempo na tabela de NAT até expirar

• Ajustar para um valor consistente com os tempos espectáveis entre pedidos e respostas e pedidos seguintes para evitar rejeições indesejadas de respostas e o enchimento da tabela de mapeamento

– Para aceitar TRAPs (alarmes assíncronos do agente) há que criar um mapeamento estático aceitando o tráfego de volta para o gestor, sendo assim, na maioria dos casos incompatível esta componente com o uso de múltiplos gestores

– Como os pedidos chegarão aos agentes com o endereço origem pós-NAT, estes terão de ter incluído este endereço na lista de gestores autorizados, com o aspecto negativo adicional de esta permissão ser partilhada com todas as máquinas que reutilizem o endereço pós-NAT


NAT vs FTP

• FTP modo Activo só suportado com o uso de um módulo especializado (fixup) na NATBox para alterar o endereço e porto enviados no comando PORT, abrindo em simultâneo o canal/mapeamento para a ligação de dados iniciada pelo servidor

• FTP modo Passivo mais fácil de suportar, não necessita de fixup na NATBox porque ambas as ligações (controlo e dados) são iniciadas pelo cliente– Se o fixup for dispensado, para funcionar tem de se aceitar ligações

outbound de e para qualquer porto TCP acima de 1024 (inclusive) o que pode implicar abrir acesso a muitas outras aplicações indesejadas

– Complica-se quando é o servidor que está atrás de NAT


FTP modo Activo

USER anonymous

331 Guest login ok, send your e-mail address as password.

PASS NcFTP@

230 Logged in anonymously.

PORT 192,168,1,2,7,138 <= Ou o NAT sabe ajustar esta// mensagem e abrir o canal de volta ou não há ligação

// O cliente pretende que o servidor se ligue ao seu porto// 1930 (7*256+138), e endereço 192.168.1.2

200 PORT command successful.

LIST

150 Opening ASCII mode data connection for /bin/ls.

// O servidor já fez a ligação

226 Listing completed.

QUIT

221 Goodbye.


FTP modo Passivo

USER anonymous

331 Guest login ok, send your e-mail address as password.

PASS NcFTP@

230 Logged in anonymously.

PASV

// O cliente diz que quer usar modo passivo e pergunta// para onde deve ligar

227 Entering Passive Mode (192,0,1,4,204,173)

// O servidor envia os dados.

// Se o servidor está atrás de NAT também são válidos!

LIST

150 Data connection accepted from 192.0.1.4:52397

// O cliente já se ligou ao endereço e porto (52397)

// indicados pelo servidor

226 Listing completed.

QUIT

221 Goodbye.


NAT vs MSN Messenger

• Para a vertente Chat não costumam existir problemas, o cliente inicia uma única ligação para um dos servidores centrais do sistema

• Usa um protocolo semelhante a STUN (acessível em Tools->Options->Connection) para perceber que restrições tem cada utilizador (NAT e/ou firewalls)

• O Chat utiliza sempre o servidor como relay

• Para a transferência de ficheiros e sessões multimédia usa comunicações directas entre clientes, se não é possível usa o servidor como relay– Utilizadores na mesma rede atrás de NAT nem sempre transferem entre si os

ficheiros usando o percurso mais eficiente!


NAT vs VoIP/SIP (Session Initiation Protocol)

• Por motivos de escalabilidade e qualidade do serviço o VoIP/SIP foi desenhado com uma estrutura peer-to-peer


– A sinalização é agregada em softswitchs

– Os fluxos multimédia podem ser agregados em relays/transcodersdesignados de mediaproxys ou serem directos entre clientes

• O facto do protocolo correr na maioria dos casos sobre UDP facilita o atravessamento de NAT

• Para coexistência pacifica os clientes usam STUN para detectar se têm e que forma têm de NAT entre eles e o servidor de referência

NAT vs VoIP/SIP (Session Initiation Protocol)

• Os clientes usam no corpo das mensagens de sinalização (SIP) os parâmetros pós-NAT para serem contactáveis do exterior

• Após registo dos clientes (terminal VoIP), estes e o softswitch enviam periodicamente mensagens de keepalive para criar e manter os mapeamentos nas NATBox

• Dado o número de factores envolvidos no processo, ocorrem frequentemente incompatibilidades que são na maioria dos casos solucionáveis com o ajuste de parâmetros

• É possível a coexistência com todas as formas de NAT identificadas pelo STUN excepto Symmetric NAT devido à dispersão de endereços e portos realizada por esta técnica

• Para que seja possível o fluxo directo do tráfego multimédia entre terminais atrás de uma NATBox comum é normalmente necessário o suporte de hairipin na NATBox


NAT vs IPsec

• Pouco compatíveis devido a dependências diversas– As NATBox não conseguem actualizar os checksums do UDP/TCP

• Estão cifrados dentro do envelope ESP (modo transporte)

– Não se conseguem multiplexar fluxos de dados IPsec, não existem cabeçalhos visíveis

• SPI e o endereço destino não servem pois o contexto é simplex (são usados diferentes SPI em cada um dos sentidos). SPI não pode ser alterado em caso de colisão de valores pois está protegido pelo HMAC à cauda do pacote

– O porto de IKE (500) usado por algumas implementações não pode ser alterado• Algumas implementações descartam estas mensagens se o porto origem não for o

standard

– Os mapeamentos de NAT do IKE/UDP expiram• As mensagens de IKE não são frequentes e após o mapeamento expirar deixa-se de

se conseguir receber mensagens

– As mensagens IKE contêm endereços internamente• Ao sofrer NAT o endereço do cabeçalho IP fica inconsistente com o do corpo da

mensagem sendo rejeitada e abortada a negociação


NAT vs IPsec

• Recentemente definido um modo (NAT-T)

– Transporta o ESP sobre UDP

– Flexibiliza regras (ex. portos válidos)

– Cabeçalho IKE modificado para evitar incompatibilidade

– O protocolo inclui a detecção de NAT no percurso para coexistência

– Menos eficiente já que o overhead cresce substancialmente

– O modo tunnel foi adaptado para ser possível a multiplexagem de

diversas ligações sobre NAT


NAT vs eDonkey2000

• Liga-se a um servidor de rendez-vous por TCP ou UDP

• Por questões de fairness, o sistema limita em muito as funcionalidades

disponibilizadas a clientes aos quais não consegue ligar de volta (para

o porto indicado pelo cliente) - (LowID!)

– Tenta promover a simetria produtor/consumidor em cada utilizador para evitar o

desequilíbrio que limita a escalabilidade do protocolo

– Necessário fixup na NATBox (não há pressão dos grandes compradores de

equipamentos para que seja suportado!) para abertura automática do porto para

recepção das ligações dos outros clientes

• Usar mapeamento estático de portos para encaminhar os pedidos para

a máquina interna

– Para suporte de múltiplos clientes internos há que

usar um porto diferente de entrada para cada com

os respectivos mapeamentos estáticos de NAT


NAT vs BitTorrent

• Idêntico ao anterior com a diferença de se complicar o

mapeamento de portos pois utiliza uma gama deles (default

6881-6889) por aplicação/máquina.


Ilustração das ligações TCP possíveis quando existe NAT (caixa azul) do lado dos clientes. As

ligações a vermelho não conseguem estabelecer-se, as a verde conseguem

Situações sem e com mapeamento estático de portos no sentido inbound

Referências

• Operating Principles and General Behavioral Requirements for Network Address Translators (BEH-GEN)B. Ford - M.I.T., P. Srisuresh - Caymas Systems, S. Sivakumar - Cisco Systems - May 2005

• Cisco - NAT Frequently Asked Questions, Document ID: 26704

• NAT Classification Test ResultsC. Jennings - Cisco Systems - July 16, 2005

• RFC2428 - FTP Extensions for IPv6 and NATsM. Allman - NASA Lewis/Sterling Software, S. Ostermann - Ohio University, C. Metz - The Inner Net, September 1998

http://www.faqs.org/rfcs/rfc1631.html


http://www.ietf.org/rfc/rfc2993.txt

http://www.networksorcery.com/enp/rfc/rfc3489.txt

http://www.networksorcery.com/enp/protocol/stun.htm

http://www.cisco.com/warp/public/556/5.html

http://www.cisco.com/en/US/tech/tk648/tk361/tk438/tsd_technology_support_sub-protocol_home.html

http://en.wikipedia.org/wiki/Network_address_translation

http://en.wikipedia.org/wiki/STUN

http://tools.ietf.org/html/rfc3489

http://slacksite.com/other/ftp.html

http://www.ncftp.com/ncftpd/doc/misc/ftp_and_firewalls.html

http://www.microsoft.com/technet/community/columns/cableguy/cg0802.mspx

http://www.kazaa.com/us/help/glossary/p2p.htm

http://userpages.umbc.edu/~hamilton/btclientconfig.html

http://www.voip-info.org/wiki/view/NAT+and+VOIP

http://www.voip-info.org/wiki-Asterisk+SIP+NAT+solutions

http://www.snom.com/whitepapers/FAQ-03-10-20-cs.pdf


http://www.ietf.org/internet-drafts/draft-ford-behave-gen-01.txt



http://www.cisco.com/warp/public/556/nat-faq.html




http://tools.ietf.org/html/draft-jennings-behave-test-results-01

http://www.apps.ietf.org/rfc/rfc2428.html






http://www.ietf.org/rfc/rfc2993.txt

http://www.networksorcery.com/enp/rfc/rfc3489.txt

http://www.networksorcery.com/enp/protocol/stun.htm

http://www.cisco.com/warp/public/556/5.html




http://en.wikipedia.org/wiki/Network_address_translation

http://en.wikipedia.org/wiki/STUN

http://tools.ietf.org/html/rfc3489

http://slacksite.com/other/ftp.html

http://www.ncftp.com/ncftpd/doc/misc/ftp_and_firewalls.html

http://www.microsoft.com/technet/community/columns/cableguy/cg0802.mspx

http://www.kazaa.com/us/help/glossary/p2p.htm

http://userpages.umbc.edu/~hamilton/btclientconfig.html


















03 - natv0.8

Documents