Re: [GTER] Roteamento avançado: identificação de pacotes
César Augusto Santiago
csantiagobr at gmail.com
Thu May 18 10:24:36 -03 2006
Bom Dia,
Primeiro quero novamente agradecer a força que está dando. Ao Marlon
quero dizer que está cheio de razão e que tentei fazer isso antes, mas
que o desespero aqui fez com que eu tivesse que expor meu ambiente
para tentar chegar a solução masi rápida.
Rubens, suas explicações estão me ajudando muito e esta facilitando a
tirar esta nuvem negra aqui, inclusive vendo problemas que ainda não
havia percebido.
Vamos lá, ainda com relação a explicação de ontem:
- 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.
- Cometi um erro enorme na minha tabela mangle, estava esquecendo de
dar um -F nela no início do firewall e por isso haviam centenas de
regras duplicadas. E o fato de ter enviado a mesma sem o verbose fez
vc entender que eu estava tentando balancear a saída da minha DMZ. Por
enquanto, estou tentando balancear o acesso à Internet realizado pelas
estações. Vou copiar novamente a tabela mangle aqui com a sua
definição básica:
==> 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
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.
---------
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.
==> Saindo pela Brasil Telecom.
traceroute to www.detran.ms.gov.br (200.181.116.5), 30 hops max, 38 byte packets
1 10.2.1.1 (10.2.1.1) 0.136 ms 0.117 ms 0.113 ms
2 200-199-217-65.cpece300.ipd.brasiltelecom.net.br (200.199.217.65)
319.762 ms 190.956 ms 265.232 ms
3 0431051.ipd.brasiltelecom.net.br (201.24.5.181) 1490.445 ms
1611.157 ms 1221.061 ms
4 * * *
5 BrTC-S4-0-4-cpece300.brasiltelecom.net.br (200.163.40.82) 416.003
ms 661.573 ms 680.836 ms
(este é o destino final)
-------
==> Saindo pela Embratel
traceroute www.detran.ms.gov.br
traceroute to www.detran.ms.gov.br (200.181.116.5), 30 hops max, 38 byte packets
1 10.2.1.1 (10.2.1.1) 0.162 ms 0.116 ms 0.107 ms
2 200.241.189.129 (200.241.189.129) 9.439 ms 3.486 ms 3.221 ms
3 embratel-S4-0-acc03.cpe.embratel.net.br (200.242.182.37) 20.715
ms 11.991 ms 3.719 ms
4 ebt-G0-2-dist02.cpe.embratel.net.br (200.230.159.148) 34.761 ms
34.753 ms 34.945 ms
MPLS Label=344 CoS=5 TTL=1 S=0
5 ebt-A2-2-4-core03.spo.embratel.net.br (200.230.0.254) 39.262 ms
47.819 ms 36.921 ms
MPLS Label=296 CoS=5 TTL=1 S=0
6 ebt-P4-0-dist05.bsa.embratel.net.br (200.244.40.45) 40.935 ms
89.833 ms 67.206 ms
MPLS Label=401 CoS=5 TTL=1 S=0
7 ebt-G6-0-gacc02.bsa.embratel.net.br (200.244.165.2) 382.454 ms
216.811 ms 219.273 ms
8 brasiltelecom-P3-2-gacc02.bsa.embratel.net.br (200.252.129.30)
1332.385 ms 995.543 ms 917.278 ms
9 * * *
10 BrTC-S4-0-4-cpece300.brasiltelecom.net.br (200.163.40.82) 1101.543 ms * *
---
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.
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.
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?.
Já estou mais aliviado agora. Um grande abraço e muito obrigado.
César Augusto Santiago
2006/5/18, Rubens Kuhl Jr. <rubensk at gmail.com>:
> > 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
> --
> gter list https://eng.registro.br/mailman/listinfo/gter
>
--
César Augusto Santiago
csantiagobr at gmail.com
More information about the gter
mailing list