Kan man kombinere flere internetkanaler til én? Der er mange misforståelser og myter omkring dette emne, selv erfarne netværksingeniører er ofte i tvivl om, at det er muligt. I de fleste tilfælde bliver kanalernes sammenlægning fejlagtigt kaldt NAT-balancering eller failover. Men rigtig summation tillader at oprette en enkelt TCP-forbindelse, der samtidigt benytter alle internetkanaler, for eksempel ved videotransmission, så udsendelsen ikke afbrydes ved en hvilken som helst afbrudt internetkanal.
Der findes dyre kommercielle løsninger til videotransmission, men sådanne enheder koster mange tusinde kroner. Artiklen beskriver opsætningen af en gratis, åben pakke kaldet OpenMPTCPRouter og tager fat på populære myter om kanalernes summation.
Myter om summation af kanaler
Der findes mange almindelige routere, der understøtter Multi-WAN-funktionen. Nogle gange kalder producenterne dette kanalaggregation, hvilket ikke helt er korrekt. Mange netværksteknikere tror, at der ikke findes nogen anden form for kanalsammenlægning end og summation på L2-niveau. Jeg har ofte hørt fra folk, der arbejder i telekommunikation, at dette overhovedet ikke er muligt. Så lad os prøve at se nærmere på de populære myter.
Balancering på IP-forbindelsesniveau
Dette er den mest tilgængelige og populære måde at udnytte flere internetkanaler på samtidig. For enkelhedens skyld forestiller vi os, at du har tre internetudbydere, hvor hver giver dig en faktisk IP-adresse fra sit netværk. Alle disse udbydere er tilsluttet en router med Multi-WAN-funktion. Dette kan være OpenWRT med mwan3-pakken, MikroTik, Ubiquiti eller enhver anden almindelig router, da denne funktion nu ikke er usædvanlig.
For at simulere situationen lad os forestille os, at udbyderne har givet os følgende adresser:
WAN1 — 11.11.11.11
WAN2 — 22.22.22.22
WAN3 — 33.33.33.33
Det vil sige, at vi opretter forbindelse til en ekstern server example.com Gennem hver af udbyderne vil den remote server se tre uafhængige source IP'er for klienten. Balanceringen gør det muligt at fordele belastningen over kanalerne og bruge alle tre samtidig. For enkelhedens skyld, lad os forestille os, at vi deler belastningen ligeligt mellem alle kanaler. Som et resultat, når klienten åbner et websted, der hypotetisk har tre billeder, indlæser den hvert billede gennem en separat udbyder. På webstedets side ser det ud som forbindelse fra tre forskellige IP'er.
Ved balancering på forbindelsesniveau går hver TCP-forbindelse gennem en separat udbyder.
Denne balanceringsmetode medfører ofte problemer for brugerne. For eksempel binder mange websteder cookies og tokens strengt til klientens IP-adresse, og hvis den pludselig ændres, bliver anmodningen afvist eller klienten logget ud af webstedet. Dette sker ofte i bankklient-systemer og på andre websteder med strenge regler for brugersessioner. Her er et simpelt eksempel: musikfiler på VK.com er kun tilgængelige med en gyldig sessionsnøgle, der er knyttet til IP-adressen, og kunder, der bruger sådan balancering, kan ofte ikke afspille lydfiler, fordi anmodningen gik gennem en anden udbyder, end sessionen er knyttet til.
Ved downloading af torrents summerer balancering på forbindelsesniveau båndbredden fra alle kanaler.
Denne balancering muliggør summering af hastigheden fra internetkanalen, når der bruges mange forbindelser. For eksempel, hvis hver af de tre udbydere har en hastighed på 100 megabit, så får vi 300 megabit ved download af torrents. Dette skyldes, at torrenten åbner mange forbindelser, der fordeles mellem alle udbydere og dermed udnytter hele kanalen.
Det er vigtigt at forstå, at én enkelt TCP-forbindelse altid vil gå gennem én udbyder. Det vil sige, hvis vi downloader en stor fil via HTTP, vil denne forbindelse blive udført gennem en af udbyderne, og hvis forbindelsen til denne udbyder brydes, vil download også stoppe.
Én forbindelse vil altid kun bruge én internetkanal.
Det gælder også for livestreams. Hvis du streamer video på et hypotetisk Twitch, vil IP-forbindelsesbalancering ikke give nogen særlig fordel, da videostreamen vil blive sendt gennem én IP-forbindelse. I dette tilfælde, hvis WAN-udbyderen oplever forbindelsesproblemer, som tab af pakker eller hastighedsnedsættelse, kan du ikke straks skifte til en anden udbyder. Streaming skal stoppes, og forbindelsen genoprettes.
Egte kanalsammenlægning
Reel kanalsammenlægning giver mulighed for at sende én forbindelse til hypotetiske Twitch gennem alle udbydere, således at hvis en af udbyderne går ned, vil forbindelsen ikke blive brudt. Dette er overraskende kompliceret og har stadig ikke en optimal løsning. Mange ved endda ikke, at dette er muligt!
Ifølge de tidligere illustrationer husker vi, at den hypotetiske Twitch-server kun kan modtage videostreamen fra én kilde-IP-adresse, hvilket betyder, at vi altid skal have en konstant adresse, uanset hvilke udbydere der er faldet fra, og hvilke der virker. For at opnå dette har vi brug for en sammenlægningsserver, der vil terminere alle vores forbindelser og kombinere dem til én.
Sammenlægningsserveren aggregerer alle kanaler til én tunnel. Alle forbindelser sker fra adressen på sammenlægningsserveren.
I en sådan ordning anvendes alle udbydere, og afbrydelse af en af dem vil ikke forårsage brud på forbindelsen til Twitch-serveren. I bund og grund er det en særlig VPN-tunnel, der under motorhjelmen har flere internetkanaler. Hovedmålet med en sådan ordning er at opnå den bedst mulige forbindelseskvalitet. Hvis der opstår problemer med en af udbyderne, tab af pakker eller øgede forsinkelser, skal dette ikke påvirke forbindelseskvaliteten, da belastningen automatisk vil blive fordelt på andre, mere kvalitetskanaler, der er til rådighed.
Kommersielle løsninger
Dette problem har længe bekymret dem, der live-streamer begivenheder og ikke har adgang til kvalitetsinternet. Der findes flere kommercielle løsninger til sådanne opgaver, for eksempel producerer virksomheden Teradek sådanne enorme routere, hvor der kan indsættes stakke af USB-modemer:
Router til videostreaming med kanal-sammenlægning funktion
I sådanne enheder er der normalt indbygget mulighed for at fange videosignalet via HDMI eller SDI. Sammen med routeren sælges et abonnement på tjenesten til kanal-sammenlægning samt til behandling af videostrøm, omkodning af den og retransmission. Priserne på sådanne enheder starter fra 2.000 $ med modempakker, plus et separat abonnement på tjenesten.
Nogle gange ser det ret skræmmende ud:
Konfigurerer OpenMPTCPRouter
Protokol (MultiPath TCP) blev opfundet for at muliggøre tilslutning på flere kanaler samtidig. For eksempel understøtter det og kan samtidig forbinde til en fjernserver via WiFi og mobilnetværk. Det er vigtigt at forstå, at dette ikke er to separate TCP-forbindelser, men netop én forbindelse, der er etableret gennem to kanaler. For at dette skal fungere, skal den fjerntliggende server også understøtte MPTCP.
er et open source-projekt til software-router, der reelt kan sammenlægge kanaler. Forfatterne erklærer, at projektet er i alpha-status, men det kan allerede bruges. Det består af to dele - en sammenlægningsserver, der hostes på internettet, og en router, som flere internetudbydere og klientenheder såsom computere og telefoner forbinder til. Raspberry Pi, nogle WiFi-routere eller en almindelig computer kan fungere som bruger-router. Der findes præbyggede versioner til forskellige platforme, hvilket er meget praktisk.
Principperne for OpenMPTCPRouter
Konfiguration af sammenlægningsserveren
Sammenlægningsserveren placeres på internettet og terminerer forbindelser fra alle kanaler fra klientrouteren til én. IP-adressen på denne server vil være den offentlige adresse ved udgang til internettet gennem OpenMPTCPRouter.
Til denne opgave vil vi bruge en VPS-server på Debian 10.
Krav til sammenlægningsserveren:
- MPTCP fungerer ikke på OpenVZ virtualisering
- Der skal være mulighed for at installere egen Linux-kernel
Serveren deployeres ved at udføre én kommando. Scriptet vil installere en kernel med mptcp støtte og alle nødvendige pakker. Installeringsscripts er tilgængelige for Ubuntu og Debian.
wget -O - http://www.openmptcprouter.com/server/debian10-x86_64.sh | sh
Resultatet af en vellykket serverinstallation.
Vi gemmer adgangskoderne, da de vil være nødvendige for at konfigurere klientrouteren, og vi genstarter. Det er vigtigt at huske, at SSH vil være tilgængeligt på port 65222 efter installationen. Efter genstart skal vi sikre os, at vi er startet op med den nye kerne.
uname -a
Linux test-server.local 4.19.67-mptcp
Vi ser betegnelsen mptcp ved siden af versionnummeret, hvilket betyder, at kernen er installeret korrekt.
Konfiguration af klientrouteren
På færdige builds er tilgængelige for nogle platforme, såsom Raspberry Pi, Banana Pi, Lynksys-routere og virtuelle maskiner.
Denne del af openmptcprouter er baseret på OpenWRT, og LuCI bruges som interface, hvilket er velkendt for alle, der har arbejdet med OpenWRT. Distributionen vejer omkring 50 MB!
Som testbed vil jeg bruge Raspberry Pi og flere USB-modemer med forskellige operatører: MTS og MegaFon. Jeg antager, at det ikke er nødvendigt at forklare, hvordan man skriver et billede til SD-kortet.
Ethernet-porten i Raspberry Pi er oprindeligt indstillet som lan med en statisk IP-adresse. 192.168.100.1. For ikke at rode med kablerne på bordet, har jeg tilsluttet Raspberry Pi til WiFi-adgangspunktet og tildelt en statisk adresse til computerens WiFi-adapter. 192.168.100.2. DHCP-serveren er ikke aktiveret som standard, så statiske adresser skal bruges.
Nu kan vi få adgang til webgrænsefladen.
Ved første login beder systemet om at angive root-adgangskode, og SSH vil være tilgængeligt med den samme adgangskode.
I LAN-indstillingerne kan den ønskede subnetmaske angives, og DHCP-serveren kan aktiveres.
Jeg bruger modemer, der identificeres som USB Ethernet interfaces med separate DHCP-servere, så det krævede installation af . Proceduren er identisk med konfiguration af modemer i almindelig OpenWRT, så jeg vil ikke gennemgå den her.
Dernæst skal WAN-interface indstilles. To virtuelle WAN-interfacer, WAN1 og WAN2, er oprindeligt oprettet i systemet. Fysiske enheder skal tildeles dem; i mit tilfælde er dét USB-modemernavnene.
For ikke at blive forvirret med navnene på interfacerne, anbefaler jeg at se dmesg-beskederne ved at oprette forbindelse via SSH.
Da mine modemer selv fungerer som routere og har deres egne DHCP-servere, måtte jeg ændre konfigurationen af deres interne netværksområder og deaktivere DHCP-serveren, da begge modemer oprindeligt tildeler adresser fra det samme netværk, hvilket forårsager konflikt.
OpenMPTCPRouter kræver, at WAN-interface adresserne er statiske, så vi finder på subnetter til modemmerne og indstiller dem i menuen system → openmptcprouter → interface settings. Her skal IP-adressen og servernøglen indtastes, som blev modtaget under installationen af den samlede server.
Hvis opsætningen er vellykket, skal siden med status vise et lignende billede. Det er synligt, at routeren har kunnet få kontakt til den samlede server, og begge kanaler fungerer korrekt.
Som standard anvendes mode shadowsocks + mptcp. Det er en proxy, der omslutter alle forbindelser. Oprindeligt er den indstillet til kun at behandle TCP, men UDP kan også aktiveres.
Hvis der ikke er fejl på status siden, kan opsætningen betragtes som afsluttet.
Med nogle udbydere kan der opstå en situation, hvor mptcp-flaget bliver skåret, hvilket giver denne fejl:
I dette tilfælde kan en anden driftsmode anvendes, uden brug af MPTCP, læs mere om dette .
Konklusion
Projektet OpenMPTCPRouter er meget interessant og vigtigt, da det måske er den eneste åbne, komplette løsning på problemet med kanalopsummering. Alt andet er enten helt lukket og proprietært eller blot separate moduler, som en almindelig person har svært ved at forstå. På nuværende stadie er projektet stadig ret uferdigt, med meget sparsom dokumentation, hvor mange ting simpelthen ikke er beskrevet. Men det fungerer stadig. Jeg håber, at det vil fortsætte med at udvikle sig, og at vi vil få hjemme-routere, der kan samle kanaler ordentligt fra starten.
Følg vores udvikler på Instagram
Kilde: habr.com
