"Houston, we have a problem!"

Problema

Um cliente solicitou que fosse feito um redirecionamento das portas 80 e 443 para um servidor web que se encontra na rede interna da empresa, pois os consultores externos iriam iniciar os testes no novo sistema.

No firewall foi adicionada uma regra de redirecionamento (os usuários do IPTables conhecem como DNAT), você testou e está tudo ok!

Ao solicitar o teste por parte do cliente, ele lhe diz que não consegue fazer o acesso.

Causa

A causa deste problema está no percurso em que o pacote percorre quando o servidor responde à requisição de uma estação que está na rede interna.

Observe na figura 1 o caminho que é feito pelo pacote quando há uma requisição de fora da rede interna:

Obs.: Os endereços contidos neste documento são aleatórios, apenas para demonstração. Neste caso o mesmo caminho é percorrido tanto na ida quanto na volta. O pacote consegue ir e voltar sem nenhum empecilho.

Observe agora na figura 2 como isto ocorre quando a requisição é feita da rede interna: Podemos verificar que o caminho percorrido é diferente. O servidor não encaminha o pacote de resposta para o seu gateway. Vejamos mais detalhadamente o caminho que o pacote percorre:

1. A estação solicita conexão (pacote com flag SYN ativado) para o IP 200.254.225.31.
2. O firewall modifica o destination ip para fazer o port forward (novo destination: 172.15.25.3).
3. O servidor recebe o SYN packet e responde com pacote de aceite da conexão (pacote com os flags SYN e ACK ativados) para o IP da estação (172.15.25.100).
4. Na tabela de roteamento do servidor este pacote é redirecionado para o barramento, pois tem como destino um IP da mesma rede que ele está conectado, sem passar pelo gateway.
5. A estação recebe o pacote SYN/ACK e, após verificar que não está esperando resposta de conexão deste host (172.15.25.3), mas sim do host (200.254.225.31), ele descarta o pacote.
6. Após o período de timeout da conexão, esta é descartada.

Aplicando uma solução

Uma solução que pode ser utilizada neste caso é criar uma regra que modifique o source address do pacote durante o caminho de ida. Seria como mascarar o pacote que venha da rede interna e tenha destino o IP e porta do servidor.

Vou exemplificar com regras do IPTables. Porém, para um melhor entendimento desta regra, é melhor darmos uma olhada no caminho que o pacote percorre nas chains e tabelas do IPTables. (fonte: Iptables Tutorial 1.1.19, Chapter 3)

Bom, para o DNAT, utilizamos:

# iptables -p tcp -t nat -A PREROUTING -d 200.254.225.31 --dport 80 -j DNAT --to-destination 172.15.25.3:80

As regras de DNAT são aplicadas na tabela NAT, chain PREROUTING. As de SNAT, na tabela Nat e chain POSTROUTING.

Analisando a figura 3, vemos que quando o pacote chega na chain POSTROUTING, ele já passou pela PREROUTING. Desta forma o seu destination já foi alterado. Então a nossa regra tem que filtrar os pacotes vindo de toda a rede interna (ou um ip dela, a depender do caso) com destino o servidor (dentro da rede interna também) na porta 80, e não o IP 200.254.225.31.

Segue a regra:

# iptables -p tcp -t nat -A POSTROUTING -s 172.15.25.0/100 -d 172.15.25.3 --dport 80 -j SNAT --to-source 200.254.225.31

Após isto, basta permitirmos o tráfego do pacote na tabela filter, chain FORWARD e pronto, está tudo funcionando corretamente. Segue a regra:

# iptables -p tcp -t filter -A FORWARD -s 172.15.25.0/100 -d 172.15.25.3 --dport 80 -j ACCEPT

Veja como ficou o novo desenho na figura 4: Notem que agora a estação recebe o pacote SYN/ACK do mesmo IP que ele havia solicitado antes.

Esta lógica pode ser utilizada para demais ferramentas de firewall, bastando estudar antes como o pacote trafega dentro dele para assim gerar as regras necessárias. O resto, a lógica é a mesma.

Obs.: Este artigo foi publicado originalmente por mim em:

• Port Forward mais completo - Zé Bob na Itália