Como obter o roteamento de caminhos múltiplos por pacote no Linux?

O Linux Kernel anterior à 3.6 usava o cache de rota para fazer o roteamento de caminhos múltiplos IPv4, o que significava que o roteamento entre duas linhas / ISPs separadas era bastante fácil. De 3.6, o algoritmo mudou para ser por pacote, o que significa que alguns truques de marcador de tabela de rotas / regra / iptables foram necessários para atingir as duas linhas / ISPs.

No entanto, se você tivesse duas linhas com o mesmo provedor de serviços de Internet que poderiam rotear um único IP nas duas linhas por pacote de maneira balanceada / failover, a partir da 3.6, seria possível obter facilmente ligação de linha (no nível IP) por causa de o roteamento por pacote nas duas direções.

Da 4.4, o kernel mudou novamente para o balanceamento de carga baseado em fluxo com base em um hash nos endereços de origem e destino.

Atualmente, estou executando o Kernel 4.4.36 e estou usando roteamento de caminhos múltiplos em conexões PPPoE. Meu tráfego downstream do ISP é roteado pelas duas linhas separadas por pacote (um IP roteado nas duas linhas). Isso me dá uma velocidade de download mais rápida que a velocidade de uma linha individual. Quase a velocidade de ambas as linhas somadas. Funciona muito bem, vídeo do Skype, VoIP (UDP), YouTube etc. tudo funciona muito bem.

Por ter uma experiência tão boa no downstream, quero experimentá-lo upstream, mas meu tráfego upstream é roteado de acordo com o algoritmo baseado em fluxo mais recente nos dois dispositivos ppp (que têm o mesmo endereço IP). Isso significa que não consigo atingir uma velocidade de upload superior à velocidade de uma única linha.

Existe uma maneira de configurar o Kernel atual para usar o algoritmo por pacote? Ou algum outro método para obter o roteamento de caminhos múltiplos por pacote? Eu precisaria reverter para um Kernel mais antigo (o que não quero fazer por vários outros motivos)?

Meu provedor de serviços de Internet não oferece suporte a ppp com vários links.

Caso seja relevante, atualmente estou executando o Arch Linux ARMv7 em um Raspberry Pi 3.

— bao7uo
fonte

Esta é uma péssima ideia. O balanceamento por pacote em L2 (ou seja, MLPPP) inclui lógica suficiente para remontar os pacotes em ordem. A execução desse IP deixa em aberto uma tremenda oportunidade (se não quase certa) de entrega fora de ordem. Isso causará um grande número de problemas com sessões TCP lentas, UDP totalmente interrompido, problemas com qualquer tipo de streaming em tempo real etc. A outra questão é que, mesmo se você estiver enviando pacotes round-robin para o seu ISP, haverá absolutamente nenhuma sugestão de que eles se equilibrarão da mesma forma em relação a você.

— Rnxrx

@rnxrx obrigado pelo seu comentário - editei a pergunta para fornecer detalhes adicionais. Da minha pergunta: "o tráfego downstream do ISP é roteado pelas duas linhas separadas por pacote". O provedor de serviços de Internet fornece um painel de controle - quando eu escolho um IP a ser roteado nas duas linhas, eles o encaminham perfeitamente round-robin equilibrado por pacote. Funciona bem, com cerca de 90% do total de velocidades de ambas as linhas somadas e fornece failover instantâneo. Vídeo Skype, chamadas VoIP, YouTube, BBC de streaming etc. Todos grande -, uma grande experiência jusante me faz querer tentar a montante

— bao7uo

Ahh - entendi ... Então, atualmente, você tem dois IPs únicos (um por conexão) ou eles estão roteando para um único IP (ou uma sub-rede) do seu lado através de dois caminhos paralelos? Se você estiver executando qualquer tipo de NAT, é obviamente crucial que ocorra antes desse equilíbrio. De qualquer forma - você já deu uma olhada em support.aa.net.uk/… ? Ele está usando extensões iptables para realizar basicamente o que você está descrevendo e, como tal, deve ser bastante consistente nas versões razoavelmente modernas do kernel.

— Rnxrx

Obrigado @rnxrx - sim, posso fazer qualquer opção (dois IPs únicos ou um único IP através dos caminhos paralelos). Eu preferi a opção de IP único, pois parecia fazer mais sentido.

— bao7uo

Ok, então, depois de ter tido mais tempo para investigar isso, encontrei uma maneira de fazer isso usando o Linux TEQL (True Link Equalizer). Aqui está um link que eu segui livremente, mas com alguns ajustes.

http://lartc.org/howto/lartc.loadshare.html

Foi assim que o fiz funcionar no Arch Linux ARMv7 (Raspberry Pi 3)

Na inicialização:

O comando a seguir deve ser executado na inicialização para carregar o módulo Kernel apropriado.

modprobe sch_teql

Os seguintes comandos também devem ser executados na inicialização, desde que você deseje NAT a partir de uma rede local em eth0.

sysctl -w net.ipv4.ip_forward=1
iptables -A INPUT -i ppp+ -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -i ppp+ -o eth0 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -A POSTROUTING -t nat -o teql+ -j MASQUERADE

O tráfego de retorno FORWARD está no ppp + e o POSTROUTING MASQUERADE no teql + porque o tráfego de saída sai no teql e o tráfego de retorno volta no ppp.

Quando os links ppp aparecerem:

Supondo que os links tenham balanceamento de carga são ppp, os seguintes comandos devem ser executados em um script em um /etc/ppp/ip-up.d/script.

sysctl -w net.ipv4.conf.ppp1.rp_filter=2
sysctl -w net.ipv4.conf.ppp2.rp_filter=2
tc qdisc add dev ppp1 root teql0
tc qdisc add dev ppp2 root teql0
ip address add 1.1.1.1/32 dev teql0
# you can add additional public IP addresses teql0 if you need to
ip link set teql0 up
ip route replace default scope global dev teql0

Onde 1.1.1.1está o seu endereço IP público voltado para o ISP. IPs públicos adicionais podem ser atribuídos ao dispositivo teql0, mas não precisam ser atribuídos aos dispositivos ppp. Na minha configuração, os dois links ppp compartilham o mesmo IP (negociado pela pppoe etc.) O link teql é atribuído manualmente, como mostrado acima. O ISP precisa enviar o tráfego para o IP igualmente nos dois links.

O caminho reverso ( rp_filter) é definido como 2(solto), tanto no script acima, para que os pacotes de retorno não sejam descartados devido ao retorno das interfaces ppp ao invés de teql0.

Eu configurei dessa maneira e funciona perfeitamente. Muito fácil! Quando os links falham, há failover contínuo. Quando eles aparecem, eles simplesmente começam a trabalhar novamente. Parece que não há perda ou atraso de pacote quando ocorre failover e nenhum quando ele retorna.

Além disso, um dos comentaristas sugeriu o link abaixo, que usa o roteamento de políticas, com o iptables para marcar todos os outros pacotes, etc.

http://support.aa.net.uk/Router_-_Linux_upload_bonding_using_policy_routing

— bao7uo
fonte

Eu nunca tentei o roteamento de políticas porque o TEQL funcionou tão bem. Se não está quebrado ....

— bao7uo

Estou tentando fazer isso funcionar. Eu tenho a ligação funcionando, posso usar a interface ligada do roteador. Eu não posso obter o trabalho NAT, porém, o tráfego de minha LAN não está indo para baixo o link ligado :(

— andynormancx

se você postar uma nova pergunta sobre falha do servidor e vincular a ela a partir de um comentário, tentarei descobrir isso por você. incluir o máximo de informações possível, como interface / configuração de ip, tabela de roteamento, regras de tabelas de ip etc., a menos que você possa caber todas as informações aqui nos comentários?

— 27518 bao7uo

PS. só notei um erro na minha configuração. disse, sysctl -w net.ipv4.ip_forwardmas devo dizer sysctl -w net.ipv4.ip_forward=1que eu corrigi acima. Isso certamente impediria o tráfego da LAN descendo pelo link vinculado.

— 27418 bao7uo

Eu não acho que foi isso que parou de funcionar para mim, eu tinha o encaminhamento ativado no sysctl. Agora estou tentando descobrir se é esperado o grande número de pacotes fora de ordem que estou vendo.

— andynormancx