1 – Introdução
Quando falamos de NAT logo nos vem em mente à necessidade de traduzirmos o ip de origem, que normalmente é um ip de rede privado, para um ip válido a fim de podermos acessar a Internet à partir da nossa rede interna. Já a tradução do ip de destino não é uma necessidade tão comum assim. Neste post mostraremos como configurá-lo facilmente, em roteadores Cisco.
2 – Necessidade Real
Um cliente teve a necessidade de alterar os ips da LAN da Matriz e em consequência, de todos os seus servidores. Os aplicativos das filiais foram facilmente reconfigurados já que o cliente tem gerência sobre suas máquinas. Um equipamento proprietário (ponto eletrônico biométrico) é gerenciado por uma empresa terceirizada que, por algum motivo, não pode fazer as alterações solicitadas pelo cliente no prazo desejado. Fomos consultados para realizarmos a tradução do ip de destino antigo (192.168.1.100) pelo atual (10.1.1.100), no CPE da Matriz até que o problema fosse resolvido definitivamente. Os ips de LAN das filiais não sofreram alterações.
3 - Cenário (resumido) do problema:
 |
| Figura - 1 |
A rede real do cliente é uma MPLS, mas a tradução do ip independe dela ser MPLS ou não. O nosso exemplo não é. Ela roda BGP entre o CPE e o PE e a rota defaul da matriz é anunciada, através do BGP, a todas as filiais. Sendo assim não é necessário criar rota estática para anunciar o ip 192.168.1.100 já que ele chega até o Server por rota default.
Antes de iniciarmos o Lab vamos entender como funciona NAT Rotary, pois ele é a base para a realização da tradução do ip de destino que adotamos.
4 - Distribuição de Carga usando NAT Rotary
Veja como funciona:
 |
| Figura - 2 |
Uma organização pode ter mais de um servidor que serve a vários hosts. Usando NAT Rotary, um servidor virtual (192.168.1.100) é estabelecido na rede dentro da qual se comunica com servidores reais (10.1.1.100,101). Endereços de destino que correspondem a uma 'access-list' permitem que o endereço IP do servidor virtual (192.168.1.100) seja substituído por endereços de um 'pool' (10.1.1.100...) rotativo (Rotary). A alocação é feita com base em round-robin.
O roteador executa as seguintes etapas ao traduzir endereços através de NAT Rotary:
- Um host abre uma conexão TCP com servidor virtual 192.168.1.100.
- O roteador recebe o pedido de conexão e cria uma tradução, alocando o próximo endereço IP do servidor.
- O roteador substitui o IP de destino pelo IP real (10.1.1.100...) selecionado e encaminha o pacote.
- O servidor recebe o pacote e responde.
- O roteador recebe a resposta e executa a pesquisa na tabela NAT. O roteador então traduz o IP de origem para o IP do servidor virtual e encaminha o pacote.
4.1 – Configurando Distribuição de Carga:
A forma dos comandos é a seguinte:
ip nat pool name start-ip end-ip {netmask netmask | prefix-length prefix-length} type rotary
ip nat inside destination list access-list-number pool name
Onde:
name: é o nome do pool.
start-ip e end-ip: são os ips reais dos servidores onde ocorre a distribuição de carga.
acces-list-number: é a lista de acesso com o ip virtual, o ip a ser traduzido.
Exemplo:
!
ip nat pool SERVER_LIST 10.1.1.100 10.1.1.101 prefix-length 24 type rotary
ip nat inside destination list 110 pool SERVER_LIST
!
access-list 110 permit tcp any host 192.168.1.100
!
|
O ip 192.168.1.100 será traduzido ora para o ip 10.1.1.100, ora para o ip 10.1.1.101 realizando então, a distribuição de carga.
5.0 – O Lab
 |
| Figura - 3 |
Na verdade não há mais muito que fazer. Aproveitando as configurações da distribuição de carga acima, basta colocar o mesmo ip em start-ip e end-ip e pronto. Como os ips são os mesmos, só haverá a tradução para um único ip.
Exemplo:
!
ip nat pool SERVER_LIST 10.1.1.100 10.1.1.100 prefix-length 24 type rotary
ip nat inside destination list 110 pool SERVER_LIST
!
access-list 110 permit tcp any host 192.168.1.100
!
|
O ip 192.168.1.100 será traduzido ora para o ip 10.1.1.100 ora para o ip 10.1.1.100 ou seja, para o mesmo ip realizando assim a tradução do ip de destino.
6.0 – Scripts
hostname PE
!********************************************
!
interface FastEthernet0/0
ip address 172.16.1.1 255.255.255.0
!
interface Serial1/0
ip address 200.1.1.1 255.255.255.252
!
router bgp 4200
no synchronization
bgp log-neighbor-changes
redistribute connected
neighbor 200.1.1.2 remote-as 65000
no auto-summary
!
hostname CPE
!********************************************
!
interface FastEthernet0/0
ip address 10.1.1.1 255.255.255.0
ip nat inside
!
interface Serial1/0
ip address 200.1.1.2 255.255.255.252
ip nat outside
!
router rip
redistribute connected
redistribute bgp 65000 metric transparent
network 10.0.0.0
!
router bgp 65000
no synchronization
bgp log-neighbor-changes
redistribute connected
neighbor 200.1.1.1 remote-as 4200
neighbor 200.1.1.1 default-originate
no auto-summary
!!
ip route 0.0.0.0 0.0.0.0 10.1.1.100
!
ip nat pool SERVER_LIST 10.1.1.100 10.1.1.100 prefix-length 24 type rotary
ip nat inside destination list 110 pool SERVER_LIST
!
access-list 110 permit tcp any host 192.168.1.100
!
hostname SERVER
!********************************************
!
enable secret cisco.
!
interface FastEthernet0/0
ip address 10.1.1.100 255.255.255.0
!
router rip
network 10.0.0.0
!
|
7.0 – Troubleshooting
PE#telnet 192.168.1.100 /source-interface FastEthernet 0/0
Trying 192.168.1.100 ... Open
User Access Verification
Password:
SERVER>
CPE#sh ip nat translations
Pro Inside global Inside local Outside local Outside global
tcp 192.168.1.100:23 10.1.1.100:23 172.16.1.1:18939 172.16.1.1:18939
tcp 192.168.1.100:23 10.1.1.100:23 172.16.1.1:64147 172.16.1.1:64147
CPE#debug ip nat detailed
IP NAT detailed debugging is on
CPE#
*Mar 1 00:33:46.011: NAT*: o: tcp (172.16.1.1, 18790) -> (192.168.1.100, 23) [52931]
*Mar 1 00:33:46.015: NAT*: o: tcp (172.16.1.1, 18790) -> (192.168.1.100, 23) [52931]
*Mar 1 00:33:46.019: NAT*: s=172.16.1.1, d=192.168.1.100->10.1.1.100 [52931]
*Mar 1 00:33:46.099: NAT*: i: tcp (10.1.1.100, 23) -> (172.16.1.1, 18790) [23401]
*Mar 1 00:33:46.099: NAT*: s=10.1.1.100->192.168.1.100, d=172.16.1.1 [23401]
*Mar 1 00:33:46.167: NAT*: o: tcp (172.16.1.1, 18790) -> (192.168.1.100, 23) [52932]
*Mar 1 00:33:46.167: NAT*: s=172.16.1.1, d=192.168.1.100->10.1.1.100 [52932]
*Mar 1 00:33:46.179: NAT*: o: tcp (172.16.1.1, 18790) -> (192.168.1.100, 23) [52933]
CPE#
PE#sh ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route
Gateway of last resort is 200.1.1.2 to network 0.0.0.0
200.1.1.0/30 is subnetted, 1 subnets
C 200.1.1.0 is directly connected, Serial1/0
172.16.0.0/24 is subnetted, 1 subnets
C 172.16.1.0 is directly connected, FastEthernet0/0
10.0.0.0/24 is subnetted, 1 subnets
B 10.1.1.0 [20/0] via 200.1.1.2, 00:50:49
B* 0.0.0.0/0 [20/0] via 200.1.1.2, 00:50:49
PE#
!
|
Obs.: Notem que testamos a tradução do ip realizando um telnet para o ip virtual. Neste tipo configuração o ping (ICMP) não funciona. Caso seja necessário testar a conectividade com o ip virtual através de ping, acrescente as seguintes linhas no CPE:
hostname CPE
!
interface FastEthernet0/0
ip address 192.168.1.100 255.255.255.0 sec
!
ip nat inside source static 192.168.1.100 10.1.1.100 extendable
!
|
Nenhum comentário:
Postar um comentário