Redes de Computadores · IPtables · Endereços IPs - Explicações básicas

Breves comentários básicos sobre redes internas de computadores, IPtables e endereços IPs.

[ Hits: 28.704 ]

Por: Buckminster em 10/05/2013


No IPtables



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.

Página anterior     Próxima página

Páginas do artigo
   1. Redes de computadores
   2. No IPtables
   3. Sobre Modem/Roteadores
Outros artigos deste autor

O Kernel Linux

Compilando o Squid3

Configuração do sistema, DHCP, compartilhamento e DNS no Debian Squeeze

Compilação do Squid 3 no Debian Wheezy

IPv6, DNSv6 e DHCPv6

Leitura recomendada

IPv6 completo Net Virtua

Linux Group Policy

Configurações Básicas no CentOS 7

Openconnect - Conexão de VPN Paloalto no Debian

A ferramenta Nagios aplicada a IPv6

  
Comentários
[1] Comentário enviado por danniel-lara em 10/05/2013 - 13:39h

Parabéns muito bom o Artigo

[2] Comentário enviado por Buckminster em 10/05/2013 - 15:53h


[1] Comentário enviado por danniel-lara em 10/05/2013 - 13:39h:

Parabéns muito bom o Artigo


Obrigado Daniel.

[3] Comentário enviado por adrianoh2 em 11/05/2013 - 00:54h

Muito bom! Artigo excelente e bem organizado! Parabéns!

[4] Comentário enviado por Buckminster em 11/05/2013 - 01:46h


[3] Comentário enviado por adrianoh2 em 11/05/2013 - 00:54h:

Muito bom! Artigo excelente e bem organizado! Parabéns!


Obrigado!

[5] Comentário enviado por cesar44ac em 11/05/2013 - 22:41h

Parabéns! Realmente muito bom! Artigo de qualidade!

[6] Comentário enviado por Buckminster em 11/05/2013 - 23:23h


[5] Comentário enviado por cesar44ac em 11/05/2013 - 22:41h:

Parabéns! Realmente muito bom! Artigo de qualidade!


Agradeço. Estamos aí.

[7] Comentário enviado por thyagobrasileiro em 31/12/2013 - 16:18h


[3] Comentário enviado por adrianoh2 em 11/05/2013 - 00:54h:

Muito bom! Artigo excelente e bem organizado! Parabéns!


Não sei se esta bem organizado, na Ultima pagina vc fala de algo que é pré-requisito para entender o conteúdo da pagina anterior. Como alguém pode entender Iptables sem entender primeiro sobre Endereçamento IP?

[8] Comentário enviado por Buckminster em 01/01/2014 - 19:25h


[7] Comentário enviado por thyagobrasileiro em 31/12/2013 - 16:18h:


[3] Comentário enviado por adrianoh2 em 11/05/2013 - 00:54h:

Muito bom! Artigo excelente e bem organizado! Parabéns!

Não sei se esta bem organizado, na Ultima pagina vc fala de algo que é pré-requisito para entender o conteúdo da pagina anterior. Como alguém pode entender Iptables sem entender primeiro sobre Endereçamento IP?


Quem trabalha, ou vai trabalhar com Iptables, subentende-se que o sujeito já entenda pelo menos o mínimo sobre endereçamento IP. Aliás, quem não tem um conhecimento mínimo sobre redes nem sabe o que é Iptables.

E mesmo que não entenda (muita gente que usa o Iptables não entende, inclusive você), o uso do Iptables não requer profundos conhecimentos de endereçamento IP. Até porque geralmente quem está começando no Iptables vai aprendendo sobre redes e sobre endereçamento IP concomitantemente.

Caso você não entendeu alguma coisa do artigo, posso te explicar. Qual é tua dúvida?

E se tu achas que não ficou bem, pode refazer o artigo aprofundando ele em endereçamento IP.

[9] Comentário enviado por f_tyet em 28/08/2014 - 15:48h

Olá,

Excelente Artigo, amigo, para quem está começando a se aprofundar em questões de rede (como é o meu caso).

Eu tenho um conhecimento maior do que muita gente, sobre linux e alguma coisa sobre redes... mas, resolvi começar a me aprofundar.

Tenho uma dúvida besta (acho eu), para compreender plenamente a estrutura da rede (modelo) que você colocou aqui no seu artigo.

Bem, no caso dos tempos de hoje, em que a operadora (no meu caso a NET) disponibiliza um modem/roteador/Ponto de Acesso Wireless, eu consigo montar uma rede básica:

MODEM/ROTEADOR/WIRELESS
|
|
SERVIDOR
|
|
(a)PC
(b)Netbook (wi-fi)
(c)Notebook (wi-fi)
(d)cel android 1 (LG L5)
(e)cel android 2 (Galaxy S2)
(f)PS3

Ou, necessariamente, eu tenho que ter o SERVIDOR com duas placas de rede e ter, ainda, um SWITCH, nos exatos moldes que você deu como exemplo?

Desde já,

Agradeço.

[10] Comentário enviado por Buckminster em 06/11/2014 - 20:03h

f_tyet

Desculpa a demora em responder.

Não necessariamente tu tens que ter um servidor. O servidor (dependendo do servidor) fornece maior controle sobre a rede. O switch serve para expandir a rede.

Com a arquitetura que tu apresentastes podes muito bem montar uma rede básica, mas teria que ter um switch de um número de portas que suporte o número de computadores da tua rede, caso queria expandí-la futuramente.

Caso optes por instalar um servidor, daí NECESSARIAMENTE ele terá que ter, no mínimo, duas placas de rede, uma de entrada e outra de saída dos dados para a rede.

Nessa arquitetura apresentada e caso opte não colocar o servidor, tu teria que colocar um switch ou, caso o modem/roteador tenha um número de portas suficientes que comporte as máquinas que se conectarão via fio, o switch é dispensável.

Pelo que estou vendo tem somente um PC que se conectará via fio. Se o modem/roteador tiver uma porta disponível para esse PC não se faz necessário o switch tendo em vista que as outras máquinas se conectarão via wireless.

Lembre-se que a conexão via fio é sempre melhor que a conexão via wireless.

[11] Comentário enviado por JJSantos em 15/11/2014 - 23:09h

Parabéns!

[12] Comentário enviado por buckminster em 27/03/2015 - 12:42h


[11] Comentário enviado por JJSantos em 15/11/2014 - 23:09h

Parabéns!

Obrigado.


Contribuir com comentário




Patrocínio

Site hospedado pelo provedor RedeHost.
Linux banner
Linux banner
Linux banner

Destaques

Artigos

Dicas

Tópicos

Top 10 do mês

Scripts