Er det mulig å kombinere flere internettkanaler til én? Det er mange misoppfatninger og myter rundt dette emnet; selv erfarne nettverksingeniører vet ofte ikke at dette er mulig. I de fleste tilfeller kalles lenkeaggregering feilaktig balansering på NAT-nivå eller failover. Men ekte summering tillater det starte én enkelt TCP-tilkobling samtidig over alle Internett-kanaler, for eksempel videokringkasting slik at hvis noen av internettkanalene blir avbrutt, vil ikke sendingen bli avbrutt.
Det finnes dyre kommersielle løsninger for videosendinger, men slike enheter koster mange kilobucks. Artikkelen beskriver hvordan du konfigurerer den gratis OpenMPTCPRouter-pakken med åpen kildekode og tar for seg populære myter om kanalsummering.
Myter om kanalsummering
Det er mange hjemmerutere som støtter Multi-WAN-funksjonen. Noen ganger kaller produsenter denne kanalen summering, noe som ikke er helt sant. Mange nettverkere mener at i tillegg til og summering på L2-nivå, finnes det ingen annen kanalaggregering. Jeg har ofte hørt at dette er generelt umulig fra folk som jobber innen telekom. Derfor, la oss prøve å forstå populære myter.
Balansering på IP-tilkoblingsnivå
Dette er den rimeligste og mest populære måten å bruke flere Internett-kanaler på samtidig. For enkelhets skyld, la oss forestille oss at du har tre Internett-leverandører, som hver gir deg en ekte IP-adresse fra nettverket sitt. Alle disse leverandørene er koblet til en ruter som støtter Multi-WAN-funksjonen. Dette kan være OpenWRT med mwan3-pakken, mikrotik, ubiquiti eller en hvilken som helst annen husholdningsruter, siden et slikt alternativ ikke lenger er uvanlig.
For å simulere situasjonen, la oss forestille oss at leverandørene ga oss følgende adresser:
WAN1 — 11.11.11.11
WAN2 — 22.22.22.22
WAN2 — 33.33.33.33
Det vil si å koble til en ekstern server example.com Gjennom hver av leverandørene vil den eksterne serveren se tre uavhengige kilde-IP-klienter. Balansering lar deg dele belastningen på tvers av kanaler og bruke alle tre samtidig. For enkelhets skyld, la oss forestille oss at vi deler belastningen likt mellom alle kanaler. Som et resultat, når en klient åpner et nettsted med tre bilder, laster han ned hvert bilde gjennom en separat leverandør. På sidesiden ser det ut som tilkoblinger fra tre forskjellige IP-er.
Ved balansering på tilkoblingsnivå går hver TCP-tilkobling gjennom en egen leverandør.
Denne balanseringsmodusen forårsaker ofte problemer for brukerne. For eksempel binder mange nettsteder informasjonskapsler og tokens strengt til klientens IP-adresse, og hvis den plutselig endres, blir forespørselen avvist eller klienten logges ut av nettstedet. Dette er ofte gjengitt i klient-banksystemer og andre nettsteder med strenge brukersesjonsregler. Her er et enkelt illustrerende eksempel: musikkfiler på VK.com er kun tilgjengelig med en gyldig sesjonsnøkkel, som er knyttet til en IP, og klienter som bruker slik balansering spiller ofte ikke av lyd fordi forespørselen ikke gikk gjennom leverandøren som økten er knyttet.
Når du laster ned torrenter, oppsummerer balansering av tilkoblingsnivå båndbredden til alle kanaler
Denne balanseringen lar deg få summen av hastigheten til Internett-kanalen når du bruker flere tilkoblinger. For eksempel, hvis hver av de tre leverandørene har en hastighet på 100 megabit, vil vi få 300 megabit når du laster ned torrenter. Fordi en torrent åpner mange tilkoblinger, som er fordelt mellom alle tilbydere og til slutt utnytter hele kanalen.
Det er viktig å forstå at én enkelt TCP-tilkobling alltid vil gå gjennom kun én leverandør. Det vil si at hvis vi laster ned én stor fil via HTTP, så vil denne forbindelsen gjøres gjennom en av leverandørene, og hvis forbindelsen med denne leverandøren brytes, vil også nedlastingen bryte.
Én tilkobling vil alltid bruke bare én Internett-kanal
Dette gjelder også for videosendinger. Hvis du kringkaster streaming video til en slags betinget Twitch, vil balansering på nivået av IP-tilkoblinger ikke gi noen spesiell fordel, siden videostrømmen vil bli kringkastet innenfor én IP-tilkobling. I dette tilfellet, hvis WAN 3-leverandøren begynner å få problemer med kommunikasjon, for eksempel pakketap eller redusert hastighet, vil du ikke umiddelbart kunne bytte til en annen leverandør. Sendingen må stoppes og kobles til igjen.
Ekte kanaloppsummering
Ekte kanalsummering gjør det mulig å kjøre én tilkobling til en betinget Twitch gjennom alle leverandørene samtidig på en slik måte at hvis noen av leverandørene bryter sammen, vil tilkoblingen ikke bli avbrutt. Dette er et overraskende vanskelig problem som fortsatt ikke har en optimal løsning. Mange vet ikke engang at dette er mulig!
Fra de tidligere illustrasjonene husker vi at den betingede Twitch-serveren kan motta en videostrøm fra oss fra kun én kilde-IP-adresse, noe som betyr at den alltid må være konstant for oss, uavhengig av hvilke leverandører som har falt fra og hvilke som fungerer. For å oppnå dette trenger vi en summeringsserver som vil avslutte alle tilkoblingene våre og kombinere dem til én.
Summeringsserveren samler alle kanaler i én tunnel. Alle tilkoblinger kommer fra den summerende serveradressen
I denne ordningen brukes alle leverandører, og deaktivering av noen av dem vil ikke føre til tap av kommunikasjon med Twitch-serveren. I hovedsak er dette en spesiell VPN-tunnel, under panseret som det er flere Internett-kanaler samtidig. Hovedoppgaven til en slik ordning er å oppnå kommunikasjonskanalen av høyeste kvalitet. Hvis en av leverandørene begynner å få problemer, tap av pakker, økte forsinkelser, så bør ikke dette påvirke kvaliteten på kommunikasjonen på noen måte, siden lasten automatisk fordeles over andre, bedre kanaler som er tilgjengelige.
Kommersielle løsninger
Dette problemet har lenge plaget de som sender direktebegivenheter og ikke har tilgang til Internett av høy kvalitet. For slike oppgaver er det flere kommersielle løsninger, for eksempel lager selskapet Teradek slike monstrøse rutere som pakker med USB-modemer settes inn i:
Ruter for videosendinger med kanalsummeringsfunksjon
Slike enheter har vanligvis en innebygd evne til å fange opp videosignaler via HDMI eller SDI. Sammen med ruteren selges et abonnement på kanalsummeringstjenesten, samt behandle videostrømmen, omkode den og videresende den. Prisen på slike enheter starter fra $2k med et sett med modemer, pluss et separat abonnement på tjenesten.
Noen ganger ser det ganske skummelt ut:
Sette opp OpenMPTCPRouter
Protokoll (MultiPath TCP) ble oppfunnet for å kunne koble til via flere kanaler samtidig. For eksempel hans og kan samtidig koble til en ekstern server via WiFi og via et mobilnettverk. Det er viktig å forstå at dette ikke er to separate TCP-forbindelser, men snarere én forbindelse etablert over to kanaler samtidig. For at dette skal fungere, må den eksterne serveren også støtte MPTCP.
er et åpen kildekodeprogramvareruterprosjekt som gir mulighet for ekte kanaloppsummering. Forfatterne opplyser at prosjektet er i alfaversjonsstatus, men det kan allerede tas i bruk. Den består av to deler - en summeringsserver, som er plassert på Internett og en ruter, som flere Internett-leverandører og selve klientenhetene er koblet til: datamaskiner, telefoner. Den tilpassede ruteren kan være en Raspberry Pi, noen WiFi-rutere eller en vanlig datamaskin. Det er ferdige sammenstillinger for ulike plattformer, noe som er veldig praktisk.
Hvordan OpenMPTCPRouter fungerer
Sette opp en oppsummeringsserver
Summeringsserveren er plassert på Internett og avslutter tilkoblinger fra alle kanalene til klientruteren til én. IP-adressen til denne serveren vil være den eksterne adressen når du får tilgang til Internett via OpenMPTCPRouter.
For denne oppgaven vil vi bruke en VPS-server på Debian 10.
Krav til summeringsserveren:
- MPTCP fungerer ikke på OpenVZ-virtualisering
- Det skal være mulig å installere din egen Linux-kjerne
Serveren distribueres ved å utføre én kommando. Skriptet vil installere en kjerne med mptcp-støtte og alle nødvendige pakker. Installasjonsskript er tilgjengelig for Ubuntu og Debian.
wget -O - http://www.openmptcprouter.com/server/debian10-x86_64.sh | sh
Resultatet av en vellykket serverinstallasjon.
Vi lagrer passordene, vi trenger dem for å konfigurere klientruteren og starte på nytt. Det er viktig å huske på at etter installasjonen vil SSH være tilgjengelig på port 65222. Etter omstart må vi sørge for at vi har startet opp med den nye kjernen
uname -a
Linux test-server.local 4.19.67-mptcp
Vi ser inskripsjonen mptcp ved siden av versjonsnummeret, som betyr at kjernen ble riktig installert.
Sette opp en klientruter
På ferdige bygg er tilgjengelige for noen plattformer, for eksempel Raspberry Pi, Banana Pi, Lynksys-rutere og virtuelle maskiner.
Denne delen av openmptcprouter er basert på OpenWRT, og bruker LuCI som et grensesnitt, kjent for alle som noen gang har møtt OpenWRT. Distribusjonen veier ca 50MB!
Som testbenk skal jeg bruke en Raspberry Pi og flere USB-modemer med forskjellige operatører: MTS og Megafon. Jeg tror ikke jeg trenger å fortelle deg hvordan du skriver et bilde til et SD-kort.
I utgangspunktet er Ethernet-porten i Raspberry Pi konfigurert som LAN med en statisk IP-adresse 192.168.100.1. For å unngå å fikle med ledninger på skrivebordet koblet jeg Raspberry Pi til et WiFi-tilgangspunkt og satte datamaskinens WiFi-adapter til en statisk adresse 192.168.100.2. DHCP-serveren er ikke aktivert som standard, så du må bruke statiske adresser.
Nå kan du logge på nettgrensesnittet
Når du logger på for første gang, vil systemet be deg angi et root-passord; SSH vil være tilgjengelig med samme passord.
I LAN-innstillingene kan du angi ønsket subnett og aktivere DHCP-serveren.
Jeg bruker modemer som er definert som USB Ethernet-grensesnitt med en separat DHCP-server, så dette krevde installasjon . Prosedyren er identisk med å sette opp modemer i vanlig OpenWRT, så jeg vil ikke dekke det her.
Deretter må du konfigurere WAN-grensesnittene. Opprinnelig opprettet systemet to virtuelle grensesnitt WAN1 og WAN2. De må tildeles en fysisk enhet, i mitt tilfelle er dette navnene på USB-modemgrensesnittene.
For å unngå forvirring med grensesnittnavn, anbefaler jeg å se dmesg-meldinger mens du kobler til via SSH.
Siden modemene mine selv fungerer som rutere, og selv har en DHCP-server, måtte jeg endre innstillingene for deres interne nettverksområder og deaktivere DHCP-serveren, fordi begge modemene i utgangspunktet utsteder adresser fra samme nettverk, og dette forårsaker en konflikt.
OpenMPTCPRouter krever at WAN-grensesnittadressene er statiske, så vi kommer opp med subnett for modemene og konfigurerer dem i system → openmptcprouter → grensesnittinnstillinger-menyen. Her må du spesifisere IP-adressen og servernøkkelen som ble oppnådd under installasjonen av summeringsserveren.
Hvis oppsettet er vellykket, skal et lignende bilde vises på statussiden. Det kan ses at ruteren var i stand til å nå summeringsserveren og begge kanalene fungerer normalt.
Standardmodusen er shadowsocks + mptcp. Dette er en proxy som pakker alle tilkoblinger i seg selv. Den er i utgangspunktet konfigurert til å behandle kun TCP, men UDP kan også aktiveres.
Hvis det ikke er noen feil på statussiden, kan oppsettet anses som fullført.
Hos noen leverandører kan det oppstå en situasjon når mptcp-flagget er kuttet av langs trafikkbanen, da vil følgende feil vises:
I dette tilfellet kan du bruke en annen driftsmodus, uten å bruke MPTCP, mer om dette .
Konklusjon
OpenMPTCPRouter-prosjektet er veldig interessant og viktig, siden det kanskje er den eneste åpne omfattende løsningen på kanalsummeringsproblemet. Alt annet er enten tett lukket og proprietært, eller ganske enkelt separate moduler som en vanlig person ikke kan forstå. På det nåværende utviklingsstadiet er prosjektet fortsatt ganske grovt, dokumentasjonen er ekstremt dårlig, mange ting er rett og slett ikke beskrevet. Men samtidig fungerer det fortsatt. Jeg håper at det vil fortsette å utvikle seg, og vi vil få husholdningsrutere som vil være i stand til å kombinere kanaler riktig ut av esken.
Følg utvikleren vår på Instagram
Kilde: www.habr.com