Ă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 den hÀr uppgiften kommer vi att anvÀnda en VPS-server Debian 10.
Krav för summeringsservern:
- MPTCP fungerar inte pÄ OpenVZ-virtualisering
- Det borde vara möjligt att installera sin egen kÀrna Linux
Servern driftsÀtts genom att köra ett enda kommando. Skriptet installerar en kÀrna med mptcp-stöd och alla nödvÀndiga paket. Installationsskript Àr tillgÀngliga för Ubuntu О 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
