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