É possível combinar vários canais de internet em um só? Há muitos mal-entendidos e mitos em torno desse tema, até mesmo engenheiros de redes experientes muitas vezes não sabem que isso é possível. Na maioria das vezes, a combinação de canais é erroneamente chamada de balanceamento em nível NAT ou failover. Mas a verdadeira soma permite estabelecer uma única conexão TCP simultaneamente por todos os canais de internet, como em uma transmissão de vídeo, de modo que, caso qualquer um dos canais de internet falhe, a transmissão não seja interrompida.
Existem soluções comerciais caras para transmissões de vídeo, mas esses dispositivos custam milhares de dólares. O artigo descreve a configuração de um pacote gratuito e aberto chamado OpenMPTCPRouter, abordando mitos populares sobre a soma de canais.
Mitos sobre a soma de canais
Existem muitos roteadores domésticos que suportam a função Multi-WAN. Às vezes, os fabricantes chamam isso de soma de canais, o que não é exatamente correto. Muitos profissionais de rede acreditam que além de e soma em nível L2, não existe outra forma de combinação de canais. Já ouvi muitas vezes que isso é impossível, por parte de pessoas que trabalham em telecomunicações. Portanto, vamos tentar esclarecer alguns mitos populares.
Balanceamento em nível de conexões IP
Este é o método mais acessível e popular para utilizar vários canais de internet simultaneamente. Para simplificar, vamos imaginar que você tem três provedores de internet, cada um fornecendo um endereço IP real de sua rede. Todos esses provedores estão conectados a um roteador com suporte para a função Multi-WAN. Isso pode ser OpenWRT com o pacote mwan3, mikrotik, ubiquiti ou qualquer outro roteador doméstico, já que essa opção não é mais rara atualmente.
Para simular a situação, vamos supor que os provedores nos forneceram os seguintes endereços:
WAN1 — 11.11.11.11
WAN2 — 22.22.22.22
WAN2 — 33.33.33.33
Ou seja, conectando-se a um servidor remoto example.com Através de cada um dos provedores, o servidor remoto verá três IPs de origem independentes do cliente. O balanceamento permite dividir a carga entre os canais e utilizar os três simultaneamente. Para simplificar, vamos imaginar que estamos dividindo a carga igualmente entre todos os canais. Assim, quando o cliente abre um site que tem três imagens, ele carrega cada imagem através de um provedor separado. Do lado do site, isso aparece como conexões vindas de três IPs diferentes.
No balanceamento ao nível de conexões, cada conexão TCP é gerida por um provedor separado.
Esse modo de balanceamento frequentemente traz problemas para os usuários. Por exemplo, muitos sites vinculam cookies e tokens rigorosamente ao IP do cliente, e se ele mudar repentinamente, a solicitação é rejeitada ou o cliente é desconectado do site. Isso é frequentemente observado em sistemas de bancos e em outros sites com regras rígidas de sessões de usuários. Aqui está um exemplo simples: arquivos de música no VK.com estão disponíveis apenas com uma chave de sessão válida, que está vinculada ao IP, e os clientes que usam esse tipo de balanceamento muitas vezes não conseguem reproduzir áudio, porque a solicitação foi feita através de um provedor diferente do qual a sessão está vinculada.
Ao baixar torrents, o balanceamento ao nível de conexões soma a largura de banda de todos os canais.
Esse tipo de balanceamento permite a soma da velocidade do canal de internet, quando se usa várias conexões. Por exemplo, se cada um dos três provedores tem uma velocidade de 100 Megabits, ao baixar torrents, obteremos 300 Megabits. Isso acontece porque o torrent abre várias conexões, que são distribuídas entre todos os provedores e, no fim, utilizam completamente o canal.
É importante entender que uma única conexão TCP sempre passará por apenas um provedor. Ou seja, se estivermos baixando um único grande arquivo via HTTP, essa conexão será realizada através de um dos provedores, e se a conexão com esse provedor falhar, o download também será interrompido.
Uma única conexão sempre usará apenas um canal de internet.
Isso também se aplica a transmissões de vídeo. Se você estiver transmitindo vídeo em alguma plataforma como o Twitch, o balanceamento no nível de IP não trará nenhum benefício significativo, uma vez que a transmissão de vídeo será feita por meio de uma única conexão de IP. Nesse caso, se o provedor WAN tiver problemas de conectividade, como perda de pacotes ou redução de velocidade, você não conseguirá mudar instantaneamente para outro provedor. A transmissão precisará ser interrompida e reconectada.
Agregação real de canais
A agregação real de canais permite que uma única conexão seja feita para o Twitch através de todos os provedores, de forma que, se qualquer um dos provedores falhar, a conexão não seja interrompida. Esta é uma tarefa surpreendentemente complexa, que ainda não tem uma solução ideal. Muitas pessoas nem sabem que isso é possível!
Com as ilustrações anteriores, lembramos que um servidor como o Twitch só pode aceitar nosso fluxo de vídeo de um único endereço IP de origem, o que significa que ele deve ser sempre constante, independentemente de quais provedores estão fora de serviço e quais estão operando. Para conseguir isso, precisaremos de um servidor agregador que termine todas as nossas conexões e as combine em uma só.
O servidor agregador agrega todos os canais em um único túnel. Todas as conexões ocorrem a partir do endereço do servidor agregador.
Nesse esquema, todos os provedores são utilizados, e a desconexão de qualquer um deles não causará a interrupção da conexão com o servidor do Twitch. Na verdade, é um tipo especial de túnel VPN, que opera com vários canais de internet ao mesmo tempo. O principal objetivo desse esquema é obter a melhor qualidade possível de conexão. Se um dos provedores começar a ter problemas, como perda de pacotes ou aumento de latência, isso não deve afetar a qualidade da conexão, pois a carga será automaticamente redistribuída por outros canais mais confiáveis disponíveis.
Soluções comerciais
Este problema tem preocupado há muito tempo aqueles que fazem transmissões ao vivo de eventos e não têm acesso a uma internet de qualidade. Para essas situações, existem algumas soluções comerciais, por exemplo, a empresa Teradek fabrica roters robustos nos quais podem ser inseridos vários modems USB:
Roteador para transmissões de vídeo com função de soma de canais
Esses dispositivos geralmente possuem a capacidade de capturar sinais de vídeo via HDMI ou SDI. Junto com o roteador, é vendida uma assinatura do serviço de soma de canais, que também inclui o processamento do fluxo de vídeo, sua recodificação e retransmissão. O preço desses dispositivos começa em 2 mil dólares com um conjunto de modems, além de uma assinatura independente do serviço.
Às vezes, isso parece bastante intimidador:
Configurando o OpenMPTCPRouter
Protocolo (MultiPath TCP) foi criado para possibilitar a conexão simultânea por múltiplos canais. Por exemplo, ele e pode conectar simultaneamente a um servidor remoto via WiFi e através da rede celular. É importante entender que não se trata de duas conexões TCP separadas, mas sim de uma única conexão estabelecida por dois canais. Para que isso funcione, o servidor remoto também deve suportar MPTCP.
é um projeto de roteador de software aberto que permite realmente somar canais. Os autores afirmam que o projeto está em estado alpha, mas já pode ser utilizado. Ele consiste em duas partes: um servidor de soma que é hospedado na internet e o roteador, ao qual se conectam vários provedores de internet e os próprios dispositivos cliente: computadores, telefones. Como roteador do usuário, pode ser um Raspberry Pi, alguns roteadores WiFi ou um computador comum. Há compilações prontas para várias plataformas, o que é muito conveniente.
Princípio de funcionamento do OpenMPTCPRouter
Configuração do servidor de soma
O servidor de soma está hospedado na internet e termina conexões de todos os canais do roteador cliente em uma única conexão. O endereço IP desse servidor será o endereço externo ao acessar a internet através do OpenMPTCPRouter.
Para esta tarefa, usaremos um servidor VPS com Debian 10.
Requisitos para o servidor de soma:
- MPTCP não funciona em virtualização OpenVZ
- Deve haver a possibilidade de instalar um kernel Linux personalizado
O servidor é instalado com a execução de um único comando. O script instalará um kernel com suporte a mptcp e todos os pacotes necessários. Scripts de instalação estão disponíveis para Ubuntu e Debian.
wget -O - http://www.openmptcprouter.com/server/debian10-x86_64.sh | sh
Resultado da instalação bem-sucedida do servidor.
Estamos salvando as senhas; elas nos serão necessárias para configurar o roteador do cliente, e reiniciamos. É importante lembrar que, após a instalação, o SSH estará disponível na porta 65222. Depois da reinicialização, precisamos garantir que iniciamos com o novo kernel.
uname -a
Linux test-server.local 4.19.67-mptcp
Vemos que, ao lado do número da versão, há a inscrição mptcp, o que significa que o kernel foi instalado corretamente.
Configuração do roteador do cliente
Sobre são disponibilizadas compilações prontas para algumas plataformas, como Raspberry Pi, Banana Pi, roteadores Lynksys e máquinas virtuais.
Esta parte do openmptcprouter é baseada no OpenWRT, utilizando a interface LuCI, conhecida por todos que já lidaram com o OpenWRT. A distribuição pesa cerca de 50 MB!
Como bancada de testes, estarei usando um Raspberry Pi e alguns modems USB com diferentes operadoras: MTS e MegaFon. Não acho necessário explicar como gravar a imagem em um cartão SD.
Inicialmente, a porta Ethernet no Raspberry Pi está configurada como lan com um endereço IP estático. 192.168.100.1. Para evitar bagunça com cabos na mesa, conectei o Raspberry Pi ao ponto de acesso WiFi e atribuí um endereço estático ao adaptador WiFi do computador. 192.168.100.2. O servidor DHCP por padrão não está ativado, então precisamos usar endereços estáticos.
Agora podemos acessar a interface web.
Na primeira entrada, o sistema pedirá para definir a senha root; com essa mesma senha, o SSH estará disponível.
Nas configurações de LAN, podemos definir a sub-rede desejada e ativar o servidor DHCP.
Estou usando modems que são reconhecidos como interfaces USB Ethernet com um servidor DHCP separado, portanto, isso exigiu a instalação . O procedimento é idêntico à configuração de modems no OpenWRT comum, então não vou abordar isso aqui.
Em seguida, é necessário configurar as interfaces WAN. Inicialmente, o sistema cria duas interfaces virtuais WAN1 e WAN2. É necessário atribuir um dispositivo físico a elas, no meu caso, são os nomes das interfaces dos modems USB.
Para não confundir os nomes das interfaces, recomendo observar as mensagens do dmesg, conectando-se via SSH.
Como meus modems atuam como roteadores e possuem um servidor DHCP, tive que alterar as configurações de suas faixas internas de rede e desativar o servidor DHCP, pois inicialmente ambos os modems atribuem endereços de uma única rede, o que causa conflito.
OpenMPTCPRouter requer que os endereços das interfaces WAN sejam estáticos, então criamos sub-redes para os modems e configuramos no menu sistema → openmptcprouter → configurações de interface. Aqui também é necessário indicar o endereço IP e a chave do servidor, obtida na etapa de instalação do servidor agregador.
Se a configuração for bem-sucedida, a página de status deve exibir uma imagem semelhante. É possível ver que o roteador conseguiu se conectar ao servidor agregador e ambos os canais estão funcionando normalmente.
O modo padrão utilizado é shadowsocks + mptcp. Este é um proxy que encapsula todas as conexões. Inicialmente, ele está configurado para processar apenas TCP, mas pode-se habilitar também o UDP.
Se não houver erros na página de status, a configuração pode ser considerada concluída.
Com alguns provedores, pode ocorrer uma situação em que a bandeira mptcp na rota do tráfego é cortada, e então aparecerá o seguinte erro:
Nesse caso, é possível utilizar outro modo de operação, sem usar MPTCP. Mais detalhes sobre isso. .
Conclusão
O projeto OpenMPTCPRouter é muito interessante e importante, pois talvez seja a única solução aberta abrangente para o problema de agregação de canais. Todo o resto é ou completamente fechado e proprietário, ou apenas módulos separados, com os quais uma pessoa comum não consegue lidar. Neste estágio de desenvolvimento, o projeto ainda está bastante cru, com documentação extremamente escassa, muitas coisas simplesmente não estão descritas. Mas ainda assim, ele funciona. Espero que continue a se desenvolver e que consigamos roteadores domésticos que consigam agregar canais corretamente desde o início.
Siga nosso desenvolvedor no Instagram
Fonte: habr.com
