[GTER] FreeBSD - Roteamento baseado em source address

Wed Aug 1 21:30:13 -03 2012

Embora só tenha testado no ambiente virtualizado, gostaria de agradecer os
amigos que contribuíram.

Basicamente segui a dica do Patrick, recompilando o kernel com suporte a
múltiplas tabelas de roteamento e no PF usei um regra similar a abaixo:

pass in on $lans from <ipacesso> to any rtable 1

Em 1 de agosto de 2012 15:54, Patrick Tracanelli <
eksffa at freebsdbrasil.com.br> escreveu:

>
> Em 27/07/2012, às 16:08, Patrick Barreto Petronetto escreveu:
>
> > o pf já esta funcionando com varias "tabelas de roteamento". Na
> > verdade você especifica o parâmetro "route-to" dentro de uma regra.
>
> Isso não é multiplas tabelas de roteamento, route-to é PBR FFIB ou seja
> fica na frente (é processado antes) da FIB, interceptando-a.
>
> A opção setfib é mais interessante e também disponível no pf com "rtable"
> como no e-mail anterior :-)
>
> Acho que o route-to ja tava na pauta :D
>
>
>
> >
> > por exemplo:
> > "pass out on em0 from 192.168.1.0/24 to 200.200.200.200 route-to
> 10.0.0.1"
> >
> > traduzindo:
> > o trafego saindo pela interface em0 com origem de 192.168.1.0/24 com
> > destino a 200.200.200.200 vai ser roteado pelo gateway 10.0.0.1
> >
> > 2012/7/27 Lucas Willian Bocchi <lucas.bocchi at gmail.com>
> >
> >> patrick
> >>
> >> O pf novo não está trabalhando já com múltiplas tabelas de rotas?? Se eu
> >> não me engano sim!
> >> Aí você pode fazer a mesma regra para o pf com o ipfw para ignorar uma
> >> classe ou determinado ip, fora que vc pode criar macros!
> >>
> >>
> >>
> >> Em 27 de julho de 2012 14:06, Patrick Tracanelli <
> >> eksffa at freebsdbrasil.com.br> escreveu:
> >>
> >>> Com pf voce usa route-to.
> >>>
> >>> Com ipfw voce usa fwd
> >>>
> >>> Com ipfw voce usa multiplas tabelas de roteamento (idea, recomendado,
> >> mais
> >>> leve, melhor performance, multithread, etc).
> >>>
> >>> Compila seu FreeBSD com options ROUTETABLES=2 (caso queira 2 tabelas de
> >>> roteamento).
> >>>
> >>> Manipula as rotas da segunda tabela com
> >>>
> >>> setfib -1 route add default <ip>
> >>> setfib -1 netstat -rn
> >>> setfib -1 route add -host -iface
> >>> setfib -1 <qq coisa q vc esteja acostumado mas quer na segunda tabela
> de
> >>> roteamento)
> >>>
> >>> Teste com
> >>>
> >>> setfib -1 ping www.bsd.com.br
> >>>
> >>> Esse ping sera pela FIB e não a FIB0 que é a padrão.
> >>>
> >>> Pra selecionar quem voce quer pela FIB1 use
> >>>
> >>> ipfw add setfib 1 all from <origem> to any
> >>>
> >>> Ou seja classifica como quer, ex, Web e SMTP pela FIB1:
> >>>
> >>> ipfw add setfib 1 tcp from <clientes> to any 80,25
> >>>
> >>> E assim por diante...
> >>>
> >>> pf é excelente, mas não escala... creio que ipfw com multiplas FIB
> seja a
> >>> solução mais limpa.
> >>>
> >>>
> >>> Em 27/07/2012, às 12:32, mail gter escreveu:
> >>>
> >>>> Bom tarde amigos,
> >>>>
> >>>> Obrigado pelas dicas.
> >>>>
> >>>> Acredito que estou no caminho certo, pois estava justamente estudando
> a
> >>>> parte de pools do PF.
> >>>>
> >>>> Deixe-me falar um pouco sobre meu caso concreto, quem sabe alguém pode
> >>> ter
> >>>> uma ideia melhor.
> >>>>
> >>>> Vamos fazer a implantação de novo servidor de cache, o qual opera em
> >> modo
> >>>> bridge e em tese é transparente, ou seja, o tráfego HTTP que for
> >>>> encaminhado entre as interfaces da bridge será inspecionado, salvo as
> >>>> exceções.
> >>>>
> >>>> Neste cenário todo tráfego de rede acabará passando pelo hardware de
> >>> cache,
> >>>> inclusive as exceções do cache, as quais não são poucas. Eu gostaria
> >> que
> >>> as
> >>>> exceções não precisassem passar pelo serviço de cache, com objetivo de
> >>>> eliminar essa camada de processamento adicional e desnecessária.
> >>>>
> >>>> Hoje nosso cenário é formado por um segmento de rede, interligando o
> >>> router
> >>>> de borda com o gateway dos usuários. A ideia é criar um novo segmento.
> >>>>
> >>>> O primeiro segmento seria uma conexão exclusiva entre o gateway dos
> >>>> usuários e o router de boarda, com uma sessão OSPF fechada.
> >>>>
> >>>> No segundo segmento colocaríamos o cache, posicionado entre o gateway
> >> dos
> >>>> usuários e o router da borda, fechando outra sessão OSPF.
> >>>>
> >>>> Porém, para que o cache funcione é necessário que tanto o tráfego de
> >>> subida
> >>>> quanto o de descida "atravessem" o servidor de cache, então imaginamos
> >> o
> >>>> seguinte:
> >>>>
> >>>> 1. UPSTREAM: No gateway dos usuários faremos roteamento com base no IP
> >> de
> >>>> origem,  encaminhando para o segmento com cache as classes IPs que
> >> devam
> >>>> usar este serviço;
> >>>>
> >>>> 2. DOWNSTREAM: Como teremos duas sessões OSPF fechadas com o router da
> >>>> borda, faremos anúncios mais específicos através da sessão OSPF
> fechada
> >>>> pelo do segmento no qual o cache está posicionado.
> >>>>
> >>>> Assim consigo eliminar a camada de comutação extra.
> >>>>
> >>>> Essa é minha ideia. Alguma sugestão ?
> >>>>
> >>>> Obrigado.
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> Em 26 de julho de 2012 19:24, Eduardo Schoedler <listas at esds.com.br
> >>>> escreveu:
> >>>>
> >>>>> Em 26 de julho de 2012 11:08, mail gter <mail.gter at gmail.com>
> >> escreveu:
> >>>>>
> >>>>>> Gostaria de realizar um balanceamento de carga entre duas
> interfaces,
> >>>>>> baseado no endereço ip de origem.
> >>>>>>
> >>>>>> No linux utilizaríamos iproute2 e no FreeBSD ?
> >>>>>>
> >>>>>
> >>>>> Pode fazer utilizando tanto o PF quanto o IPFW.
> >>>>> http://www.openbsd.org/faq/pf/pools.html#outgoing
> >>>>> http://www.freebsd.org/doc/en/books/faq/networking.html#IPFW-FWD
> >>>>>
> >>>>>
> >>>>> --
> >>>>> Eduardo Schoedler
> >>>>> --
> >>>>> gter list    https://eng.registro.br/mailman/listinfo/gter
> >>>>>
> >>>> --
> >>>> gter list    https://eng.registro.br/mailman/listinfo/gter
> >>>
> >>> --
> >>> Patrick Tracanelli
> >>>
> >>> FreeBSD Brasil LTDA.
> >>> Tel.: (31) 3516-0800
> >>> 316601 at sip.freebsdbrasil.com.br
> >>> http://www.freebsdbrasil.com.br
> >>> "Long live Hanin Elias, Kim Deal!"
> >>>
> >>> --
> >>> 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
>
> --
> Patrick Tracanelli
>
> FreeBSD Brasil LTDA.
> Tel.: (31) 3516-0800
> 316601 at sip.freebsdbrasil.com.br
> http://www.freebsdbrasil.com.br
> "Long live Hanin Elias, Kim Deal!"
>
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter
>