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

[César Augusto Santiago]

Rubens,


As coisas estão se clareando agora.. mas eu estou enfrentando problema
justamente naquele acesso internet <-> DMZ. Poderia me dar uma luz de
como eu devo tratar isso? Vc deu umas dicas no email anterior, mas não
consegui resolver aqui, continua dando problema.

Abraços,

César

2006/5/18, Rubens Kuhl Jr. <rubensk at gmail.com>:
> > 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
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter
>


-- 
César Augusto Santiago
csantiagobr at gmail.com