Olá Noilson, obrigado por me responder!
Fui atrás da sua dica (iptables -A POSTROUTING -t mangle -j CONNMARK
--save-mark) e pesquisei sobre "CONNMARK" e "mark", mas para ser sincero
acabei ficando com mais dúvidas.
Nesta parte do meu script onde trato os pacotes marcados:
iptables -I PREROUTING -t mangle -i $placa_rede_interna -s $rede_interna
-d 0/0 -p tcp -m multiport --dports 110,23,25,465,587 -j MARK --set-mark
0x10
iptables -I PREROUTING -t mangle -i $placa_rede_interna -s $rede_interna
-d 0/0 -p tcp -m multiport --dports 80,443 -j MARK --set-mark 0x20
Como ficaria com a sua sugestão? Seria algo neste sentido:
*iptables -A PREROUTING -t mangle -j CONNMARK --restore-mark << Nesta
posição?*
iptables -I PREROUTING -t mangle -i $placa_rede_interna -s $rede_interna
-d 0/0 -p tcp -m multiport --dports 110,23,25,465,587 -j MARK --set-mark
0x10
iptables -I PREROUTING -t mangle -i $placa_rede_interna -s $rede_interna
-d 0/0 -p tcp -m multiport --dports 80,443 -j MARK --set-mark 0x20
*iptables -A POSTROUTING -t mangle -j CONNMARK --save-mark**<< Nesta
posição?*
Em 28-07-2016 08:36, Noilson Caio escreveu:
Jurgen, beleza ? As métricas de rede/roteamento depois que saem de sua
caixa, saem de seu controle. Da origem até sua caixa, mesma coisa. =]
. Só para alinhar o pensamento.
Tem um macete com o alvo CONNMARK que armazena a marcação associada
com a conexão, que parece ser um ou uns dos seus problemas =]
iptables -A POSTROUTING -t mangle -j CONNMARK --save-mark
2016-07-27 14:13 GMT-03:00 Keppler <[email protected]
<mailto:[email protected]>>:
Ola pessoal, tudo bem?
Implementei um Load Balancing, que ainda está em ambiente de
testes, e aparentemente está funcionando OK.
O que notei é que após implementar o Load Balancing, o desempenho
da internet parece ter caído.
Vou explicar melhor:
Quanto compartilho a conexão, da forma como normalmente se faz
usando somente um link (com somente 1 Gateway), quando dou um
"ping" de alguma estação Windows qualquer, o ping corre "lisinho".
Por exemplo vejam a saída do comando abaixo:
Resposta de 200.147.67.142 <http://200.147.67.142>: bytes=32
tempo=9ms TTL=242
Resposta de 200.147.67.142 <http://200.147.67.142>: bytes=32
tempo=10ms TTL=242
Resposta de 200.147.67.142 <http://200.147.67.142>: bytes=32
tempo=8ms TTL=242
Resposta de 200.147.67.142 <http://200.147.67.142>: bytes=32
tempo=9ms TTL=242
Resposta de 200.147.67.142 <http://200.147.67.142>: bytes=32
tempo=9ms TTL=242
Resposta de 200.147.67.142 <http://200.147.67.142>: bytes=32
tempo=10ms TTL=242
Resposta de 200.147.67.142 <http://200.147.67.142>: bytes=32
tempo=9ms TTL=242
Resposta de 200.147.67.142 <http://200.147.67.142>: bytes=32
tempo=10ms TTL=242
Resposta de 200.147.67.142 <http://200.147.67.142>: bytes=32
tempo=9ms TTL=242
Resposta de 200.147.67.142 <http://200.147.67.142>: bytes=32
tempo=9ms TTL=242
Resposta de 200.147.67.142 <http://200.147.67.142>: bytes=32
tempo=9ms TTL=242
E também quando uso o comando "tracert" para verificar as rotas e
por qual roteador estão saindo os pacotes, noto que os saltos
entre os roteadores no caminho ocorrem bem mais rápido do que
quanto o Load Balancing está ativo.
Já quando ativo o Load Balancing (ativando as tabelas de
roteamento em "/etc/iproute2/rt_table" para os 2 links e ativando
as regras), quando dou o mesmo comando "ping" de alguma estação
Windows, noto que o retorno do comando ping parece ficar mais
lento o tempo de retorno dos pacotes também ficam mais lentos.
Vejam abaixo a saída do comando ping (em uma estação Windows) após
ativar o Load Balancing:
Resposta de 200.221.2.45 <http://200.221.2.45>: bytes=32 tempo=9ms
TTL=52
Resposta de 200.221.2.45 <http://200.221.2.45>: bytes=32 tempo=9ms
TTL=52
Esgotado o tempo limite do pedido.
Resposta de 200.221.2.45 <http://200.221.2.45>: bytes=32 tempo=9ms
TTL=52
Resposta de 200.221.2.45 <http://200.221.2.45>: bytes=32 tempo=9ms
TTL=52
Esgotado o tempo limite do pedido.
Resposta de 200.221.2.45 <http://200.221.2.45>: bytes=32 tempo=9ms
TTL=52
Resposta de 200.221.2.45 <http://200.221.2.45>: bytes=32 tempo=8ms
TTL=52
Esgotado o tempo limite do pedido.
Resposta de 200.221.2.45 <http://200.221.2.45>: bytes=32 tempo=9ms
TTL=52
Resposta de 200.221.2.45 <http://200.221.2.45>: bytes=32
tempo=20ms TTL=52
Resposta de 200.221.2.45 <http://200.221.2.45>: bytes=32
tempo=30ms TTL=52
Resposta de 200.221.2.45 <http://200.221.2.45>: bytes=32 tempo=9ms
TTL=52
Esgotado o tempo limite do pedido.
Resposta de 200.221.2.45 <http://200.221.2.45>: bytes=32
tempo=10ms TTL=52
Resposta de 200.221.2.45 <http://200.221.2.45>: bytes=32 tempo=9ms
TTL=52
Resposta de 200.221.2.45 <http://200.221.2.45>: bytes=32 tempo=9ms
TTL=52
Resposta de 200.221.2.45 <http://200.221.2.45>: bytes=32 tempo=9ms
TTL=52
Resposta de 200.221.2.45 <http://200.221.2.45>: bytes=32 tempo=9ms
TTL=52
Resposta de 200.221.2.45 <http://200.221.2.45>: bytes=32 tempo=9ms
TTL=52
Esgotado o tempo limite do pedido.
E agora, se no prompt do Windows eu digitar o comando "tracert
www.uol.com.br <http://www.uol.com.br>", observo que os saltos dos
pacotes entre os roteadores pelo caminho percorrido se tornam mais
lendo para retornar.
Abaixo segue a configuração que estou usando para fazer o Load
Balancing:
# Dados da interfaces de rede conectadas com a internet - Link 1
placa_rede_1=eth1
tabela_1=nome_tabela_1
gateway_1=192.168.100.254
#peso_balanceamento_link_1=30
peso_balanceamento_link_1=10
# Dados da interfaces de rede conectadas com a internet - Link 2
placa_rede_2=eth2
tabela_2=nome_tabela_2
gateway_2=192.168.200.254
#peso_balanceamento_link_2=70
peso_balanceamento_link_2=10
# Dados da Rede Interna
placa_rede_interna=eth0
rede_interna=192.168.50.0/24 <http://192.168.50.0/24>
### Fim das Variáveis
#Carregar Modulos
echo "Carregando Modulos"
modprobe iptable_nat
modprobe ip_nat_ftp
modprobe ipt_MARK
echo 1 > /proc/sys/net/ipv4/tcp_syncookies
echo 1 > /proc/sys/net/ipv4/ip_forward
echo 1 > /proc/sys/net/ipv4/ip_dynaddr
# Zero (0) para desativado e (1) para ativado
echo "1" > /proc/sys/net/ipv4/conf/default/rp_filter
echo "1" > /proc/sys/net/ipv4/conf/all/rp_filter
# Deletar a rota default
echo "Deletando Rota Default"
ip route del default
# Limpa as regras das tabelas
echo "Limpando Regras das Tabelas"
ip route flush table $tabela_1
ip route flush table $tabela_2
# Define a rota para as tabelas
echo "Definindo as Rotas para as Tabelas"
ip route add default dev $placa_rede_1 via $gateway_1 table $tabela_1
ip route add default dev $placa_rede_2 via $gateway_2 table $tabela_2
# Define as regras para balanceamento dos links
ip route add default scope global nexthop via $gateway_1 dev
$placa_rede_1 weight $peso_balanceamento_link_1 nexthop via
$gateway_2 dev $placa_rede_2 weight $peso_balanceamento_link_2
## Regras
echo "Definindo as Marcas dos para o Kernel"
ip rule add fwmark 0x10 lookup $tabela_1 prio 3
ip rule add fwmark 0x20 lookup $tabela_2 prio 3
# Aplicar as regras
echo "Aplicando as Regras"
ip route flush cache
# Compartilha a conexãi
echo "Compartilhando a Conexao atravez das Interfaces de Rede"
iptables -t nat -A POSTROUTING -o $placa_rede_1 -j MASQUERADE
iptables -t nat -A POSTROUTING -o $placa_rede_2 -j MASQUERADE
echo "Definindo quais pacotes saem por qual link"
iptables -I PREROUTING -t mangle -i $placa_rede_interna -s
$rede_interna -d 0/0 -p tcp -m multiport --dports
110,23,25,465,587 -j MARK --set-mark 0x10
iptables -I PREROUTING -t mangle -i $placa_rede_interna -s
$rede_interna -d 0/0 -p tcp -m multiport --dports 80,443 -j MARK
--set-mark 0x20
Enfim, me dúvida é se posso melhor o desempenho deste Loading
Balancing ???
Ou quando usa-se um Loading Balancing, perde-se um pouco do
desempenho quando se está roteando os pacotes por entre os Gateways?
Ou, no caso do meu Script, se vocês observarem estou marcando
determinados pacotes para saírem por um Gateway específico, ou
seja, no meu exemplo que a "navegação comum" (portas 80 e 443)
utilize o Gateway 2 (que é o Link 2). Em outras palavras, marcar
pacotes para depois redirecioná-los para gateways específicos
prejudicam o desempenho/fluxo das entradas e saídas dos pacotes?
Espero ter sido claro!
Alguém já passou por isso? Dá para melhorar?
abraço,
Jurgen
--
GUS-BR - Grupo de Usuários de Slackware Brasil
http://www.slackwarebrasil.org/
http://groups.google.com/group/slack-users-br
Antes de perguntar:
http://www.vivaolinux.com.br/artigo/Como-elaborar-perguntas-para-listas-de-discussao
Para sair da lista envie um e-mail para:
[email protected]
<mailto:slack-users-br%[email protected]>
--- Você está recebendo esta mensagem porque se inscreveu no grupo
"Slackware Users Group - Brazil" dos Grupos do Google.
Para cancelar inscrição nesse grupo e parar de receber e-mails
dele, envie um e-mail para
[email protected]
<mailto:slack-users-br%[email protected]>.
Para obter mais opções, acesse https://groups.google.com/d/optout.
--
Noilson Caio Teixeira de Araújo
https://ncaio.wordpress.com
https://br.linkedin.com/in/ncaio
https://twitter.com/noilsoncaio
https://jammer4.wordpress.com/
http://8bit.academy
--
GUS-BR - Grupo de Usuários de Slackware Brasil
http://www.slackwarebrasil.org/
http://groups.google.com/group/slack-users-br
Antes de perguntar:
http://www.vivaolinux.com.br/artigo/Como-elaborar-perguntas-para-listas-de-discussao
Para sair da lista envie um e-mail para:
[email protected]
---
Você recebeu essa mensagem porque está inscrito no grupo "Slackware
Users Group - Brazil" dos Grupos do Google.
Para cancelar inscrição nesse grupo e parar de receber e-mails dele,
envie um e-mail para [email protected]
<mailto:[email protected]>.
Para mais opções, acesse https://groups.google.com/d/optout.
--
GUS-BR - Grupo de Usuários de Slackware Brasil
http://www.slackwarebrasil.org/
http://groups.google.com/group/slack-users-br
Antes de perguntar:
http://www.vivaolinux.com.br/artigo/Como-elaborar-perguntas-para-listas-de-discussao
Para sair da lista envie um e-mail para:
[email protected]
---
Você está recebendo esta mensagem porque se inscreveu no grupo "Slackware Users Group - Brazil" dos Grupos do Google.
Para cancelar inscrição nesse grupo e parar de receber e-mails dele, envie um
e-mail para [email protected].
Para obter mais opções, acesse https://groups.google.com/d/optout.
