Dois ISPs e configuração de gateway multipath

Question

Eu tenho dois ISPs diferentes. Eu quero definir algum tipo de configuração de balanceamento de carga que irá distribuir pacotes para esses provedores. Eu sei que isso pode ser feito usando tabelas de roteamento diferentes, mas eu queria usar algo chamado "gateway multipath".

Eu configurei as duas interfaces no arquivo /etc/network/interfaces . Ambas as conexões funcionam separadamente. Eu substituí os gateways padrão pelo seguinte:

# ip route add default \
    nexthop via 192.168.1.1 dev bond0 weight 1 \
    nexthop via 10.143.105.17 dev wwan0 weight 1

Eu adicionei os alvos de mascaramento em iptables em ambas as interfaces:

iptables -t nat -A POSTROUTING -o wwan0 -j MASQUERADE
iptables -t nat -A POSTROUTING -o bond0 -j MASQUERADE

Também ativei (parcialmente) a filtragem de caminho reverso via sysctl :

net.ipv4.conf.all.rp_filter = 2
net.ipv4.conf.default.rp_filter = 2

Esta configuração funciona. Pacotes (conexões) são enviados através de ambas as interfaces. Há apenas um problema que não consigo.

Quando quero verificar meu endereço IP usando os seguintes comandos:

$ curl text.whatisyourip.org
$ curl eko.one.pl/host.php

O endereço IP é diferente nos dois casos, o que significa que o mecanismo funciona bem. Também posso ver isso funcionando em wireshark . Mas quando estou tentando enviar, por exemplo, várias solicitações para o primeiro dos domínios acima, sempre recebo o mesmo endereço IP em resposta. Portanto, parece que os pacotes destinados ao endereço IP específico sempre passam pela mesma interface. Eu só estou me perguntando por quê. Existe algum mecanismo que lembre os endereços IP de destino das solicitações anteriores e faça com que as próximas solicitações aos mesmos endereços passem pela mesma interface?

    

Answer 1

Consegui resolver o problema. Em este link , você pode ler o seguinte:

IPv4: Hash-based multipath routing. When the routing cache was removed in 3.6, the IPv4 multipath algorithm changed from more or less being destination-based into being quasi-random per-packet scheduling. This increased the risk of out-of-order packets and made it impossible to use multipath together with anycast services. In this release, the multipath routing implementation is replaced with a flow-based load balancing based on a hash over the source and destination addresses merge commit

Portanto, mesmo que o cache tenha sido removido no kernel 3.6, os pedidos ainda estão sendo armazenados em cache. Agora, os endereços de origem e destino são importantes. É por isso que os pacotes sempre passam pela mesma interface.