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

[Rubens Kuhl Jr.]

> Primeiro quero novamente agradecer a força que está dando. Ao Marlon

Disponha...

> - Aquela rota que não citei (dificil esconder as coisas de vc, ehehhe)
> é de um terceiro Link onde vou hospedar um servidor de Stream. O
> servidor de stream está ligado diretamente ao Link e esta interface é
> para que minha rede interna acesse-o sem precisar sair pela Internet.

Só cuidado para no servidor de streaming colocar rotas para que ele
use essa interface interna ao invés da Internet, ou o roteamento
assimétrico pode te dar problemas.


> ==> Veja que estas regras abaixam tentam marcar os pacotes vindos da
> Interface de rede do firewall Acadêmico (eth3). Esta assim por
> enquanto, pois está meio "adaptado". Na verdade, ainda para o firewall
> acadêmico eu pretendia adicionar regras pela rede de origem e não pela
> interface. Acontece que são diversas redes e o firewall esta
> segmentado para tratá-las de forma independente.
> 8200 1220K MARK       all  --  eth3   *       0.0.0.0/0
> 200.241.189.160/27  MARK set 0x1
>     0     0 MARK       all  --  eth3   *       0.0.0.0/0
> 200.199.217.80/28   MARK set 0x2
> 22593 2204K MARK       all  --  eth3   *       0.0.0.0/0
> 0.0.0.0/0           MARK set 0x3
> ==> Estas regras abaixo são idênticas para as diversas redes de origem
> e objetivam que a rede saia balanceada pela Internet. Veja que
> coloquei a marcação para pacotes com destino a DMZ, pq entendi que se
> eu colocasse da forma como vc recomendou, dando -i na interface das
> minhas LANs, eu acabaria direcionando o balanceamento para os destinos
> da DMZ. Isso pq fiz os routes da forma mais enxuta possível,
> entretanto, acho que se eu fizer como vc disse, adicionar as rotas das
> redes estáticas e também as rotas das redes que estão ligadas ao
> firewall pode ser suficiente. Se for assim, para resolver o problema


Humm, agora entendi o que você queria com as marcas 1 e 2. Essa linha
de ação funciona também, desde que você pense em cada possibilidade de
tráfego. Replicar as rotas ajuda a diminuir o número de cenários que
você precisa avaliar.


> do fluxo redes <-> Internet e redes <-> dmz. Apenas a regra que
> sugeriu resolveria certo? Eu apesar de ter deixado os pacotes com
> destino a DMZ marcado, não utilizeu as rulez ebt e brt neles pq
> apresentou problemas.

No caso que você pensou de destino DMZ de fato é na tabela principal
que ele deveria fazer lookup.

> Com relação ao SNAT. Eu modifiquei ainda ontem a noite as regras para
> SNAT e parece que realmente resolveu o problema. Veja o resultado dos
> tracerts agora que está com SNAT.

Mais um caso para a pasta "MASQUERADE não é seu amigo".

> Eu ainda não coloquei o analisador de pacotes, mas aparentemente está
> funcionando. Resta saber se ele agora "acerta" mais e se ainda vai
> errar algumas vezes ou se ele não vai errar mais.

Dado que o SNAT sempre vai trocar para o IP da operadora por onde o
tráfego vai sair, esse problema some. O que pode acontecer é um
problema de no meio de uma conexão que fique sem tráfego (mas não seja
considerada down pelos stacks TCP das pontas), ele mudar de um
backbone para outro. Eu encaro esse problema como possibilidade
téorica apenas, mas é bom estar alerta e ter uma solução na manga para
ele.
(para registro, existe uma solução para isso que é usar CONNMARK)


> Com relação aos serviços rodando em minha DMZ há sim outros serviços,
> inclusive ftp. Sei que o ftp possui particularidades a nível de portas
> e que devem ser observadas no filtro de pacotes, mas não entendi qual
> a particularidade nesta questão de  dual-homing.

O problema é que um segundo fluxo é iniciado pelo servidor da DMZ em
direção ao IP do cliente, e ele precisa usar o mesmo IP da conexão
entrante, ou o cliente não vai entender pq ele abrir uma conexão de
controle com um servidor e outro que respondeu pra ele.
Esse tipo de coisa pode ser diferente daemon a daemon; se o próprio
daemon tomar essa atitude, não há problemas. Se não, rode duas
instâncias diferentes, cada uma deles com bind para o IP de um
backbone.

> Vou analisar melhor o que disse verificar esta questão de marcar os
> pacotes vindos da DMZ afim de que saiam por onde entraram, pois vou
> sim fazer o que disse sobre balancear o trafego entrante através de
> DNS. O Firewall já possui está preparado para isso, pelo menos eu
> acho. Nos fluxos net-dmz e dmz-net eu crio as regras pelo NOME dos
> servidores e por isso quando eu configurar o DNS com os endereços dos
> dois Links creio que ele irá duplicar as regras para os dois
> endereços, certo?.

Eu não confiaria nisso. Pelo contrário, meu feeeling diz ele vai
resolver o DNS para os dois endereços, pegar o primeiro deles naquele
set de respostas (o que 50% das vezes vai dar um IP, 50% das vezes vai
dar o outro IP) e implantar uma só regra no kernel. Eu nunca testei,
prefiro a previsibilidade de colocar as duas regras por IP númerico...
mas pode ser que um dia alguém tenha mudado isso em alguma versão do
iptables. Se você testar, nos conte.



Rubens