[GTER] Configuração de strong x weak host model para servidores

[Claudio Junior]

Carlos

obrigado pela dica.

Att.


--
Claudio da Silva Junior
csjunior at gmail.com

Em 8 de outubro de 2014 15:42, Carlos Ribeiro <cribeiro at telbrax.com.br>
escreveu:

> Cláudio,
>
> Mandei uns dias atrás na lista, segue de novo para sua referência. Essa
> receita resolve o problema do "strong host model" para envio de pacotes, e
> garante que pacotes de resposta a conexões iniciadas irão retornar pela
> interface onde entraram. Isso pode ser complementado com outras técnicas
> para controle de ARP mas é suficiente se você tiver duas interfaces em
> subredes IPs diferentes, como era meu caso:
>
> 1) Configuração básica
>
> eth0: 172.19.0.200
> eth1: 172.27.0.200
> Rota default: 172.19.0.1 (via eth0)
>
> 2) Política de roteamento
>
> A rede 172.19.0.0/24 atende o tráfego recebido em BH
> A rede 172.27.0.0/24 atende o tráfego recebido em SP
>
> (Desse jeito, um único servidor virtual - esteja em BH ou em SP - pode
> responder requests recebidos por qualquer um dos dois lados da rede e irá
> devolver para o firewall correto).
>
> 3) Criar uma nova tabela de roteamento
>
> echo 200 upstreamsp >> /etc/iproute2/rt_tables
>
> 3) Criar regras de "source routing" associadas ao tráfego originado do IP
> 172.27.0.200
>
> ip rule add from 172.27.0.200 lookup upstreamsp
> ip route add default via 172.27.0.1 dev eth1 table upstreamsp
>
> 4) Salvar a configuração de forma persistente
>
> post-up ip rule from 172.27.0.200 lookup upstreamsp
> post-up ip route add default via 172.27.0.1 dev eth1 table upstreamsp
>
> *Carlos Ribeiro*
> *Sócio*
> Cel: +55 (31) 9303-3366
> Tel: +55 (31) 3305-5620
> Geral: +55 (31) 3305-5600
> cribeiro at telbrax.com.br
> www.telbrax.com.br
>
> Em 8 de outubro de 2014 13:09, Claudio Junior <csjunior at gmail.com>
> escreveu:
>
> > Ola
> >
> > Gostaria de maiores informações sobre este assunto, principalmente como
> > mudar o modo de operar no linux.
> >
> > Você já tem mais algum material?
> >
> > Att.
> >
> >
> > --
> > Claudio da Silva Junior
> > csjunior at gmail.com
> >
> > Em 3 de outubro de 2014 15:09, Carlos Ribeiro <cribeiro at telbrax.com.br>
> > escreveu:
> >
> > > Prezados,
> > >
> > > Como parte de um trabalho para um cliente, estou pesquisando o suporte
> a
> > > tipos diferentes de "host model" para servidores. É um tema
> interessante
> > e
> > > para o qual existe relativamente pouca informação e troca de
> experiência.
> > >
> > > Basicamente, em um servidor com várias interfaces, existem dois modos
> > > primários de comunicação:
> > >
> > > - No "weak model" o servidor pode enviar e receber pacotes com o IP de
> > > qualquer uma das interfaces existentes em todas as interfaces. Este é o
> > > comportamento default do Linux e das versões antigas do Windows.
> > >
> > > - No "strong model" o servidor só pode receber (ou enviar) pacotes se o
> > IP
> > > de destino (ou origem) estiver na subrede correta para uma determinada
> > > interface. Este é o comportamento default do BSD e das versões mais
> novas
> > > (depois do Vista) do Windows.
> > >
> > > O problema é que muitos servidores operam com o "weak model" e podem
> > criar
> > > assimetria de tráfego, criando problemas com o firewall, por exemplo.
> > >
> > > Minhas perguntas no estilo "TLDR" são:
> > >
> > > 1) Alguém já precisou reconfigurar os servidores para mudar o modo de
> > > operação da pilha TCP?
> > >
> > > 2) Em um ambiente híbrido, com servidores de diversos tipos (Windows
> > 2003,
> > > Windows 2008, Linux OpenSUSE e RedHat, etc.), há como garantir que
> todos
> > os
> > > servidores estejam usando obrigatoriamente o "strong model"? Seria essa
> > uma
> > > recomendação razoável?
> > >
> > > Agora para quem quiser detalhes... seguem mais comentários e
> explicações.
> > >
> > > ==========================================
> > >
> > > OBSERVAÇÃO IMPORTANTE
> > >
> > > O uso do "weak model" ou do "strong model" é uma propriedade da pilha
> TCP
> > > de um sistema operacional, em alguns casos pode ser configurado, mas é
> um
> > > comportamento intrínseco de cada host. A RFC1122 estabelece as
> definições
> > > básicas para IPv4; a RFC3484 trata da extensão para IPv6, que segue
> > > critérios semelhantes; e finalmente, a RFC6419 trata das "práticas
> > atuais"
> > > para cada sistema operacional.
> > >
> > > WEAK MODEL
> > >
> > > Para entender o impacto do "weak model", suponha a configuração:
> > >
> > > - Servidor Linux "genérico" (opera em 'weak mode' por default)
> > > - eth0: 10.0.1.1/24
> > > - eth1: 10.0.2.1/24
> > >
> > > Se o servidor estiver configurado em "weak mode", e um pacote destinado
> > ao
> > > IP 10.0.2.1 chegar na interface eth0, o mesmo será recebido e
> encaminhado
> > > internamente para a interface lógica correta.
> > >
> > > No caso do recebimento de pacotes, este comportamento é necessário em
> > > alguns casos mas deixa o sistema vulnerável, e neste caso pode ser
> > aplicado
> > > um filtro, que é configurado por default em algumas distribuições.
> > >
> > > No caso do envio de pacotes, o "weak model" é mais complicado e pode
> > causar
> > > problemas de tráfego assimétrico. Suponha o seguinte cenário:
> > >
> > > - eth0: 10.0.1.1/24
> > > - eth1: 10.0.2.1/24
> > > - servidor web configurado no endereço da eth1 (10.0.2.1:80)
> > > - duas saídas para a Internet (ex: dois "upstreams" diferentes), um em
> > cada
> > > rede
> > > - rota default para 10.0.1.254 (ou seja, o gateway fica na rede da
> eth0)
> > >
> > > Quando um cliente externo tentar acessar a página web, o servidor
> > > provavelmente receberá os pacotes pela eth1. Porém, assumindo a
> > > configuração default de "weak model", o pacote de resposta será enviado
> > > pela eth0**, criando a assimetria. Essa assimetria nem sempre causa
> > > impacto, mas em certos casos - por exemplo, se houver um firewall
> > stateful
> > > no caminho - irá quebrar as coisas.
> > >
> > > Obs: No caso do Linux, há um flag (SO_BINDTODEVICE) que força o envio
> dos
> > > pacotes pela mesma interface onde o socket foi inicialmente aberto, que
> > > "resolve" o problema. Mas eu não sei qual é a prática para servidores
> Web
> > > hoje em dia, se é que existe uma; e além do mais, esse flag não é
> > suportado
> > > em outros OSs.
> > >
> > > STRONG MODEL
> > >
> > > No "strong model", se repetirmos o mesmo cenário do servidor web
> acima, o
> > > pacote sempre sairá pela interface "certa", mesmo que a rota default
> > esteja
> > > configurada para a interface eth0. Não haverá assimetria de tráfego.
> > >
> > > CONFIGURAÇÕES DEFAULT
> > >
> > > - No Windows server 2003 e XP, o default é weak model.
> > > - No Windows Vista para cima, e no Windows 2008 para cima, o default é
> > > strong model, mas pode ser configurado como weak model.
> > > - No BSD, o default é strong model.
> > > - No Linux, o default é weak model, mas pode ser configurado como
> strong
> > > model (apesar de ser difícil descobrir como :-/)
> > >
> > > *Carlos Ribeiro*
> > > *Sócio*
> > > Cel: +55 (31) 9303-3366
> > > Tel: +55 (31) 3305-5620
> > > Geral: +55 (31) 3305-5600
> > > cribeiro at telbrax.com.br
> > > www.telbrax.com.br
> > > --
> > > gter list    https://eng.registro.br/mailman/listinfo/gter
> > --
> > gter list    https://eng.registro.br/mailman/listinfo/gter
> >
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter
>