[GTER] FreeBSD - Roteamento baseado em source address

[Patrick Tracanelli]

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!"