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

César Augusto Santiago csantiagobr at gmail.com
Thu May 18 22:47:33 -03 2006


oi Rubens,

São tantos problemas que as vezes fico até chateado de continuar
perturbando-o. Seguinte. Analisando tudo de forma melhor hoje
verifiquei que a solução em SNAT não funcionou. Creio que o motivo
seja simples, como as regras eram sequenciais, ele passou a fazer SNAT
sempre com o endereço especificado na primeira regra. Creio que seja
este o problema. Eu fiz o SNAT da seguinte maneira:

$IPT -A POSTROUTING -t nat -s 172.16.0.0/16 -o $IFWAN -j lab-net
$IPT -t nat -A lab-net -j SNAT --to 200.241.189.130
$IPT -t nat -A lab-net -j SNAT --to 200.199.217.66

Ainda estou trabalhando com apenas uma interface. Ocorre que o
ambiente esta em produção e é MUITO complicado desligá-lo durante a
semana. Ainda bem q domingo esta chegando.

Minhas rules hoje, depois de estudar suas explicações ficaram assim:

0:      from all lookup local
15:     from all fwmark 0x1 lookup principal
16:     from 200.241.189.130 lookup ebt
17:     from 200.199.217.66 lookup brt
18:     from all fwmark 0x4 lookup ebt
19:     from all fwmark 0x5 lookup brt
30:     from all fwmark 0x3 lookup load
32766:  from all lookup main
32767:  from all lookup default

-> Pacotes com origem em minhas redes internas e destinos a DMZ foram
amrcados com 1.

-> Pacotes com origem na DMZ da EBT foi marcado com 4 e com origem na
BRT foi marcado com 5.

-> Pacotes com origem nas redes internas e destino pro "mundo" foram
marcados com 3.

O MASQUERADE faz o balanceamento ainda cometendo aqueles erros.
Podemos voltar a este problema para depois avançar às DMZs?

Abraços.

César

2006/5/18, Rubens Kuhl Jr. <rubensk at gmail.com>:
> O Ethereal só mostraria algo se o pacote tivesse DSCP/TOS marcado; o
> fwmark é uma marca "virtual", que só acompanha o pacote nas estruturas
> de dados do kernel.
>
> Um jeito de conter o problema é fazer com que o tráfego da DMZ
> necessariamente saia pela EBT e só usar os endereços EBT por enquanto.
> Defina um serviço alternativo para o IP da BRT, só usado para testes,
> enquanto diagnostica o problema
>
> Para a diagnóstico, minha sugestão é observar os contadores de
> pacotes/bytes que fizeram match nas regras do iptables. Possivelmente
> colocar regras de iptables com o IP origem/destino dos testes na DMZ,
> ou com os fwmarks que você quer acompanhar, nas cadeias de FORWARD e
> POSTROUTING, só para fazer match, sem ação (ou jump para uma chain com
> -j RETURN).
>
> Mas você não tem mais detalhes do problema para nos contar ?
> Conexões chegam a ser estabelecidas, ou ficam penduradas em SYN_RECEIVED ?
> Alguma origem funciona e outras não ?
> Conexões iniciadas da DMZ funcionam ?
>
>
> Rubens
>
> On 5/18/06, César Augusto Santiago <csantiagobr at gmail.com> wrote:
> > 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
> > --
> > gter list    https://eng.registro.br/mailman/listinfo/gter
> >
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter
>


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



More information about the gter mailing list