Re: [GTER] Roteamento avançado: identificação de pacotes

[Rubens Kuhl Jr.]

> Rubens e "ouvintes",
>
> Certo... já que você está disposto mesmo a colaborar, o que agradeço
> imensamente, vou detalhar minha infra-estrutura para ver se facilita
> seu apoio. Vamos lá.

Facilita e possibilita... eu vou deixar apenas os trechos da resposta
que foram relevantes para minhas recomendações.


> Meu Firewall (vou me referir a ele como NS2) possui 4 interfaces de
> rede, sendo elas conforme segue:

Eu vi uma quinta numa rota, imagino que seja a interface que você vá
usar para separar o trafégo entre ebt e brt depois. Só cuidado para
não deixar esta rota inadvertidamente:

> [root at ns2 fwconf]# ip route show table main
> 200.199.217.112/29 dev eth4  proto kernel  scope link  src 200.199.217.115



> *** Estes firewalls que estão conectados a estas interfaces atendem
> nossa rede Administrativa e Rede Acadêmica. Eles estão tratando o
> acesso na camada de Forward e cada um deles gerencia diversas redes
> diferentes. Por este motivo tive que alimentar a tabela de roteamento
> do servidor de balanceamento com rotas estáticas para as redes que
> estão atras dos dois firewalls. Como poderá ser visto lá na frente.

Mas como eles usam só DNAT e só há IPs privados, vou assumir que nada
atrás deles recebe conexão externa que não a DMZ.

> ---------------------------  RULES ------------------------
> 0:      from all lookup local
> 14:     from all lookup principal
> 16:     from 200.199.217.66 lookup brt
> 17:     from 200.241.189.130 lookup ebt
> 30:     from all fwmark 0x3 lookup load
> 32766:  from all lookup main
> 32767:  from all lookup default

Os lookups de IPs do firewall nas tabelas brt e ebt estão corretos,
mas faltaram dois que parece que você pressentiu que precisavam, que
seriam para obrigar a seguir a tabela ebt ou a tabela brt.

Assim, eu colocaria além dessas:

ip rule add fwmark 1 lookup ebt
ip rule add fwmark 2 lookup brt




>
> ########### FIREWALL ###########33
>
> Vou colocar a regra apenas para uma das redes atras dos firewalls,
> pois elas são identicas para as demais redes.
>
> => Tabela mangle
>
> Chain PREROUTING (policy ACCEPT)
> target     prot opt source               destination
> MARK       all  --  192.168.1.37         0.0.0.0/0           MARK set 0x3
> MARK       all  --  0.0.0.0/0            200.241.189.160/27  MARK set 0x1
> MARK       all  --  0.0.0.0/0            200.199.217.80/28   MARK set 0x2
> MARK       all  --  0.0.0.0/0            0.0.0.0/0           MARK set 0x3


O problema aqui é que a origem dos pacotes na DMZ é que deveria ser
usada para escolher o link de saída; se as conexões vieram pelo link
EBT, elas tem que voltar por ele.

Então onde havia
iptables -A PREROUTING -t mangle -i eth1 -d 200.241.189.160/27 -j MARK
--set-mark 1
iptables -A PREROUTING -t mangle -i eth1 -d 200.199.217.80/28 -j MARK
--set-mark 2
iptables -A PREROUTING -t mangle -i eth1 -j MARK --set-mark 3

(eu acho, estou chutando os -i baseado em seus e-mails anteriores)

Deveria haver
iptables -A PREROUTING -t mangle -i eth1 -s 200.241.189.160/27 -j MARK
--set-mark 1
iptables -A PREROUTING -t mangle -i eth1 -s 200.199.217.80/28 -j MARK
--set-mark 2
iptables -A PREROUTING -t mangle -i eth1 -j MARK --set-mark 3

Repare que é o IP origem e não o destino que está sendo testado.

Além disso, as conexões de saída geradas pela DMZ serão balanceadas,
mas as de entrada sairão por onde elas foram inicialmente
estabelecidas.

Outro detalhe é que apenas as conexões da DMZ serão balanceadas, as
outras vão seguir a rota default, que é a Embratel. Será que você não
imagina replicar o balanceamento para as redes dos firewalls também,
adicionando as seguintes regras ?
iptables -A PREROUTING -t mangle -i eth2 -j MARK --set-mark 3
iptables -A PREROUTING -t mangle -i eth3 -j MARK --set-mark 3

E eu vou especular sobre porque você não fez isso: porque não há todas
as rotas locais na tabela load. Eu recomendo você replicar todas as
rotas internas em todas as tabelas(ebt, brt, load), variando entre
elas apenas a rota default. Assim pode-se aplicar as políticas de
roteamento para Internet sem que isso afeta a conectividade interna.
Eu já perdi muito tempo de diagnóstico por tentar colocar numa tabela
apenas o que eu acreditava estritamente necessário para rotear no
cenário que imaginei... a experiência me mostrou que eu deveria fazer
limitações apenas no netfilter/iptables, deixando o roteamento o mais
abrangente possível, tentando levar o tráfego para onde os objetivos
do projeto quisessem mas sempre entregando o tráfego em algum lugar.

> MASQUERADE  tcp  --  10.2.1.2             0.0.0.0/0           tcp dpt:80
> MASQUERADE  tcp  --  10.2.1.2             0.0.0.0/0           tcp dpt:53
> MASQUERADE  udp  --  10.2.1.2             0.0.0.0/0           udp dpt:53

Como eu já disse em outro e-mail, livre-se do MASQUERADE e dos
problemas de funcionalidade e performance que costumam vir com ele em
situações de dual-homing.
Você vai ter que dividir a regra de MASQUERADE em duas regras de SNAT,
uma para cada interface de saída, e o IP estará fixo na regra com
--to-ip, o src da tabela de roteamento não será utilizado.

> Chain net-dmz (2 references)
> target     prot opt source               destination
> ACCEPT     tcp  --  0.0.0.0/0            200.241.189.170     tcp dpt:80
>
> Chain dmz-net (2 references)
> target     prot opt source               destination
> ACCEPT     tcp  --  200.241.189.170      0.0.0.0/0           tcp
> spt:80 flags:!0x16/0x02
> -----------------------------------------

Se você quer ter balanceamento das conexões iniciadas fora, vai ter
que levar o aliasing até o servidor HTTP da DMZ. Para isso, além de
permitir o tráfego HTTP para 200.241.189.170, vai ter que permitir
para (por exemplo) 200.199.217.90. E configurar no serivdor web um
alias com esse IP, configurar o web-server para atender também por
esse IP.

Com os dois IPs atendendo, é preciso também configurar isso no DNS:
www IN A 200.241.189.170
www IN A 200.199.217.90


> Veja que o firewall simplesmente autoriza tudo. Acontece que toda
> regra de segurança é realizada pelos outros 2 firewalls antes deste.
> Com exceção é claro da relacão Internet<-> dmz.

Curiosidade: HTTP é o único serviço disponibilizado pela DMZ ?
Serviços de uma única conexão TCP(SMTP, por exemplo) seguem o mesmo
padrão de HTTP acima, mas coisas mais complexas como FTP, PPTP e IPSEC
tem uma complexidade adicional com dual-homing...

> Neste cenário enfrentamos o problema que coloquei, de sair pelo router
> da embratel com IP da Brasil Telecom. Vou copiar aqui o resultado do
> Tarcert para um site hospedado na Brasil Telecom. Estou dando este
> tracert a partir do firewall anterior ao do balanceamento.

O estranho é que pela sua configuração (apesar de que na table mangle
não tinha o verbose para ver se a regra estava mesmo restringindo o
--set-mark 3 à interface eth1 da DMZ), tráfego de nenhum firewall
deveria ser balanceado, só da DMZ.


Boa sorte e nos mantenha a par dos resultados.


Rubens