
È possibile unire più canali internet in uno solo? Ci sono molte convinzioni errate e miti su questo tema, persino gli ingegneri di rete esperti spesso non sono a conoscenza che ciò sia possibile. Nella maggior parte dei casi, quello che viene erroneamente definito unione dei canali è in realtà il bilanciamento a livello NAT o il failover. Ma la vera somma permette di stabilire un'unica connessione TCP simultaneamente su tutti i canali internet, ad esempio per una trasmissione video, in modo che l'emissione non venga interrotta in caso di interruzione di uno qualsiasi dei canali internet.
Esistono soluzioni commerciali costose per le trasmissioni video, ma tali dispositivi costano migliaia di euro. In questo articolo viene descritta la configurazione di un pacchetto open source gratuito chiamato OpenMPTCPRouter e si esaminano i miti popolari sull'unione dei canali.
Miti sull'unione dei canali
Ci sono molti router domestici che supportano la funzione Multi-WAN. Talvolta i produttori la chiamano unione dei canali, il che non è del tutto corretto. Molti tecnici di rete credono che, oltre a e all'unione a livello L2, non esista alcun altro tipo di unione dei canali. Ho spesso sentito dire da persone che lavorano nelle telecomunicazioni che ciò è impossibile. Cerchiamo quindi di fare chiarezza sui miti più comuni.
Bilanciamento a livello di connessioni IP
Questo è il modo più accessibile e popolare per utilizzare più canali internet contemporaneamente. Per semplificare, immaginiamo di avere tre fornitori internet, ognuno dei quali ci fornisce un indirizzo IP reale dalla propria rete. Tutti questi fornitori sono collegati a un router che supporta la funzione Multi-WAN. Potrebbe essere OpenWRT con il pacchetto mwan3, Mikrotik, Ubiquiti o qualsiasi altro router domestico, poiché oggi tale opzione non è più rara.
Per simulare la situazione, immaginiamo che i fornitori ci abbiano fornito i seguenti indirizzi:
WAN1 — 11.11.11.11
WAN2 — 22.22.22.22
WAN3 — 33.33.33.33
Cioè, collegandosi a un server remoto example.com Attraverso ciascun fornitore, il server remoto vedrà tre IP sorgente indipendenti del cliente. Il bilanciamento consente di distribuire il carico tra i canali e di utilizzare tutti e tre contemporaneamente. Per semplicità, immaginiamo di distribuire il carico in modo uniforme tra tutti i canali. Di conseguenza, quando il cliente apre un sito che ha, ad esempio, tre immagini, carica ciascuna immagine attraverso un fornitore diverso. Sul lato del sito, questo appare come connessioni da tre IP diversi.

Con il bilanciamento a livello di connessioni, ogni connessione TCP passa attraverso un fornitore diverso.
Questo tipo di bilanciamento spesso comporta problemi per gli utenti. Ad esempio, molti siti collegano rigidamente i cookie e i token all'indirizzo IP del cliente, e se questo cambia improvvisamente, la richiesta viene scartata o il cliente viene disconnesso dal sito. Questo si verifica frequentemente nei sistemi di home banking e su altri siti con regole rigorose sulle sessioni utente. Ecco un semplice esempio: i file musicali su VK.com sono accessibili solo con una chiave di sessione valida, che è legata all'IP, e i clienti che utilizzano questo tipo di bilanciamento spesso non riescono a riprodurre audio, perché la richiesta è stata effettuata tramite un fornitore diverso da quello al quale è legata la sessione.

Durante il download di torrent, il bilanciamento a livello di connessioni somma la larghezza di banda di tutti i canali.
Questo bilanciamento consente di ottenere una somma della velocità del canale Internet, utilizzando numerose connessioni. Ad esempio, se ciascuno dei tre fornitori ha una velocità di 100 Megabit, durante il download dei torrent otteniamo 300 Megabit. Questo perché il torrent apre numerose connessioni, che vengono distribuite tra tutti i fornitori e alla fine sfruttano l'intero canale.
È importante comprendere che una singola connessione TCP passerà sempre attraverso un solo fornitore. Cioè, se stiamo scaricando un grande file tramite HTTP, questa connessione sarà eseguita tramite uno dei fornitori, e se la connessione con questo fornitore viene interrotta, anche il download si interromperà.

Una connessione utilizzerà sempre solo un canale Internet.
Questo è vero anche per le trasmissioni video. Se trasmetti streaming video su una piattaforma tipo Twitch, l'equilibratura a livello di connessioni IP non apporterà alcun vantaggio particolare, poiché il flusso video verrà trasmesso all'interno di una singola connessione IP. In questo caso, se il provider WAN 3 inizia a riscontrare problemi di connessione, come perdita di pacchetti o riduzione della velocità, non sarà possibile passare immediatamente a un altro provider. Dovrai fermare la trasmissione e riconnetterti da zero.
Somma dei canali effettiva
La somma effettiva dei canali consente di instradare una connessione verso un ipotetico Twitch attraverso tutti i provider contemporaneamente, in modo tale che, se uno dei provider dovesse guastarsi, la connessione non si interrompa. Si tratta di un compito sorprendentemente complesso, che ancora non ha una soluzione ottimale. Molti non sanno nemmeno che sia possibile!
Dalle illustrazioni precedenti, ricordiamo che un server Twitch ipotetico può ricevere il nostro flusso video solo da un singolo indirizzo IP sorgente, il che significa che deve rimanere sempre costante, indipendentemente da quali provider siano andati offline e quali siano attivi. Per raggiungere questo obiettivo, avremo bisogno di un server aggregatore, che terminerà tutte le nostre connessioni e le unirà in una sola.

Il server aggregatore aggrega tutti i canali in un unico tunnel. Tutte le connessioni avvengono dall'indirizzo del server aggregatore.
In questo schema vengono utilizzati tutti i provider e la disconnessione di uno di essi non causerà l'interruzione della connessione con il server Twitch. In sostanza, si tratta di un particolare tunnel VPN, sotto il quale ci sono immediatamente diversi canali Internet. L'obiettivo principale di questo schema è ottenere il canale di comunicazione di massima qualità. Se uno dei provider inizia a riscontrare problemi, perdita di pacchetti o aumento della latenza, ciò non dovrebbe riflettersi sulla qualità della connessione, poiché il carico verrà automaticamente distribuito su altri canali di maggiore qualità disponibili.
Soluzioni commerciali
Questo problema preoccupa da tempo chi svolge dirette di eventi e non ha accesso a Internet di qualità. Per tali esigenze esistono diverse soluzioni commerciali, ad esempio l'azienda Teradek produce router mostruosi in cui possono essere inseriti pacchi di modem USB:

Router per trasmissioni video con funzione di somma dei canali
In questi dispositivi, solitamente, è integrata la possibilità di acquisire segnali video tramite HDMI o SDI. Insieme al router viene venduta un'abbonamento al servizio di somma dei canali, nonché di elaborazione del flusso video, ricodifica e rilancio successivo. Il prezzo di tali dispositivi parte da 2k$ con un pacchetto di modem, più un abbonamento separato al servizio.
A volte appare piuttosto intimidatorio:

Configuriamo OpenMPTCPRouter
Protocollo (MultiPath TCP) è stato inventato per la possibilità di connettersi simultaneamente attraverso più canali. Ad esempio, esso e può connettersi contemporaneamente a un server remoto via WiFi e attraverso una rete mobile. È importante capire che non si tratta di due diverse connessioni TCP, ma di una sola connessione stabilita su entrambi i canali. Per fare questo, il server remoto deve supportare MPTCP anche.
è un progetto di router software open source, che consente di sommare realmente i canali. Gli autori dichiarano che il progetto è in fase alpha, ma è già utilizzabile. È composto da due parti: un server di somma, che si trova su Internet e un router, a cui si collegano diversi fornitori di servizi Internet e i dispositivi client stessi: computer e telefoni. Un Raspberry Pi, alcuni router WiFi o un normale computer possono fungere da router utente. Sono disponibili versioni pronte per diverse piattaforme, il che è molto comodo.

Principio di funzionamento di OpenMPTCPRouter
Configurazione del server di somma
Il server di somma si trova su Internet e termina le connessioni di tutti i canali del router client in una sola. L'indirizzo IP di questo server sarà l'indirizzo esterno quando si esce su Internet attraverso OpenMPTCPRouter.
Per questa operazione utilizzeremo un server VPS su Debian 10.
Requisiti per il server di somma:
- MPTCP non funziona su virtualizzazione OpenVZ
- Deve esserci la possibilità di installare un proprio kernel Linux
Il server si distribuisce eseguendo un comando unico. Lo script installerà un kernel con supporto mptcp e tutti i pacchetti necessari. Sono disponibili script di installazione per Ubuntu e Debian.
wget -O - http://www.openmptcprouter.com/server/debian10-x86_64.sh | sh
Risultato di un'installazione riuscita del server.

Salviamo le password, ci serviranno per configurare il router client e riavviamo. È importante tenere a mente che, dopo l'installazione, SSH sarà disponibile sulla porta 65222. Dopo il riavvio, bisogna assicurarsi di essere avviati con il nuovo kernel
uname -a
Linux test-server.local 4.19.67-mptcp
Vediamo accanto al numero di versione la scritta mptcp, il che significa che il kernel è stato installato correttamente.
Configurazione del router client
A sono disponibili build già pronte per alcune piattaforme, come Raspberry Pi, Banana Pi, router Lynksys e macchine virtuali.
Questa parte di openmptcprouter è basata su OpenWRT, e utilizza LuCI come interfaccia, familiare a chiunque abbia mai avuto a che fare con OpenWRT. La distribuzione pesa circa 50MB!

Come banco di prova utilizzerò un Raspberry Pi e alcuni modem USB con operatori diversi: MTS e Megafon. Non credo sia necessario spiegare come scrivere un'immagine su una scheda SD.
Inizialmente la porta Ethernet del Raspberry Pi è configurata come lan con un indirizzo IP statico 192.168.100.1. Per non avere fili in giro sulla scrivania, ho collegato il Raspberry Pi a un punto di accesso WiFi e impostato un indirizzo statico sull'adattatore WiFi del computer 192.168.100.2. Il server DHCP è disattivato di default, quindi bisogna utilizzare indirizzi statici.
Ora è possibile accedere all'interfaccia web
Al primo accesso, il sistema chiederà di impostare la password di root, con la stessa password si potrà accedere a SSH.

Nelle impostazioni LAN è possibile definire la subnet desiderata e attivare il server DHCP.
Utilizzo modem che sono riconosciuti come interfacce USB Ethernet con un server DHCP separato, quindi ciò ha richiesto l'installazione di . La procedura è identica a quella di configurazione dei modem in un normale OpenWRT, quindi non la esaminerò qui.
Dopo bisogna configurare le interfacce WAN. Inizialmente, nel sistema sono stati creati due interfacce virtuali WAN1 e WAN2. Loro devono essere assegnati a dispositivi fisici, nel mio caso i nomi delle interfacce dei modem USB.
Per non confondermi con i nomi delle interfacce, consiglio di controllare i messaggi dmesg, collegandomi tramite SSH.
Poiché i miei modem fungono da router e hanno già un server DHCP, ho dovuto modificare le impostazioni dei loro intervalli interni e disattivare il server DHCP, poiché inizialmente entrambi i modem assegnano indirizzi dalla stessa rete, provocando un conflitto.
OpenMPTCPRouter richiede che gli indirizzi degli interfaccia WAN siano statici, quindi assegnamo ai modem delle sottoreti e configuriamo nel menu system → openmptcprouter → interface settings. Qui è necessario indicare l'indirizzo IP e la chiave del server, ottenuta durante la fase di installazione del server aggregato.

Se la configurazione è riuscita, nella pagina di stato dovrebbe apparire un'immagine simile. È evidente che il router è riuscito a connettersi al server aggregato e entrambi i canali funzionano correttamente.

Per impostazione predefinita viene utilizzata la modalità shadowsocks + mptcp. Si tratta di un proxy che incapsula tutte le connessioni. Inizialmente è configurato per gestire solo TCP, ma è possibile abilitare anche UDP.

Se non ci sono errori nella pagina di stato, si può considerare completata la configurazione.
Con alcuni provider potrebbe verificarsi una situazione in cui il flag mptcp viene troncato lungo il percorso di traffico, generando il seguente errore:

In questo caso è possibile utilizzare un'altra modalità operativa, senza l'uso di MPTCP, ulteriori dettagli su questa .
Conclusione
Il progetto OpenMPTCPRouter è molto interessante e importante, in quanto rappresenta probabilmente l'unica soluzione open-source completa al problema dell'aggregazione dei canali. Tutto il resto è o totalmente chiuso e proprietario, oppure semplicemente moduli separati, con cui una persona comune fatica a orientarsi. Al momento attuale, il progetto è ancora piuttosto grezzo, con una documentazione estremamente scarsa e molte cose non sono semplicemente descritte. Tuttavia, funziona ancora. Spero che continuerà a svilupparsi e che avremo router casalinghi in grado di aggregare canali in modo efficace sin dal primo utilizzo.
Segui il nostro sviluppatore su Instagram
Fonte: habr.com
