[FUG-BR] 3 placas com dois links pppoe

Araujo araujo em iguabanet.com.br
Terça Janeiro 2 17:06:38 BRST 2007


 Pessoal, estou tentando montar uma maquina gateway com uma placa para a
rede interna e dois links externos pppoe para provedores distintos.
Inicialmente uma coisa bem simples, com um nat estático, alguns ips internos
seriam encaminhados ao link1 os restantes ao link2. Mais tarde pretendo
desenvolver um script que teste ambos os links e a situação atual e jogue
todos os ips para um link se outro não estiver funcionando e retorne ao nat
estatico balanceado quando ambos voltarem a funcionar.

 Uso o ppp (segundo entendi da doc o pppd só transaria um link) para cada
link em tempo de "user" (após o boot) assim:

 ppp -ddial link1
 ppp -ddial link2

 Funcionam perfeitamente estabelecendo os dois links com iface tun0 e tun1
respectivamente.

 Se utilizo a opção "nat enable yes" no ppp.conf na seção "default" somente
o link ativado pelo segundo ppp funciona. O primeiro fica ativado, porem
inoperante. Por definição o ultimo ppp chamado chama todo o tráfego para si.
Isto fica claro listando as routes com "netstat -nr". Tambem não há como
dividir o tráfego já que cada ppp chamado desconhece a existência do outro.

 Logo a dedução logica é não utilizar a opção "nat enable yes" no ppp.conf e
usar outro nat, como o ipnat.

 Assim preparei o rc.conf para levantar o ipnat com as regras:

# balanceado

map tun0 200.222.97.194/32 -> 0/32
map tun0 200.222.97.196/32 -> 0/32
map tun0 200.222.97.197/32 -> 0/32
map tun1 200.222.97.198/32 -> 0/32
map tun1 200.222.97.200/32 -> 0/32

 Não estranhem que os ips internos parecem reais, é apenas por razões
históricas, tivemos no passado um link com vários ips reais
disponibilizados, hoje são ips falsos.

 Ocorre que quando o ipnat é levantado, em tempo de "boot" tun0 e tun1 ainda
não existem e a coisa não rola, mesmo depois que executo com sucesso os dois
ppps. Não adianta dar "ipnat -CF -f /etc/ipnat.rules" após os ppps, não rola
mais.

 Conclui que os ppps precisam rodar, e as interfaces tun0 e tun1 passarem a
existir, antes do nat ser levantado.

 assim existiriam duas alternativas:

 a) levantar o nat em tempo de "user", após levantar os dois ppps. Para isso
precisaria existir um software de nat próprio para ser levantado em tempo de
"user". não encontrei no ports. tentei não colocar o ipnat e ipfilter no
rc.conf e depois usando o "lado negro da força" em tempo de "user" após
executar os ppps rodar:

set ipfilter_rules="/etc/ipf.rules"  # o arquivo existe e deixa passar tudo
/etc/rc.d/ipfilter start
set ipnat_rules="/etc/ipnat.rules"  # o arquivo mostrado acima
/etc/rc.d/ipnat start

não rolou.

 b) levantar os ppps em tempo de boot, após o NETWORKING e antes do ipnat,
para isso precisaria, colocar no rc.conf um "pppmeu_enable="YES"", criar no
/etc/rc.d um shell pppmeu levantando os ppps após o NETWORKING e finalmente
fazer com que os "shell" netif e ipnat, ficassem dependentes do pppmeu.

 é minha última alternativa e é isso que não sinto segurança para fazer, já
li o handbook (boot sequence), o man rc e rc.d, o google, mas não senti
firmeza. Alguem conhece algum link bom para orientar sobre isso, ou já fez
isso (seria pedir demais) ? como levantar softwares de usuário no meio do
processo de boot, considerando suas dependencias ?

 araujo




Mais detalhes sobre a lista de discussão freebsd