Er det muligt at kombinere flere internetkanaler til én? Der er mange misforståelser og myter omkring dette emne, selv erfarne netværksingeniører ved ofte ikke, at dette er muligt. I de fleste tilfælde omtales linkaggregering fejlagtigt som NAT-balancering eller failover. Men ægte summering tillader det køre én enkelt TCP-forbindelse samtidigt over alle internetkanalerfor eksempel videoudsendelse, så hvis nogen af internetkanalerne afbrydes, bliver udsendelsen ikke afbrudt.
Der er dyre kommercielle løsninger til videoudsendelse, men sådanne enheder koster mange kilobucks. Artiklen beskriver konfigurationen af den gratis, åbne pakke OpenMPTCPRouter og omhandler populære myter om kanalsumering.
Myter om summering af kanaler
Der er mange hjemmeroutere, der understøtter Multi-WAN-funktionen. Nogle gange kalder producenterne denne kanal for summering, hvilket ikke er helt sandt. Mange netværkere mener, at foruden og summering ved L2-laget, eksisterer der ingen anden kanalaggregering. Jeg har ofte hørt, at dette generelt er umuligt fra folk, der arbejder inden for telekommunikation. Lad os derfor prøve at forstå populære myter.
Balancering på niveau med IP-forbindelser
Dette er den mest overkommelige og populære måde at bruge flere internetkanaler på på samme tid. For nemheds skyld, lad os forestille os, at du har tre internetudbydere, der hver giver dig en rigtig IP-adresse fra deres netværk. Alle disse udbydere er forbundet til en router med understøttelse af Multi-WAN-funktionen. Dette kan være OpenWRT med mwan3-pakken, mikrotik, ubiquiti eller enhver anden husstandsrouter, da denne mulighed nu ikke længere er ualmindeligt.
For at simulere situationen, forestil dig, at udbyderne gav os følgende adresser:
WAN1 — 11.11.11.11
WAN2 — 22.22.22.22
WAN2 — 33.33.33.33
Det vil sige at oprette forbindelse til en ekstern server example.com gennem hver af udbyderne vil fjernserveren se tre uafhængige kilde-ip-adresser til klienten. Balancering giver dig mulighed for at dele belastningen på tværs af kanaler og bruge dem alle tre på samme tid. Lad os for nemheds skyld forestille os, at vi deler belastningen ligeligt mellem alle kanaler. Som et resultat, når en klient åbner et websted med tre billeder betinget, downloader han hvert billede gennem en separat udbyder. På siden ser det ud som forbindelser fra tre forskellige IP'er.
Ved balancering på forbindelsesniveau går hver TCP-forbindelse gennem en separat udbyder.
Denne balanceringstilstand giver ofte problemer for brugerne. For eksempel kan mange websteder koble cookies og tokens til klientens IP-adresse, og hvis den pludselig ændres, bliver anmodningen droppet, eller klienten logger ud på webstedet. Dette gengives ofte i klient-banksystemer og andre websteder med strenge brugersessionsregler. Her er et simpelt illustrativt eksempel: musikfiler i VK.com er kun tilgængelige med en gyldig sessionsnøgle, der er bundet til IP, og klienter, der bruger en sådan balancering, afspiller ofte ikke lyd, fordi anmodningen ikke gik gennem den udbyder, som session er bundet.
Når du downloader torrents, summerer balancering på forbindelsesniveau båndbredden af alle kanaler
Sådan balancering giver dig mulighed for at få summeringen af internetkanalens hastighed, når du bruger flere forbindelser. For eksempel, hvis hver af de tre udbydere har en hastighed på 100 megabit, vil vi, når vi downloader torrents, få 300 megabit. Fordi torrenten åbner en masse forbindelser, der er fordelt mellem alle udbydere og til sidst udnytter hele kanalen.
Det er vigtigt at forstå, at én enkelt TCP-forbindelse altid kun vil gå gennem én udbyder. Det vil sige, at hvis vi downloader én stor fil via HTTP, så vil denne forbindelse blive lavet gennem en af udbyderne, og hvis forbindelsen med denne udbyder går i stykker, så vil downloadingen også bryde.
Én forbindelse vil altid kun bruge én internetkanal
Dette gælder også for videoudsendelser. Hvis du udsender streaming video på en betinget Twitch, vil balancering på niveauet af IP-forbindelser ikke give nogen særlig fordel, da videostreamen vil blive udsendt inden for én IP-forbindelse. I dette tilfælde, hvis WAN 3-udbyderen begynder at få kommunikationsproblemer, såsom pakketab eller opbremsning, så vil du ikke umiddelbart kunne skifte til en anden udbyder. Udsendelsen skal stoppes og tilsluttes igen.
Ægte kanalsummering
Den reelle summering af kanaler gør det muligt at starte én forbindelse til den betingede Twitch gennem alle udbydere på én gang på en sådan måde, at hvis nogen af udbyderne går i stykker, vil forbindelsen ikke blive afbrudt. Dette er et overraskende vanskeligt problem, som stadig ikke har en optimal løsning. Mange ved ikke engang, at dette er muligt!
Fra de tidligere illustrationer husker vi, at den betingede Twitch-server kan modtage en videostream fra os fra kun én kilde-IP-adresse, hvilket betyder, at den altid skal være konstant hos os, uanset hvilke udbydere der er faldet fra, og hvilke der virker. For at opnå dette har vi brug for en summeringsserver, der afslutter alle vores forbindelser og slår dem sammen til én.
Summeringsserveren samler alle kanaler i én tunnel. Alle forbindelser stammer fra adressen på summeringsserveren
Denne ordning bruger alle udbydere, og deaktivering af nogen af dem vil ikke forårsage tab af kommunikation med Twitch-serveren. Faktisk er dette en speciel VPN-tunnel, under hvilken der er flere internetkanaler på én gang. Hovedopgaven for en sådan ordning er at opnå kommunikationskanal af højeste kvalitet. Hvis problemer starter hos en af udbyderne, pakketab, stigning i forsinkelser, så bør dette ikke påvirke kvaliteten af kommunikationen på nogen måde, da belastningen automatisk vil blive fordelt over andre, bedre kanaler, der er tilgængelige.
Kommercielle løsninger
Dette problem har længe været et problem for dem, der sender begivenheder live og ikke har adgang til internet af høj kvalitet. Til sådanne opgaver er der flere kommercielle løsninger, for eksempel laver Teradek sådanne monstrøse routere, som pakker med USB-modemmer er indsat i:
Broadcast video-router med kanalsummeringsfunktion
Sådanne enheder har normalt mulighed for at optage video via HDMI eller SDI. Sammen med routeren sælges et abonnement på kanalsummeringstjenesten, ligesom videostrømmen behandles, omkodes og videresendes. Prisen på sådanne enheder starter fra $ 2k med et sæt modemer plus et separat abonnement på tjenesten.
Nogle gange ser det ret skræmmende ud:
Opsætning af OpenMPTCPRouter
protokol (MultiPath TCP) blev opfundet for evnen til at forbinde på flere kanaler på én gang. For eksempel hans og kan samtidigt oprette forbindelse til en fjernserver via WiFi og via et mobilnetværk. Det er vigtigt at forstå, at disse ikke er to separate TCP-forbindelser, men en forbindelse etableret over to kanaler på én gang. For at dette skal virke, skal fjernserveren også understøtte MPTCP.
er et open source software-router-projekt, der giver dig mulighed for virkelig at summere kanaler. Forfatterne oplyser, at projektet er i alfaversionsstatus, men det kan allerede bruges. Den består af to dele - en summeringsserver, som er placeret på internettet og en router, som flere internetudbydere og klientenheder selv er forbundet til: computere, telefoner. En brugerdefineret router kan være en Raspberry Pi, nogle WiFi-routere eller en almindelig computer. Der er færdige samlinger til forskellige platforme, hvilket er meget praktisk.
Sådan fungerer OpenMPTCPRouter
Opsummering server opsætning
Opsummeringsserveren er placeret på internettet og afslutter forbindelser fra alle kanaler på klientrouteren til én. IP-adressen på denne server vil være den eksterne adresse, når du får adgang til internettet via OpenMPTCPRouter.
Til denne opgave vil vi bruge en VPS-server på Debian 10.
Summationsserverkrav:
- MPTCP virker ikke på OpenVZ virtualisering
- Det skulle være muligt at installere din egen Linux-kerne
Serveren implementeres ved at udføre én kommando. Scriptet vil installere den mptcp-aktiverede kerne og alle nødvendige pakker. Installationsscripts er tilgængelige til Ubuntu og Debian.
wget -O - http://www.openmptcprouter.com/server/debian10-x86_64.sh | sh
Resultatet af en vellykket serverinstallation.
Vi gemmer adgangskoderne, vi skal bruge dem til at konfigurere klientrouteren og genstarte. Det er vigtigt at huske på, at efter installationen vil SSH være tilgængelig på port 65222. Efter genstart skal vi sikre os, at vi starter op med den nye kerne
uname -a
Linux test-server.local 4.19.67-mptcp
Vi ser inskriptionen mptcp ved siden af versionsnummeret, hvilket betyder, at kernen blev installeret korrekt.
Opsætning af en klientrouter
On Færdiglavede builds er tilgængelige til nogle platforme, såsom Raspberry Pi, Banana Pi, Lynksys-routere og virtuelle maskiner.
Denne del af openmptcprouter er baseret på OpenWRT, der bruger LuCI som en grænseflade, kendt for alle, der nogensinde har stødt på OpenWRT. Distributionssættet vejer omkring 50 Mb!
Som testbænk vil jeg bruge Raspberry Pi og flere USB-modemmer med forskellige operatører: MTS og Megafon. Hvordan man skriver et billede til et SD-kort, tror jeg, det er ikke nødvendigt at fortælle.
I første omgang er Ethernet-porten i Raspberry Pi konfigureret som LAN med en statisk IP-adresse. 192.168.100.1. For ikke at rode med ledningerne på bordet, sluttede jeg Raspberry Pi til et WiFi-adgangspunkt og indstillede en statisk adresse på computerens WiFi-adapter 192.168.100.2. DHCP-serveren er ikke aktiveret som standard, så statiske adresser skal bruges.
Nu kan du gå til webgrænsefladen
Når du først logger på, vil systemet bede dig om at indstille root-adgangskoden, SSH vil være tilgængelig med den samme adgangskode.
I LAN-indstillingerne kan du indstille det ønskede undernet og aktivere DHCP-serveren.
Jeg bruger modemer, der er defineret som USB ethernet-grænseflader med en separat DHCP-server, så dette krævede installation . Proceduren er identisk med at konfigurere modemer i almindelig OpenWRT, så jeg vil ikke dække det her.
Dernæst skal du konfigurere WAN-grænsefladerne. I første omgang blev der oprettet to virtuelle grænseflader WAN1 og WAN2 i systemet. De skal tildele en fysisk enhed, i mit tilfælde er disse navnene på USB-modemgrænseflader.
For ikke at blive forvirret i grænsefladenavnene, råder jeg dig til at se dmesg-meddelelser, mens du er tilsluttet via SSH.
Da mine modemer selv fungerer som routere og selv har en DHCP-server, var jeg nødt til at ændre indstillingerne for deres interne netværksområder og deaktivere DHCP-serveren, fordi begge modemer i første omgang udsender adresser fra det samme netværk, og det forårsager en konflikt.
OpenMPTCPRouter kræver, at WAN-grænsefladeadresser er statiske, så vi opfinder undernet til modemer og konfigurerer dem i systemet → openmptcprouter → menuen interfaceindstillinger. Her skal du også angive IP-adressen og servernøglen opnået under installationen af summeringsserveren.
I tilfælde af vellykket opsætning bør et lignende billede vises på statussiden. Det kan ses, at routeren var i stand til at nå summeringsserveren, og begge kanaler fungerer korrekt.
Standardtilstanden er shadowsocks + mptcp. Dette er sådan en proxy, der omslutter alle forbindelser i sig selv. I starten er den konfigureret til kun at håndtere TCP, men du kan også aktivere UDP.
Hvis der ikke er fejl på statussiden, kan opsætningen betragtes som afsluttet.
Hos nogle udbydere kan der opstå en situation, når mptcp-flaget afkortes langs trafikstien, så vil der være sådan en fejl:
I dette tilfælde kan du bruge en anden driftstilstand uden at bruge MPTCP, mere om dette .
Konklusion
OpenMPTCPRouter-projektet er meget interessant og vigtigt, da det måske er den eneste åbne komplekse løsning på kanalsumationsproblemet. Alt andet er enten tæt lukket og proprietært, eller bare separate moduler, som en almindelig person ikke kan håndtere. På det nuværende udviklingstrin er projektet stadig ret råt, ekstremt dårlig dokumentation, mange ting er simpelthen ikke beskrevet. Men samtidig virker det stadig. Jeg håber, at det vil fortsætte med at udvikle sig, og vi får husstandsroutere, der normalt vil kunne kombinere kanaler ud af boksen.
Følg vores udvikler på Instagram
Kilde: www.habr.com