{"id":53735,"date":"2019-12-09T00:00:00","date_gmt":"2019-12-08T21:00:00","guid":{"rendered":"https:\/\/prohoster.info\/blog\/blog_prohoster\/nastoyashhee-summirovanie-internet-kanalov-openmptcprouter"},"modified":"2020-02-18T14:01:40","modified_gmt":"2020-02-18T11:01:40","slug":"nastoyashhee-summirovanie-internet-kanalov-openmptcprouter","status":"publish","type":"post","link":"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/nastoyashhee-summirovanie-internet-kanalov-openmptcprouter","title":{"rendered":"Egentlig summering af internetkanaler \u2014 OpenMPTCPRouter","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Egentlig
\n
\nKan man kombinere flere internetkanaler til \u00e9n? Der er mange misforst\u00e5elser og myter omkring dette emne, selv erfarne netv\u00e6rksingeni\u00f8rer er ofte i tvivl om, at det er muligt. I de fleste tilf\u00e6lde bliver kanalernes sammenl\u00e6gning fejlagtigt kaldt NAT-balancering eller failover. Men rigtig summation tillader at oprette en enkelt TCP-forbindelse, der samtidigt benytter alle internetkanaler<\/b>, for eksempel ved videotransmission, s\u00e5 udsendelsen ikke afbrydes ved en hvilken som helst afbrudt internetkanal. <\/p>\n

Der findes dyre kommercielle l\u00f8sninger til videotransmission, men s\u00e5danne enheder koster mange tusinde kroner. Artiklen beskriver ops\u00e6tningen af en gratis, \u00e5ben pakke kaldet OpenMPTCPRouter og tager fat p\u00e5 popul\u00e6re myter om kanalernes summation.
\n<\/a><\/noindex><\/p>\n

Myter om summation af kanaler<\/h2>\n

\nDer findes mange almindelige routere, der underst\u00f8tter Multi-WAN-funktionen. Nogle gange kalder producenterne dette kanalaggregation, hvilket ikke helt er korrekt. Mange netv\u00e6rksteknikere tror, at der ikke findes nogen anden form for kanalsammenl\u00e6gning end LACP<\/a><\/noindex> og summation p\u00e5 L2-niveau. Jeg har ofte h\u00f8rt fra folk, der arbejder i telekommunikation, at dette overhovedet ikke er muligt. S\u00e5 lad os pr\u00f8ve at se n\u00e6rmere p\u00e5 de popul\u00e6re myter. <\/p>\n

Balancering p\u00e5 IP-forbindelsesniveau<\/h2>\n

\nDette er den mest tilg\u00e6ngelige og popul\u00e6re m\u00e5de at udnytte flere internetkanaler p\u00e5 samtidig. For enkelhedens skyld forestiller vi os, at du har tre internetudbydere, hvor hver giver dig en faktisk IP-adresse fra sit netv\u00e6rk. Alle disse udbydere er tilsluttet en router med Multi-WAN-funktion. Dette kan v\u00e6re OpenWRT med mwan3-pakken, MikroTik, Ubiquiti eller enhver anden almindelig router, da denne funktion nu ikke er us\u00e6dvanlig.<\/p>\n

For at simulere situationen lad os forestille os, at udbyderne har givet os f\u00f8lgende adresser:<\/p>\n

WAN1 \u2014 11.11.11.11\nWAN2 \u2014 22.22.22.22\nWAN3 \u2014 33.33.33.33\n<\/code><\/pre>\n
\nDet vil sige, at vi opretter forbindelse til en ekstern server example.com<\/b> Gennem hver af udbyderne vil den remote server se tre uafh\u00e6ngige source IP'er for klienten. Balanceringen g\u00f8r 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\u00e5r klienten \u00e5bner et websted, der hypotetisk har tre billeder, indl\u00e6ser den hvert billede gennem en separat udbyder. P\u00e5 webstedets side ser det ud som forbindelse fra tre forskellige IP'er.<\/p>\n
\"Egentlig
\nVed balancering p\u00e5 forbindelsesniveau g\u00e5r hver TCP-forbindelse gennem en separat udbyder.<\/p>\n
Denne balanceringsmetode medf\u00f8rer ofte problemer for brugerne. For eksempel binder mange websteder cookies og tokens strengt til klientens IP-adresse, og hvis den pludselig \u00e6ndres, bliver anmodningen afvist eller klienten logget ud af webstedet. Dette sker ofte i bankklient-systemer og p\u00e5 andre websteder med strenge regler for brugersessioner. Her er et simpelt eksempel: musikfiler p\u00e5 VK.com er kun tilg\u00e6ngelige med en gyldig sessionsn\u00f8gle, der er knyttet til IP-adressen, og kunder, der bruger s\u00e5dan balancering, kan ofte ikke afspille lydfiler, fordi anmodningen gik gennem en anden udbyder, end sessionen er knyttet til.<\/p>\n
\"Egentlig
\nVed downloading af torrents summerer balancering p\u00e5 forbindelsesniveau b\u00e5ndbredden fra alle kanaler.<\/p>\n
Denne balancering muligg\u00f8r summering af hastigheden fra internetkanalen, n\u00e5r der bruges mange forbindelser. For eksempel, hvis hver af de tre udbydere har en hastighed p\u00e5 100 megabit, s\u00e5 f\u00e5r vi 300 megabit ved download af torrents. Dette skyldes, at torrenten \u00e5bner mange forbindelser, der fordeles mellem alle udbydere og dermed udnytter hele kanalen.<\/p>\n
Det er vigtigt at forst\u00e5, at \u00e9n enkelt TCP-forbindelse altid vil g\u00e5 gennem \u00e9n udbyder. Det vil sige, hvis vi downloader en stor fil via HTTP, vil denne forbindelse blive udf\u00f8rt gennem en af udbyderne, og hvis forbindelsen til denne udbyder brydes, vil download ogs\u00e5 stoppe. <\/p>\n
\"Egentlig
\n\u00c9n forbindelse vil altid kun bruge \u00e9n internetkanal.<\/p>\n
Det g\u00e6lder ogs\u00e5 for livestreams. Hvis du streamer video p\u00e5 et hypotetisk Twitch, vil IP-forbindelsesbalancering ikke give nogen s\u00e6rlig fordel, da videostreamen vil blive sendt gennem \u00e9n IP-forbindelse. I dette tilf\u00e6lde, hvis WAN-udbyderen oplever forbindelsesproblemer, som tab af pakker eller hastighedsneds\u00e6ttelse, kan du ikke straks skifte til en anden udbyder. Streaming skal stoppes, og forbindelsen genoprettes. <\/p>\n
Egte kanalsammenl\u00e6gning<\/h2>\n
\nReel kanalsammenl\u00e6gning giver mulighed for at sende \u00e9n forbindelse til hypotetiske Twitch gennem alle udbydere, s\u00e5ledes at hvis en af udbyderne g\u00e5r ned, vil forbindelsen ikke blive brudt. Dette er overraskende kompliceret og har stadig ikke en optimal l\u00f8sning. Mange ved endda ikke, at dette er muligt! <\/p>\n
If\u00f8lge de tidligere illustrationer husker vi, at den hypotetiske Twitch-server kun kan modtage videostreamen fra \u00e9n 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\u00e5 dette har vi brug for en sammenl\u00e6gningsserver, der vil terminere alle vores forbindelser og kombinere dem til \u00e9n.<\/p>\n
\"Egentlig
\nSammenl\u00e6gningsserveren aggregerer alle kanaler til \u00e9n tunnel. Alle forbindelser sker fra adressen p\u00e5 sammenl\u00e6gningsserveren.<\/p>\n
I en s\u00e5dan ordning anvendes alle udbydere, og afbrydelse af en af dem vil ikke for\u00e5rsage brud p\u00e5 forbindelsen til Twitch-serveren. I bund og grund er det en s\u00e6rlig VPN-tunnel, der under motorhjelmen har flere internetkanaler. Hovedm\u00e5let med en s\u00e5dan ordning er at opn\u00e5 den bedst mulige forbindelseskvalitet. Hvis der opst\u00e5r problemer med en af udbyderne, tab af pakker eller \u00f8gede forsinkelser, skal dette ikke p\u00e5virke forbindelseskvaliteten, da belastningen automatisk vil blive fordelt p\u00e5 andre, mere kvalitetskanaler, der er til r\u00e5dighed. <\/p>\n
Kommersielle l\u00f8sninger<\/h3>\n
\nDette problem har l\u00e6nge bekymret dem, der live-streamer begivenheder og ikke har adgang til kvalitetsinternet. Der findes flere kommercielle l\u00f8sninger til s\u00e5danne opgaver, for eksempel producerer virksomheden Teradek s\u00e5danne enorme routere, hvor der kan inds\u00e6ttes stakke af USB-modemer:<\/p>\n
\"Egentlig
\nRouter til videostreaming med kanal-sammenl\u00e6gning funktion<\/p>\n
I s\u00e5danne enheder er der normalt indbygget mulighed for at fange videosignalet via HDMI eller SDI. Sammen med routeren s\u00e6lges et abonnement p\u00e5 tjenesten til kanal-sammenl\u00e6gning samt til behandling af videostr\u00f8m, omkodning af den og retransmission. Priserne p\u00e5 s\u00e5danne enheder starter fra 2.000 $ med modempakker, plus et separat abonnement p\u00e5 tjenesten. <\/p>\n
Nogle gange ser det ret skr\u00e6mmende ud:<\/p>\n
\"Egentlig
\n<\/p>\n
Konfigurerer OpenMPTCPRouter<\/h2>\n
\nProtokol MP-TCP<\/a><\/noindex> (MultiPath TCP) blev opfundet for at muligg\u00f8re tilslutning p\u00e5 flere kanaler samtidig. For eksempel underst\u00f8tter det iOS<\/a><\/noindex> og kan samtidig forbinde til en fjernserver via WiFi og mobilnetv\u00e6rk. Det er vigtigt at forst\u00e5, at dette ikke er to separate TCP-forbindelser, men netop \u00e9n forbindelse, der er etableret gennem to kanaler. For at dette skal fungere, skal den fjerntliggende server ogs\u00e5 underst\u00f8tte MPTCP.<\/p>\n
OpenMPTCPRouter<\/a><\/noindex> er et open source-projekt til software-router, der reelt kan sammenl\u00e6gge kanaler. Forfatterne erkl\u00e6rer, at projektet er i alpha-status, men det kan allerede bruges. Det best\u00e5r af to dele - en sammenl\u00e6gningsserver, der hostes p\u00e5 internettet, og en router, som flere internetudbydere og klientenheder s\u00e5som computere og telefoner forbinder til. Raspberry Pi, nogle WiFi-routere eller en almindelig computer kan fungere som bruger-router. Der findes pr\u00e6byggede versioner til forskellige platforme, hvilket er meget praktisk.<\/p>\n
\"Egentlig
\nPrincipperne for OpenMPTCPRouter<\/p>\n
Konfiguration af sammenl\u00e6gningsserveren<\/h2>\n
\nSammenl\u00e6gningsserveren placeres p\u00e5 internettet og terminerer forbindelser fra alle kanaler fra klientrouteren til \u00e9n. IP-adressen p\u00e5 denne server vil v\u00e6re den offentlige adresse ved udgang til internettet gennem OpenMPTCPRouter. <\/p>\n
Til denne opgave vil vi bruge en VPS-server p\u00e5 Debian 10.<\/p>\n
Krav til sammenl\u00e6gningsserveren:<\/p>\n