NAT – Network Address Translation

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!
24-05-2013
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
24-05-2013
ISEL/DEETC/SRT
3
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
24-05-2013
ISEL/DEETC/SRT
4
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
24-05-2013
ISEL/DEETC/SRT
5
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
24-05-2013
ISEL/DEETC/SRT
6
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
24-05-2013
ISEL/DEETC/SRT
7
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ósNAT não estar previamente definido, indo sendo dinamicamente alocado a partir
de um bloco (pool) de endereços
24-05-2013
ISEL/DEETC/SRT
8
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)
24-05-2013
ISEL/DEETC/SRT
9
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
24-05-2013
ISEL/DEETC/SRT
10
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
24-05-2013
192.0.0.1
192.0.0.1:80->193.137.221.128:1024
192.0.0.1:80->193.137.221.128:5001
193.0.0.1
193.0.0.1:80->193.137.221.128:1025
IP Ext: 193.137.221.128
NAT Box
192.168.0.1
192.168.0.1:1024->192.0.0.1:80
IP Int: 192.168.0.254/24
192.168.0.2
192.168.0.3
192.168.0.2:1024->192.0.0.1:80
192.168.0.2:1025->193.0.0.1:80
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
ISEL/DEETC/SRT
11
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
24-05-2013
ISEL/DEETC/SRT
12
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
24-05-2013
ISEL/DEETC/SRT
13
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
24-05-2013
ISEL/DEETC/SRT
14
Pseudoheaders TCP/UDP
Source Address (from IP Header)
Destination Address (from IP Header)
Reserved
0
•
Protocol (from IP TCP Segment Length (computed) or
UDP Length (from IP Header)
Header)
8
16
24
TCP/UDP Pseudoheader
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
24-05-2013
ISEL/DEETC/SRT
15
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
24-05-2013
ISEL/DEETC/SRT
16
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
24-05-2013
ISEL/DEETC/SRT
17
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)
24-05-2013
ISEL/DEETC/SRT
18
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
24-05-2013
ISEL/DEETC/SRT
19
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
24-05-2013
ISEL/DEETC/SRT
20
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.
24-05-2013
ISEL/DEETC/SRT
21
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.
24-05-2013
ISEL/DEETC/SRT
22
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.
24-05-2013
ISEL/DEETC/SRT
23
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
24-05-2013
ISEL/DEETC/SRT
24
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)
24-05-2013
ISEL/DEETC/SRT
25
Algoritmo STUN
24-05-2013
ISEL/DEETC/SRT
26
Relação entre protocolos comuns e NAT
•
•
•
•
•
•
•
•
•
•
•
•
•
Telnet
SSH
HTTP
SMTP
POP
DNS
SNMP
FTP
MSN Messenger
VoIP/SIP
IPSEC
eDonkey2000
BitTorrent
24-05-2013
ISEL/DEETC/SRT
27
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
24-05-2013
ISEL/DEETC/SRT
28
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
24-05-2013
ISEL/DEETC/SRT
29
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
24-05-2013
ISEL/DEETC/SRT
30
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
24-05-2013
ISEL/DEETC/SRT
31
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.
24-05-2013
ISEL/DEETC/SRT
32
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.
24-05-2013
ISEL/DEETC/SRT
33
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!
24-05-2013
ISEL/DEETC/SRT
34
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/transcoders
designados 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
24-05-2013
ISEL/DEETC/SRT
35
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
24-05-2013
ISEL/DEETC/SRT
36
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
24-05-2013
ISEL/DEETC/SRT
37
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
24-05-2013
ISEL/DEETC/SRT
38
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
24-05-2013
ISEL/DEETC/SRT
39
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
24-05-2013
ISEL/DEETC/SRT
40
Referências
•
Operating Principles and General Behavioral Requirements for Network Address Translators (BEH-GEN)
•
•
Cisco - NAT Frequently Asked Questions, Document ID: 26704
NAT Classification Test Results
•
RFC2428 - FTP Extensions for IPv6 and NATs
B. Ford - M.I.T., P. Srisuresh - Caymas Systems, S. Sivakumar - Cisco Systems - May 2005
C. Jennings - Cisco Systems - July 16, 2005
M. 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.faqs.org/rfcs/rfc2663.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
24-05-2013
ISEL/DEETC/SRT
41