Är det möjligt att kombinera flera internetkanaler till en? Det finns många missuppfattningar och myter kring detta ämne; även erfarna nätverksingenjörer vet ofta inte att detta är möjligt. I de flesta fall kallas länkaggregation av misstag för balansering på NAT-nivå eller failover. Men riktig summering tillåter starta en enda TCP-anslutning samtidigt över alla internetkanalert.ex. videosändning så att om någon av internetkanalerna avbryts kommer sändningen inte att avbrytas.
Det finns dyra kommersiella lösningar för videosändningar, men sådana enheter kostar många kilobucks. Artikeln beskriver hur man konfigurerar det kostnadsfria OpenMPTCPRouter-paketet med öppen källkod och tar upp populära myter om kanalsummering.
Myter om kanalsummering
Det finns många hemroutrar som stöder Multi-WAN-funktionen. Ibland kallar tillverkare denna kanal summering, vilket inte är helt sant. Många nätverkare tror att förutom och summering på L2-nivå, finns ingen annan kanalaggregation. Jag har ofta hört att detta i allmänhet är omöjligt från folk som jobbar inom telekom. Låt oss därför försöka förstå populära myter.
Balansering på IP-anslutningsnivå
Detta är det mest prisvärda och populära sättet att använda flera internetkanaler samtidigt. För enkelhetens skull, låt oss föreställa oss att du har tre internetleverantörer, som var och en ger dig en riktig IP-adress från deras nätverk. Alla dessa leverantörer är anslutna till en router som stöder Multi-WAN-funktionen. Detta kan vara OpenWRT med mwan3-paketet, mikrotik, ubiquiti eller någon annan hushållsrouter, eftersom ett sådant alternativ inte längre är ovanligt.
För att simulera situationen, låt oss föreställa oss att leverantörerna gav oss följande adresser:
WAN1 — 11.11.11.11
WAN2 — 22.22.22.22
WAN2 — 33.33.33.33
Det vill säga att ansluta till en fjärrserver example.com Genom var och en av leverantörerna kommer fjärrservern att se tre oberoende IP-källklienter. Balansering gör att du kan fördela belastningen över kanaler och använda dem alla tre samtidigt. För enkelhetens skull, låt oss föreställa oss att vi delar belastningen lika mellan alla kanaler. Som ett resultat, när en klient öppnar en webbplats med tre bilder, laddar han ner varje bild via en separat leverantör. På sajtsidan ser det ut som anslutningar från tre olika IP-adresser.
Vid balansering på anslutningsnivå går varje TCP-anslutning genom en separat leverantör.
Detta balanseringsläge orsakar ofta problem för användarna. Till exempel binder många webbplatser cookies och tokens strikt till klientens IP-adress, och om den plötsligt ändras avvisas begäran eller klienten loggas ut från webbplatsen. Detta återges ofta i klient-banksystem och andra webbplatser med strikta användarsessionsregler. Här är ett enkelt illustrativt exempel: musikfiler på VK.com är endast tillgängliga med en giltig sessionsnyckel, som är bunden till en IP, och klienter som använder sådan balansering spelar ofta inte upp ljud eftersom begäran inte gick via leverantören till vilken sessionen är bunden.
När du laddar ner torrents, sammanfattar anslutningsnivåbalanseringen bandbredden för alla kanaler
Denna balansering gör att du kan få en summering av hastigheten på internetkanalen när du använder flera anslutningar. Till exempel, om var och en av de tre leverantörerna har en hastighet på 100 megabit, så får vi 300 megabit när vi laddar ner torrents. Eftersom en torrent öppnar många anslutningar, som distribueras mellan alla leverantörer och i slutändan utnyttjar hela kanalen.
Det är viktigt att förstå att en enda TCP-anslutning alltid går via endast en leverantör. Det vill säga, om vi laddar ner en stor fil via HTTP, så kommer denna anslutning att göras genom en av leverantörerna, och om förbindelsen med denna leverantör bryts kommer även nedladdningen att bryta.
En anslutning kommer alltid att använda endast en internetkanal
Detta gäller även för videosändningar. Om du sänder strömmande video till någon form av villkorlig Twitch, kommer balansering på nivån för IP-anslutningar inte att ge någon speciell fördel, eftersom videoströmmen kommer att sändas inom en IP-anslutning. I det här fallet, om WAN 3-leverantören börjar få problem med kommunikationen, såsom paketförlust eller minskad hastighet, kommer du inte att omedelbart kunna byta till en annan leverantör. Sändningen måste stoppas och återanslutas.
Sann kanalsummering
Verklig kanalsummering gör det möjligt att köra en anslutning till en villkorad Twitch genom alla leverantörer samtidigt på ett sådant sätt att om någon av leverantörerna går sönder kommer anslutningen inte att avbrytas. Detta är ett förvånansvärt svårt problem som fortfarande inte har en optimal lösning. Många människor vet inte ens att detta är möjligt!
Från de tidigare illustrationerna kommer vi ihåg att den villkorade Twitch-servern kan ta emot en videoström från oss från endast en käll-IP-adress, vilket innebär att den alltid måste vara konstant för oss, oavsett vilka leverantörer som har fallit av och vilka som fungerar. För att uppnå detta behöver vi en summeringsserver som avslutar alla våra anslutningar och kombinerar dem till en.
Summeringsservern samlar alla kanaler i en tunnel. Alla anslutningar kommer från den summerande serveradressen
I det här schemat används alla leverantörer, och om du inaktiverar någon av dem kommer inte kommunikationen med Twitch-servern att försvinna. I huvudsak är detta en speciell VPN-tunnel, under huven där det finns flera internetkanaler samtidigt. Huvuduppgiften för ett sådant system är att erhålla kommunikationskanalen av högsta kvalitet. Om någon av leverantörerna börjar få problem, förlust av paket, ökade förseningar, bör detta inte påverka kvaliteten på kommunikationen på något sätt, eftersom belastningen automatiskt kommer att fördelas över andra, bättre kanaler som är tillgängliga.
Kommersiella lösningar
Detta problem har länge bekymrat dem som sänder liveevenemang och inte har tillgång till högkvalitativt internet. För sådana uppgifter finns det flera kommersiella lösningar, till exempel tillverkar företaget Teradek sådana monstruösa routrar i vilka paket med USB-modem sätts in:
Router för videosändningar med kanalsummeringsfunktion
Sådana enheter har vanligtvis en inbyggd förmåga att fånga videosignaler via HDMI eller SDI. Tillsammans med routern säljs ett abonnemang på kanalsummeringstjänsten, samt bearbetar videoströmmen, omkodar den och vidarebefordrar den. Priset för sådana enheter börjar från $2k med en uppsättning modem, plus ett separat abonnemang på tjänsten.
Ibland ser det ganska läskigt ut:
Konfigurera OpenMPTCPRouter
Protokoll (MultiPath TCP) uppfanns för att kunna ansluta via flera kanaler samtidigt. Till exempel hans och kan samtidigt ansluta till en fjärrserver via WiFi och via ett mobilnätverk. Det är viktigt att förstå att dessa inte är två separata TCP-anslutningar, utan snarare en anslutning som upprättas över två kanaler samtidigt. För att detta ska fungera måste fjärrservern också stödja MPTCP.
är ett routerprojekt med öppen källkod som möjliggör sann kanalsammanfattning. Författarna uppger att projektet är i alfaversionsstatus, men det kan redan användas. Den består av två delar - en summeringsserver, som finns på Internet och en router, till vilken flera internetleverantörer och själva klientenheterna är anslutna: datorer, telefoner. Den anpassade routern kan vara en Raspberry Pi, vissa WiFi-routrar eller en vanlig dator. Det finns färdiga monteringar för olika plattformar, vilket är väldigt bekvämt.
Hur OpenMPTCPRouter fungerar
Konfigurera en sammanfattningsserver
Summeringsservern finns på Internet och avslutar anslutningar från alla kanaler på klientroutern till en. IP-adressen för denna server kommer att vara den externa adressen när du ansluter till Internet via OpenMPTCPRouter.
För denna uppgift kommer vi att använda en VPS-server på Debian 10.
Krav för summeringsservern:
- MPTCP fungerar inte på OpenVZ-virtualisering
- Det ska vara möjligt att installera din egen Linux-kärna
Servern distribueras genom att köra ett kommando. Skriptet kommer att installera en kärna med mptcp-stöd och alla nödvändiga paket. Installationsskript finns tillgängliga för Ubuntu och Debian.
wget -O - http://www.openmptcprouter.com/server/debian10-x86_64.sh | sh
Resultatet av en lyckad serverinstallation.
Vi sparar lösenorden, vi behöver dem för att konfigurera klientroutern och starta om. Det är viktigt att komma ihåg att efter installationen kommer SSH att finnas tillgänglig på port 65222. Efter omstart måste vi se till att vi startade med den nya kärnan
uname -a
Linux test-server.local 4.19.67-mptcp
Vi ser inskriptionen mptcp bredvid versionsnumret, vilket betyder att kärnan installerades korrekt.
Konfigurera en klientrouter
På färdiga builds finns tillgängliga för vissa plattformar, som Raspberry Pi, Banana Pi, Lynksys-routrar och virtuella maskiner.
Den här delen av openmptcprouter är baserad på OpenWRT, med LuCI som ett gränssnitt, bekant för alla som någonsin har stött på OpenWRT. Distributionen väger ca 50MB!
Som testbänk kommer jag att använda en Raspberry Pi och flera USB-modem med olika operatörer: MTS och Megafon. Jag tror inte att jag behöver berätta hur man skriver en bild till ett SD-kort.
Inledningsvis är Ethernet-porten i Raspberry Pi konfigurerad som LAN med en statisk IP-adress 192.168.100.1. För att slippa pilla med sladdar på skrivbordet kopplade jag Raspberry Pi till en WiFi-åtkomstpunkt och ställde in datorns WiFi-adapter på en statisk adress 192.168.100.2. DHCP-servern är inte aktiverad som standard, så du måste använda statiska adresser.
Nu kan du logga in på webbgränssnittet
När du loggar in för första gången kommer systemet att be dig ställa in ett root-lösenord; SSH kommer att vara tillgängligt med samma lösenord.
I LAN-inställningarna kan du ställa in önskat subnät och aktivera DHCP-servern.
Jag använder modem som är definierade som USB Ethernet-gränssnitt med en separat DHCP-server, så detta krävde installation . Proceduren är identisk med att sätta upp modem i vanliga OpenWRT, så jag kommer inte att ta upp det här.
Därefter måste du konfigurera WAN-gränssnitten. Inledningsvis skapade systemet två virtuella gränssnitt WAN1 och WAN2. De måste tilldelas en fysisk enhet, i mitt fall är dessa namnen på USB-modemgränssnitten.
För att undvika förvirring med gränssnittsnamn rekommenderar jag att du tittar på dmesg-meddelanden medan du ansluter via SSH.
Eftersom mina modem själva fungerar som routrar och själva har en DHCP-server, var jag tvungen att ändra inställningarna för deras interna nätverksintervall och inaktivera DHCP-servern, eftersom båda modemen initialt utfärdar adresser från samma nätverk, och detta orsakar en konflikt.
OpenMPTCPRouter kräver att WAN-gränssnittsadresserna är statiska, så vi tar fram subnät för modemen och konfigurerar dem i system → openmptcprouter → gränssnittsinställningar. Här måste du ange IP-adressen och servernyckeln som erhölls under installationen av summeringsservern.
Om installationen lyckas bör en liknande bild visas på statussidan. Det kan ses att routern kunde nå summeringsservern och båda kanalerna fungerar normalt.
Standardläget är shadowsocks + mptcp. Detta är en proxy som omsluter alla anslutningar inom sig själv. Den är initialt konfigurerad att endast bearbeta TCP, men UDP kan också aktiveras.
Om det inte finns några fel på statussidan kan installationen anses vara klar.
Hos vissa leverantörer kan en situation uppstå när mptcp-flaggan är avskuren längs trafikvägen, då kommer följande fel att visas:
I det här fallet kan du använda ett annat driftläge, utan att använda MPTCP, mer om detta .
Slutsats
OpenMPTCPRouter-projektet är mycket intressant och viktigt, eftersom det kanske är den enda öppna heltäckande lösningen på kanalsummeringsproblemet. Allt annat är antingen tätt stängt och proprietärt, eller helt enkelt separata moduler som en vanlig människa inte kan förstå. I det nuvarande utvecklingsstadiet är projektet fortfarande ganska grovt, dokumentationen är extremt dålig, många saker beskrivs helt enkelt inte. Men samtidigt fungerar det fortfarande. Jag hoppas att det kommer att fortsätta att utvecklas, och vi kommer att få hushållsroutrar som kommer att kunna kombinera kanaler ordentligt ur lådan.
Följ vår utvecklare på Instagram
Källa: will.com