root@blog:/# chmod o+r *

A um tempo atrás postei aqui uma dica sobre um problema comum de pessoas que estão tentando fazer um redirecionamento utilizando DNAT para um servidor que está na mesma rede lógica que a origem. Nela eu expliquei o que geralmente as pessoas tentam fazer, o porque de não dar certo e uma correção temporária para o problema. Agora, nessa segunda e última parte, apresento a 'solução ideal'.

Pra quem caíu aqui pelo google sugiro ler a primeira parte desse post!!!

Como dito no post anterior, manter servidores na mesma rede dos 'clientes' não só dificulta a administração da rede e dos servidores mas também aumenta drásticamente a possibilidade de falhas de segurança.

A ideia pincipal é criar uma rede segmentada somente para os servidores, facilidando a administração de regras do firewall e possibilitado a execução de outras tarefas que, com a outra topologias, seriam inviáveis.

Cenário

Nesse cenário teremos 2 redes, 192.168.1.0/24 e 192.168.2.0/24. Se você não entende muito bem de redes lógicas, endereçamento IP e roteamento tente somente aceitar que ambas são diferentes, futuramente estarei dedicando alguns posts pra explicar esse caso. A rede 192.168.1.0/24 será a rede dos clientes enquanto a rede 192.168.2.0/24 será a rede dos servidores.

http://under-linux.org/members/magnu...cenario3-2.gif

O Firewall será responsável pela interligação das 2 redes e de prover acesso a internet a ambas as redes. Para isso o firewall deverá possuir 3 interfaces. Nesse exemplo estaremos considerando a eth0 como sendo a interface que provê acesso a internet, a eth1 se conecta a rede dos clientes e a eth2 se conecta a rede dos servidores. Para as pessoas que não estão acostumadas a configurar um Linux para rotear dessa forma a configuração das interfaces pode parecer complicada. Para demonstrar a configuração da interface vamos assumir que a internet é entregue em tecnologia Ethernet, a interface possuirá o IP válido 200.200.200.1/30 meu gateway de internet é o 200.200.200.2/30 e o DNS é 200.200.200.200.

Pra ele rotear devemos habilitar o roteamento:
echo "1" >/proc/sys/net/ipv4/ip_forward

E pro pessoal navegar, devemos fazer o MASQUERADE:
iptables -t nat -A POSTROUTING -s 192.168.1.0/24 -i eth1 -j MASQUERADE
iptables -t nat -A POSTROUTING -s 192.168.2.0/24 -i eth2 -j MASQUERADE

No caso do Ubuntu o arquivo de configuração das interfaces seria o seguinte:

# Loopback
auto lo
iface lo inet loopback

# Eth0 - Conexão com a internet
auto eth0
iface eth0 inet static
address 200.200.200.1
netmask 255.255.255.252
network 200.200.200.0
broadcast 200.200.200.3
gateway 200.200.200.2
dns-nameservers 200.200.200.200

# Eth1 - Conexão com os clientes
auto eth1
iface eth1 inet static
address 192.168.1.254
netmask 255.255.255.0
network 192.168.1.0
broadcast 192.168.1.255

# Eth2 - Conexão com os clientes
auto eth2
iface eth2 inet static
address 192.168.2.254
netmask 255.255.255.0
network 192.168.2.0
broadcast 192.168.2.255

A essa altura alguém pergunta: "Cade o gateway das interfaces eth1 e eth2??". Ai eu respondo: "Não precisa!!!". Não sei porque mas muitas pessoas acham que toda interface tem que ter um gateway...

Definição de gateway: "Um ativo de rede que conecta uma ou mais redes a outra rede distinta."

Do ponto de vista do roteamento o default gateway é a ultima opção quando o router não sabe mais o que fazer com um pacote. Sabe quando você ta tentando resolver um problema de Linux e não sabe mais o que fazer?! pois é!!! o que você faz? Posta no Under-Linux!! Então o Under-Linux é o seu gateway .

Nessa altura talvez alguém tenha pensado: "então o firewall é um gateway??". Exatamente, ele interliga duas ou mais redes (192.168.1.0 e 192.168.2.0) a uma rede distinha (internet). Por isso quando configurarmos os clientes e o servidores colocaremos o Firewall como gateway. "Então um gateway (firewall) pode ter outro gateway (200.200.200.2)??". É exatamente essa a ideia de geteways e roteamento, mas isso é uma outra estória!

Vamos a um exemplo de configuração dos clientes e servidores.
Cliente 1
IP: 192.168.1.1
Máscara: 255.255.255.0
Gateway: 192.168.1.254
DNS: 200.200.200.200

Servidor Web
IP: 192.168.2.1
Máscara: 255.255.255.0
Gateway: 192.168.2.254
DNS: 200.200.200.200

Simulação

Agora, vamos analizar o que ocorreria ao realiza aquele acesso com redirecionamento citado no post anterior.

http://under-linux.org/members/magnu...4-cenario3.gif

Passo 1
O host deseja se comunicar com o domínio (digamos www.dominio.com.br). O host realiza a consulta DNS e descobre que www.dominio.com.br está vinculado ao IP 192.168.1.254. Com isso o host preenche os campos do pacote e o envia da seguinte forma:
IP de Origem: 192.168.1.1
IP de Destino: 192.168.1.254

Passo 2
O firewall (192.168.1.254) recebe o pacote do host 192.168.1.1 e consulta suas regras de iptables. Lá ele encontra a seguinte regra:
iptables -t nat -A PREROUTING -s 192.168.1.0/24 -i eth1 -d 192.168.1.254 -p tcp --dport 80 -j DNAT --to 192.168.2.1

Como o tráfego bate com a regra (IP de origem, interface de entrada, IP de destino e porta de destino) o firewall faz o que é mandado DNAT para 192.168.2.1, ficando da seguinte forma:
IP de Origem: 192.168.1.1
IP de Destino: 192.168.2.1 (DNAT)

O servidor web (192.168.2.1) recebe o pacote do host 192.168.1.1 (que na verdade foi encaminhado pelo Firewall) e processa a requisição HTTP. Ao terminar o processamento ele devolve o pacote. Mas pra quem que ele devolve?? Pra Origem. E quem é a origem? É só consultar o pacote! De acordo com o que vimos, a origem é 192.168.1.1 (veja o fim do passo 2)! Mas tem um pequeno problema! Eu (servidor web falando) estou na rede 192.168.2.0 e o destino está na rede 192.168.1.0, como estamos em redes diferentes tenho que mandar pro meu gateway! "Então ele põe o IP de destino como sendo 192.168.2.254!!" Errado!! Se fosse assim, o Firewall acharia que esse pacote é pra ele e não pro 192.168.1.1!! O que ele faz é colocar o IP de destino como sendo o IP 192.168.1.1 e o endereço MAC de destino como sendo o MAC do gateway. Mínimo todo mundo deve tá assim: Mas calma, tudo vai fazer sentido!
Vamos dar uma olhada no pacote de resposta:
IP de Origem: 192.168.2.1
IP de Destino: 192.168.1.1

Passo 3
Quando o Firewall receber esse pacote ele vai ver que o endereço MAC é dele mas o IP não é, logo ele tem que rotear esse pacote!!!! Mas... antes de rotear ele consulta a tabela de NAT's dele e vê que esse pacote do 192.168.1.1 foi nateado pra 192.168.2.1, então temos que remover o NAT e devolver o pacote. Ao remover o NAT o pacote de destino ficará assim:
IP de Origem: 192.168.1.254
IP de Destino: 192.168.1.1

O host receberá o pacote e verificará que o pacote está endereçado a ele e que o quem respondeu foi realmente o 192.168.1.254. Com isso ele fecha a comunicação!

Conclusão

A essa altura vocês devem estar pensando: "Ah... isso foi muito roubada!! Mentira!". Não, não é mentira. Aquela topologia do post anterior só não funciona porque o pacote de retorno não volta pelo firewall e ele não tem a oportunidade de desfazer o NAT. Dessa forma os pacotes de retorno sempre passaram pelo Firewall e esse problema não ocorrerá.

Como dito essa solução melhora inclusive a segurança pois, você pode controlar que portas os clientes podem acessar nos servers. O que era impossível controlar na outra topologia uma vez que todos tinham acesso direto ao Firewall.

Agora, que concluí essa série de posts gostaria de saber se alguém tem algum pedido de tutoriais como esse voltado pra área de redes. Estou pensando em fazer alguns tutoriais explicando o roteamento (com muitos detalhes) e a configuração de rotas no Linux. Ou explicar um pouco de teória de endereçamento, redes, mascara e sub-redes... Alguém tem alguma sugestão de tema? Alguma preferência? Aguardo comentário...

Até mais...