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

[César Augusto Santiago]

Apenas para complementar a dúvida abaixo. Como posso verificar one
esta esta marcação de pacotes? Eu não consegui localizar através do
ethereal. Acho que preciso analisar isso para ver o que esta
acontecendo.

Abraços,

César

2006/5/18, César Augusto Santiago <csantiagobr at gmail.com>:
> 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
>


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