Utilizando vários IPs fornecidos pelo ISP

3

Isso é um pouco complexo, então fique comigo. Eu tenho um ótimo conhecimento de IP, mas estou procurando ajuda sobre a melhor maneira de implementar isso.

Meu ISP me deu um bloco de IPs estáticos, bem como um único IP. Para fins de privacidade, aqui está o layout de rede que vou usar nos meus exemplos:

  • 192.168.1.0/24 - LAN
  • 172.16.0.1/30 - IP estático único, padrão gw 172.16.0.2
  • 172.16.1.1-5 / 28 - Faixa de IPs estáticos, padrão gw 172.16.1.6

Nestes exemplos, 172.16.0.1 e 172.16.1.1-5 são, na realidade, IPs da Internet de roteamento mundial. Estou usando blocos IP privados para fins de privacidade. Portanto, finja que 172.16.0.1 é o IP público que você quer imaginar e o mesmo para o bloco 172.16.1.1.

Meu serviço é fornecido por meio de uma interface de modem a cabo único com uma única porta Ethernet. Em outras palavras, espera-se que toda a comutação, roteamento, etc. seja feita no lado do cliente.

Atualmente, tenho um servidor Linux com duas interfaces Ethernet. É atribuído 172.16.0.1 estático e usa NAT para fornecer Internet para a interface LAN, que funciona perfeitamente. Eu usei essa configuração por anos para me fornecer um roteador NAT que eu tenha um controle muito mais profundo do que um roteador disponível no mercado.

Agora, quero começar a utilizar esses outros IPs estáticos que tenho. As capturas são estas:

  1. Eu ainda quero conseguir, pelo menos até certo ponto, controlar o acesso a essas caixas. Portanto, na caixa principal do Linux, gostaria de poder dizer que "172.16.1.1 não pode receber nenhuma conexão de entrada, exceto pela porta 80" ou "172.16.1.2 não pode conectar-se de saída a nada, exceto à porta 22". Apenas alguns exemplos. Em outras palavras, ainda quero o controle do firewall sobre essas caixas. Semelhante a como eu posso atualmente usar iptables para bloquear, digamos, 192.168.1.5 de ir a qualquer lugar, exceto onde eu quero, e neste exemplo, também contando as conexões de entrada também. Idealmente, isso significaria que eu posso obter todos os pacotes destinados a uma das cinco estáticas públicas roteadas via iptables e ter o mesmo nível de controle que eu faço sobre os pacotes da LAN.

  2. Os computadores na LAN (192.168.1.0/24) também precisam acessar essas máquinas voltadas para o público. Além disso, computadores no IPS público podem precisar acessar os computadores da LAN. Assim, 172.16.1.2 pode precisar acessar 192.168.1.5 e vice-versa.

  3. Os computadores que possuem IPs estáticos de roteamento mundial devem, se possível, ser autoconscientes de seu IP voltado para o público. Uma sugestão que eu vi para isso sugeriu colocar os computadores públicos na LAN e dar-lhes endereços de LAN, então usando multihoming na caixa Linux e encaminhando todas as portas da estática desejada para o IP da LAN desejado. Isso certamente funciona, mas cria algumas situações confusas - a caixa do Linux agora precisa estar ciente de cada IP estático e, portanto, isso não seria bem escalável. Então, por exemplo, "eth1" (a interface WAN) precisaria não apenas ter o IP que ele já usa, mas também todos os outros cinco IPs. Isso pode ser bom para cinco, mas o que dizer da escalabilidade quando, no futuro, houver 2000 IPs ....

Uma ideia que pensei foi adicionar uma terceira interface ao roteador Linux e configurar uma pequena rede que contenha apenas as máquinas voltadas para o público. A única questão, então, é rotear entre essas máquinas e a Internet. Além disso, a única maneira simples que consegui pensar para conseguir isso foi dar à caixa do Linux um segundo endereço IP na eth2, que usaria uma dessas cinco preciosas estatísticas.

Eu não quero ter que usar nenhuma solução comercial para conseguir isso. Eu acharia que o Linux deveria ser capaz de lidar com esse tipo de situação.

Este é o layout que eu espero que funcione, mas eu só preciso descobrir como fazer o próprio roteamento no Linux.

    
por fdmillion 05.06.2013 / 00:24

3 respostas

0

Eu finalmente percebi isso, e para o benefício de todos os outros, vale a pena escrever aqui.

Vou receber uma caixa com três interfaces Ethernet. Veja como os conectamos:

  • eth0 - > para modem a cabo
  • eth1 - > a um comutador no qual os computadores com endereços de WAN públicos residirão
  • eth2 - > a um switch para computadores LAN (NATted)

Nós configuramos uma ponte Linux usando bridge-utils (brctl), br0, que conecta eth0 e eth1.

Podemos então dar à interface br0 um dos endereços IP voltados ao público. Isso terminará sendo o endereço de origem dos pacotes provenientes dos computadores da LAN. Para a melhor segurança, vou usar o iptables para bloquear todo o tráfego não-NAT para este IP:

iptables -A INPUT d 172.16.0.1 -j DROP

Isso funciona porque o tráfego NAT será passado na cadeia FORWARD, enquanto o tráfego não solicitado da Internet aparecerá no INPUT.

Agora, no switch da WAN, posso colocar outros hosts. Moverei meu servidor principal - o servidor da Web e assim por diante - para esse comutador e, estaticamente, atribuirei a ele um dos IPs públicos roteáveis pelo mundo.

A verdadeira razão pela qual isso não era óbvio para mim antes era que eu não achava que poderia criar um firewall em uma interface de ponte - eu não sabia que os pacotes de uma ponte realmente passavam pelo iptables. Acontece que não apenas eu posso fazer isso, mas eu posso até usar truques como o ulogd e ferramentas similares para fazer o monitoramento de banda e assim por diante. A chave para isso é um módulo iptables chamado physdev , que permite firewall baseado em qual interface física um pacote está entrando ou saindo, independentemente da ponte das interfaces.

Para adicionar regras de firewall à tabela FORWARD, por exemplo:

iptables -A FORWARD -d 172.16.1.2 -p tcp --dport 80 -m physdev --physdev-in eth0 -j ACCEPT
iptables -A FORWARD -d 172.16.1.2 -m physdev --physdev-in eth0 -j DROP

Isso acaba permitindo o tráfego da porta 80 para 172.16.1.2 da Internet, mesmo que essa máquina tenha um IP público. (Lembre-se em meus exemplos 172.16.x.x são públicos, embora todos nós saibamos que na realidade não são.)

Como estou usando physdev , isso significa que as máquinas no lado da LAN ainda podem ter acesso total a esse host. Então, do lado da LAN, ainda posso SSH para 172.16.0.1. Do ponto de vista de uma máquina LAN, o 172.16.0.1 não tem nenhum firewall. Do ponto de vista de outra máquina DMZ, a mesma coisa. No entanto, do ponto de vista da Internet, 172.16.0.1 está bloqueado.

Solução encontrada! Este acabou por ser um projeto muito divertido.

F

    
por 04.05.2014 / 09:53
2

se você adicionar a terceira interface como você tem acima para construir uma DMZ, o roteamento é simples. literalmente tudo o que você precisa fazer é habilitar o IP Forwarding e encaminhará os pacotes entre as interfaces conectadas.

ou

sysctl -w net.ipv4.ip_forward=1

ou

echo 1 > /proc/sys/net/ipv4/ip_forward

para ativá-lo em tempo real

ou definir

net.ipv4.ip_forward=1 em /etc/sysctl.conf

Então você só precisaria de regras de firewall para controlar o acesso aos computadores Lan a partir da DMZ, você ainda usaria NAT da interface Wan para a interface LAN, você confiaria nas regras de acesso Routing + para controlar da WAN para a DMZ e o DMZ para LAN. O fato de o GW padrão da DMZ e da LAN ser a mesma caixa, você não terá que retransmitir rotas estáticas nos computadores DMZ ou LAN para acessar um ao outro. Outra opção é colocar 2 placas ethernet em cada host DMZ, e conectá-las ao lan também, mas isso não é tão limpo quanto usar o Roteador no meio e listas de acesso (iptables) para ditar o que pode falar com o quê.

    
por 05.06.2013 / 06:50
0

A funcionalidade que você está procurando é "alias de rede", suponho. Então, o que você precisa fazer é configurar "vários NAT" para esses aliases de rede.

Eu não sei o que você está executando, na verdade, na caixa do seu roteador linux, mas se eu pudesse sugerir uma solução, basta instalar o "pfSense", que tem um monte de recursos ( link ) ou IPCop ( link ), é muito mais fácil de administrar, pois é uma solução gráfica.

Corresponde exatamente ao seu caso de uso:

Além disso, ele é executado em um hardware muito antigo.

Yann

    
por 05.06.2013 / 10:25