Atingir o roteamento IP de vários caminhos por pacote no Kernel = 4.4

Question

O Linux Kernel anterior ao 3.6 usava o cache de rota para fazer o roteamento de vários caminhos IPv4, o que significava que o roteamento entre duas linhas / ISPs separados era muito fácil. A partir do 3.6, o algoritmo foi alterado para por pacote, o que significa que alguns truques de tabela de rotas / regras / iptables foram necessários para atingir as duas linhas / ISPs.

No entanto, se você tivesse duas linhas com o mesmo ISP que poderiam rotear um único IP para baixo nas duas linhas por pacote de forma balanceada / failover, então a partir de 3.6 você poderia facilmente obter ligação de linha (no nível IP ) por causa do roteamento por pacote em ambas as direções.

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

Atualmente estou executando o Kernel 4.4.36 e estou usando o roteamento de caminhos múltiplos em conexões PPPoE. Meu tráfego downstream do ISP é roteado através das duas linhas separadas em uma base por pacote (um IP roteado abaixo de ambas as linhas). Isso significa que posso atingir uma velocidade de download mais rápida que a velocidade de uma linha individual. Meu tráfego upstream é roteado de acordo com o algoritmo baseado em fluxo mais recente em ambos os dispositivos ppp (que possuem o mesmo endereço IP). Isso significa que não consigo atingir uma velocidade de upload que seja mais rápida que a velocidade de uma única linha.

Existe uma maneira de configurar o Kernel atual para usar o algoritmo por pacote? Eu precisaria reverter para um Kernel mais antigo (o que não quero fazer por várias outras razões)?

Meu ISP não suporta multi-link ppp.

No caso de ser relevante, estou executando o Arch Linux ARMv7 (em um Raspberry Pi 3), mas posso mudar para o Raspian, se necessário.

    

Answer 1

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

link

Foi assim que consegui trabalhar 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 são executados na inicialização, supondo que você queira NAT de uma rede local em eth0.

sysctl -w net.ipv4.ip_forward
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 aparecem:

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

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.1 é 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 por pppoe etc.). O link teql é atribuído manualmente como mostrado acima. O ISP precisa enviar tráfego para o IP igualmente em ambos os links.

O caminho reverso ( rp_filter ) é definido como 2 (solto), ambos no script acima, para que os pacotes de retorno não sejam eliminados devido a eles voltarem às interfaces ppp em vez de teql0.

Eu configurei tudo dessa maneira e funciona perfeitamente. Muito fácil! Quando os links falham, há failover contínuo. Quando eles chegam, eles apenas começam a trabalhar novamente. Parece que não há perda ou atraso do pacote quando ele falha, e nenhum quando ele volta.

Além disso, outra forma no link abaixo usa o roteamento de políticas, com o iptables para marcar todos os outros pacotes, mas tentarei em alguns dias verificar se funciona melhor do que o acima e fornecer feedback aqui de acordo.

link