[FUGSPBR] roteamento por origem

[Patrick Tracanelli]

> exemplo de uma das maquinas
> 1 - Para os clientes de IP real não vou fazer nada

Isso significa que continuara saindo pela rota padrao, correto?

> 2 - se a origem for 10.1.0.0/16 o default é o link A
> 3 - se a origem for 10.2.0.0/16 o default é o link B

Vamos partir do principio que essa maquina fara NAT? Ou apenas 
encaminhara para o GW do Link A e esse por sua vez se encarrega do NAT?

Note, 2 links, 2 NATD rotando, OK?

natd -f /etc/natd_linkA.conf

No /etc/natd_linkA.conf:

interface <interface_linkA>
same_ports yes
use_sockets yes
punch_fw 00001:99
log_ipfw_denied yes
port 8669

natd -f /etc/natd_linkB.conf

No /etc/natd_linkB.conf:

interface <interface_linkB>
same_ports yes
use_sockets yes
punch_fw 00001:99
log_ipfw_denied yes
port 8668

Note que o daemon do NAT para o Link A esta em uma porta distinta da do 
Link B. Isso se aplicara as regras.

As regras.

...

${fwcmd} add 100 set 1 divert 8669 ip from any to IP_REAL_LOCAL_A in
${fwcmd} add 200 set 1 divert 8669 ip from 10.1.0.0/16 to any out
${fwcmd} add 300 set 1 fwd GATEWAY_A ip from IP_REAL_LOCAL_A to any

${fwcmd} add 400 set 2 divert 8668 ip from any to IP_REAL_LOCAL_B in
${fwcmd} add 500 set 2 divert 8668 ip from 10.2.0.0/16 to any out
${fwcmd} add 600 set 2 fwd GATEWAY_B ip from IP_REAL_LOCAL_B to any

# O restante do seu fireall ou pelo menos (pra testar)
# um allow all from any to any

...

Essas regras podem ser otimizadas definindo de forma explicita as 
interfaces, alem do fluxo (in, out)

Resumindo o segredo da coisa,

1 - Voce tem 2 Links alem do padrao, portanto tera que fazer 2 NAT (1 
por interface).
2 - Voce tem que jogar para o NATD (divert) todos os pacotes vindo de 
qualquer local (voce nao tem como adivinhar) para o seu IP verdadeiro 
(estara destinado ao IP) *ANTES* de qualquer coisa, para o NATD 
verificar se o pacote em questao eh resposta de uma requisicao em sua 
tabela.
3 - Voce tem que jogar para o NATD (divert) todos pacotes cuja origem 
for sua rede falsa para *qualquer* local, com tanto que o pacote esteja 
*saindo* pela interface do link (nao entrando pela interface interna).
Note que, voce soh pode fazer o 3 depois do 2.
4 - Voce tem que fazer proximo-salto, como se fosse um roteador. Vai 
dizer que tudo que for sair da sua maquina com seu IP real do link que 
voce esta tratando, o proximo-salto (next-hop) deve ser o gateway para o 
seu IP.
5 - Voce TEM QUE SABER qual seu IP real no momento do NAT. Ou seja, se 
for dinamico, faca um script que pega o IP na hora de carregar o firewall.

6 - DEVE existir uma rota padrao! Pense que rota padrao vai apenas te 
ajudar. Por exemplo, se voce tem 4 links, soh precisa fazer 
policy-routing para 3. O que vier do quarto voce deixa passar (vai pra 
rota padrao). A rota deve existir NEM que seja falsa, por exemplo 
apontando para um GW que nem esta na rede. Do contrario o ip.forward 
(gateway_enable="YES") nao vai rotear *nada*. Suas regras de firewall 
nao terao o menor efeito.

-----------------------------------------------------------------------

Pra ilustrar, se for uma situacao onde voce nao vai precisar fazer NAT 
na maquina local (por exemplo, policy-routing de IP registrado (IP real) 
ou de IP nao registrado pra nao registrado, basta usar o "fwd" do IPFW.

Por exemplo, temos uma situacao em um cliente que e' empresa de hosting, 
seu webserver tem 3 nics, e os <VirtualHost> sao feitos pelos IPs de 3 
links distintos. O padrao, sai pela rota default, o restante sai assim

${fwcmd} add 50100 set 5 fwd GW_2 ip from IP_2 to not IP_2 out via em1
${fwcmd} add 50200 set 5 fwd GW_3 ip from IP_3 to not IP_3 out via em2

Funciona *perfeito*. Como a maquina nao eh firewall ela soh tem essas 
regras.

Em outra situacao temos em producao balanceamento de carga em um 
ambiente muito parecido com o anterior. Como balancear a carga? Nehum 
segredo obscuro nao documentado, nada que o IPFW nao tenha e nao seja de 
conhecimento de todos...

# ipfw -S sh 5100
05100        842030        197749819 set 5 prob 0.500000 fwd 200.X.Y.Z 
ip from 200.X.Y.K to not 200.X.Y.K out via em0 keep-state

Omiti o IP por motivos obvios (ja que eh de producao hehe). A unica 
diferenca ai eh nosso amigo prob (probability match) que eh de 50%, ou 
seja metade do que sai eh atendido por esse gateway, a outra metade ou 
sai pela rota padrao ou por outra regra de fwd. keep-state esta ai pra 
nao matar sessoes.

Enfim..

O fato e' que policy-routing funciona e muito bem no FreeBSD. Talvez nao 
seja a coisa mais obvia do mundo implementar. Mas funciona e usamos isso 
com certa frequencia. Qualquer duvida mais especifica Eugenio, voce tem 
nosso telefone :D hehe

Mais uma nota, isso se chama policy-routing; source-routing por 
definicao eh outra coisa, que obviamente o FreeBSD tambem suporte; e´ 
controlada pelas seguintes variaveis sysct(8):

(eksffa em code-veronica)~> sysctl -d net.inet.ip.sourceroute 
net.inet.ip.accept_sourceroute
net.inet.ip.sourceroute: Enable forwarding source routed IP packets
net.inet.ip.accept_sourceroute: Enable accepting source routed IP packets

-- 
Atenciosamente,

Patrick Tracanelli

FreeBSD Brasil LTDA.
The FreeBSD pt_BR Documentation Project
http://www.freebsdbrasil.com.br
patrick @ freebsdbrasil.com.br
"Long live Hanin Elias, Kim Deal!"

_______________________________________________________________
Para enviar um novo email para a lista: fugspbr em fugspbr.org
Sair da Lista: http://lists.fugspbr.org/listinfo.cgi
Historico: http://www4.fugspbr.org/lista/html/FUG-BR/