Existem duas regras que devem "bater" uma com a outra, a saber:

# iptables -t nat -A PREROUTING -i eth1 -p tcp --dport 80 -j REDIRECT --to-port 3128
# iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

Estas duas regras acima, se uma for colocada somente pela placa de rede (eth0, no exemplo acima) a regra de redirecionamento também deve ficar somente pela placa de rede.

Se uma regra for colocada com a origem (-s) setando o endereço da sub-rede com a máscara da sub-rede, a outra regra TAMBÉM deve ser setada com o endereço da sub-rede e com a mascara da sub-rede, para não causar instabilidade na rede.

# iptables -t nat -A PREROUTING -s 172.16.1.0/24 -i eth1 -p tcp --dport 80 -j REDIRECT --to-port 3128
# iptables -t nat -A POSTROUTING -s 172.16.1.0/24 -o eth0 -j MASQUERADE

Isto é necessário, porque o IPtables lê os cabeçalhos dos pacotes (além de outras informações) e aplica suas regras de acordo com essas informações.

Com as regras acima desencontradas, o IPtables irá funcionar, porém, dependendo do pacote a ser analisado, ele poderá bloquear ou liberar alguma coisa que não estava prevista e causar confusão para o administrador da rede.

Por exemplo, quando um usuário de uma máquina cliente "abre" um site (solicitação de pacote), esta solicitação vai para o gateway da rede interna com IPtables (se tiver um) e o gateway repassa o pacote para o modem/roteador de acordo com as regras de liberações ou bloqueios.

O modem/roteador, por sua vez, seta na sua tabela de roteamento o endereço IP de origem da máquina cliente, porém, não repassa essa informação adiante. Somente guarda para ele, afim de que possa retransmitir a resposta do pacote quando ela voltar para a máquina cliente que o solicitou, e o roteador envia o pacote para fora colocando no cabeçalho o seu próprio endereço IP como sendo o IP de origem.

Por isso é que TODAS as solicitações de pacotes de uma sub-rede interna, quando saem para a rede externa (internet), saem com o mesmo endereço IP de origem, ou seja, o IP do modem/roteador.

Explicando mais ainda: se em uma rede interna tiver 500 máquinas clientes e todas elas forem ligadas e cada uma solicitar um site diferente, TODOS os 500 sites solicitados terão, na internet, o mesmo endereço IP de origem (o do modem/roteador).

Para comprovar, faça o teste na sua rede. Abra 3 ou 4 sites que fornecem o IP (Seu IP: xxx.xxx.xxx.xxx) e você verá que todos eles apresentam o mesmo IP (o do modem/roteador).

Quando o pacote voltar da rede externa (internet, na maioria dos casos) o modem/roteador faz o processo inverso, ou seja, recebe o pacote e o encaminha para a máquina cliente que o solicitou.

O pacote, então, entra no servidor com IPtables para ser repassado (FORWARD) para a rede interna e no cabeçalho do pacote irá constar o endereço IP da máquina cliente que solicitou o pacote (o site).

Nesse processo da volta do pacote, o IPtables irá ler o cabeçalho de novo e endereçar ao IP do cliente que o solicitou.

Caso as duas regras acima estiverem desencontradas, poderá acontecer de ele bloquear o pacote na saída ou na entrada, dependendo da ordem de colocação das regras, uma em relação à outra.

Veja bem, colocando o redirecionamento ANTES do compartilhamento, o tráfego irá passar primeiro pelo proxy, mas já com as liberações e bloqueios do IPtables. É claro que, depois da regra do redirecionamento, você poderá inserir outras regras no IPtables. Mas, nesse caso, os pacotes com os protocolos da pilha TCP/IP terão regras do IPtables ANTES, depois serão submetidos às regras do proxy (Squid) e novamente o iptables tentará aplicar as regras colocadas depois. E isso poderá dar conflito se você não atentar para a ordem de colocação das regras.

E colocando o redirecionamento DEPOIS do compartilhamento, o IPtables fará suas liberações e bloqueios e compartilhará os pacotes com as outras placas de rede e somente depois é que o proxy aplicará as suas regras.

Por isso, ás vezes, acontecem as confusões entre Squid e IPtables.

* Faça da forma que quiser, mas atente sempre para a ordem de colocação das regras.

O IPtables e o Squid são ótimas ferramentas (as melhores para seu uso, em minha opinião), mas como todo software de elite, eles requerem algum estudo.

Há que se fazer agora uma distinção ente NAT e mascaramento:

• NAT é a tradução de endereços de rede.
• Mascaramento "mascara" todos os IPs de origem da rede, ou sub-rede, fazendo com que todos os IPs da sua rede ou sub-rede, quando saírem para fora (internet na maioria dos casos), sairão usando um único IP.
  
  
• Endereçamento Estático: também chamado de IP fixo. É fixado na máquina cliente.
• Endereçamento Dinâmico: também chamado de IP automático, apesar de que há uma diferença técnica entre os dois. O IP dinâmico é fornecido pelo servidor DHCP ao cliente e sempre muda.

O IP automático é fornecido pelo DHCP ao cliente, mas é sempre o mesmo IP, ou seja, o IP automático é aquele fixado pelo endereço MAC no DHCP sendo que a máquina cliente está com IP automático nas suas configurações. Porém, só uma questão de denominação.

As conexões com IP dinâmico devem ser usadas com regras "-j MASQUERADE", as conexões com IP fixo devem usar "-j SNAT --to-source IP".

No manual do IPtables, está bem explícito que fazer mascaramento em IPs fixos pode ser considerado uma falha. Ou seja, se você fixar o IP da placa de rede de entrada do servidor, deve usar o -j SNAT em vez do -j MASQUERADE.

No manual do IPtables:

    "masquerade :: Este alvo só é válido na tabela nat na chain POSTROUTING. Ele só deve ser utilizado com IP atribuído dinamicamente (dialup) . Caso você tem um endereço IP estático, você deve usar o alvo SNAT.

    O mascaramento é equivalente a especificar um mapeamento do endereço de IP dos pacotes da interface de saída. Quando a interface estiver desligada a conexão é perdida. Este é o comportamento correto quando a conexão seguinte seja pouco provável que tenha o endereço da mesma interface (e, portanto, todas as conexões estabelecidas serão perdidas).

    É preciso uma opção: --to-ports port[-port] :: Especifica uma faixa de portas de origem, substituindo o padrão snat de seleção heurística de porta (ver acima). Isso só é válido se a regra também especifica -p tcp ou -p udp.

    snat :: Este alvo só é válido na tabela nat na chain POSTROUTING. Ele especifica que o endereço de origem do pacote deve ser modificado (e todos os outros pacotes, neste contexto, também serão modificados), e as regras referentes deixam de ser examinadas.

    É preciso um tipo de opção: --to-source ipaddr[-ipaddr][:port[-port]] :: Que pode especificar um novo endereço IP de origem único, um range abrangente de endereços IP e, opcionalmente, um range de portas (que só é válido se a regra também especifica -p tcp ou -p udp)."

Exemplos

Com IP fixo na placa de rede de entrada do servidor:

# iptables -t nat A POSTROUTING -o eth0 -j SNAT --to-source ip_da_placa_do_servidor

Nesta regra acima, todos os pacotes que saírem pela interface de rede eth0, terão os endereços de origem alterados para o IP do servidor, o que é o correto, pois a placa de rede está com IP estático.

Lembrando que, nesse caso, o endereço IP deverá "bater" com a faixa de rede colocada na regra de redirecionamento, caso tenha proxy no servidor, e com o IP fixado na placa de rede.

Com IP dinâmico na placa de rede de entrada do servidor:

# iptables -A POSTROUTING -o eth0 -j MASQUERADE

Se você fixar o IP da placa de rede de entrada no seu servidor e colocar "-j MASQUERADE", quando o pacote voltar, será encaminhado pelo IPtables para a placa de rede especificada na regra (no caso a eth0), porém, no cabeçalho do pacote poderá ter um IP que não é o mesmo que você fixou na placa de rede do servidor e isso fará a conexão funcionar ás vezes e ás vezes não funcionar.

Veja que, mesmo com as informações desencontradas, ainda assim o IPtables tenta encaminhar o pacote pela placa de rede.

Por isso que eu prefiro, em um servidor de sub-rede interna, deixar a placa de rede de entrada como DHCP, ou seja, com IP dinâmico e utilizar "-j MASQUERADE".

Dessa maneira, a placa de rede de entrada do servidor "pegará" seu IP do DHCP superior hierarquicamente (geralmente o DHCP do modem/roteador), evitando assim, aborrecimentos com problemas futuros de conexão.

Setar na regra o endereço da rede interna, com ou sem a placa de rede na regra, irá adicionar essa informação no cabeçalho do pacote, e assim como todo software, o IPtables é muito burro e disciplinado, ele só faz o que mandaram ele fazer. Então, ele irá encaminhar o pacote especificamente de acordo com as informações recebidas.

Por isso a ordem de colocação das regras no IPtables é importante, bem como as suas regras, logicamente, devem "bater" umas com as outras.