Vai ir iespējams apvienot vairākus interneta kanālus vienā? Par šo tēmu ir daudz nepareizu priekšstatu un mītu; pat pieredzējuši tīkla inženieri bieži nezina, ka tas ir iespējams. Vairumā gadījumu saišu apkopošanu kļūdaini sauc par balansēšanu NAT līmenī vai kļūmjpārlēci. Bet reāla summēšana ļauj vienā TCP savienojumā vienlaikus pa visiem interneta kanāliem, piemēram, video apraide, lai, ja kāds no interneta kanāliem tiktu pārtraukts, apraide netiktu pārtraukta.
Ir dārgi komerciāli risinājumi video pārraidēm, taču šādas ierīces maksā daudzus kilobakus. Rakstā ir aprakstīts, kā konfigurēt bezmaksas atvērtā koda OpenMPTCPRuter pakotni, un apskatīti populāri mīti par kanālu summēšanu.
Mīti par kanālu summēšanu
Ir daudzi mājas maršrutētāji, kas atbalsta Multi-WAN funkciju. Dažreiz ražotāji šo kanālu sauc par summēšanu, kas nav pilnīgi taisnība. Daudzi tīklu veidotāji uzskata, ka papildus un summēšana L2 līmenī, cita kanālu apkopojuma nepastāv. Es bieži esmu dzirdējis, ka tas parasti nav iespējams no cilvēkiem, kas strādā telekomunikāciju jomā. Tāpēc mēģināsim izprast populāros mītus.
Balansēšana IP savienojuma līmenī
Šis ir vispieejamākais un populārākais veids, kā vienlaikus izmantot vairākus interneta kanālus. Vienkāršības labad iedomāsimies, ka jums ir trīs interneta pakalpojumu sniedzēji, no kuriem katrs sniedz reālu IP adresi no sava tīkla. Visi šie pakalpojumu sniedzēji ir savienoti ar maršrutētāju, kas atbalsta funkciju Multi-WAN. Tas varētu būt OpenWRT ar mwan3 pakotni, mikrotik, ubiquiti vai jebkuru citu mājsaimniecības maršrutētāju, jo šāda iespēja vairs nav nekas neparasts.
Lai simulētu situāciju, iedomāsimies, ka pakalpojumu sniedzēji mums deva šādas adreses:
WAN1 — 11.11.11.11
WAN2 — 22.22.22.22
WAN2 — 33.33.33.33
Tas ir, savienojuma izveide ar attālo serveri example.com Izmantojot katru pakalpojumu sniedzēju, attālais serveris redzēs trīs neatkarīgus avota IP klientus. Balansēšana ļauj sadalīt slodzi pa kanāliem un izmantot visus trīs vienlaikus. Vienkāršības labad iedomāsimies, ka mēs sadalām slodzi vienādi starp visiem kanāliem. Tā rezultātā, kad klients atver vietni ar trim attēliem, viņš katru attēlu lejupielādē, izmantojot atsevišķu pakalpojumu sniedzēju. Vietnes pusē tas izskatās kā savienojumi no trim dažādiem IP.
Balansējot savienojuma līmenī, katrs TCP savienojums iet caur atsevišķu pakalpojumu sniedzēju.
Šis balansēšanas režīms lietotājiem bieži rada problēmas. Piemēram, daudzas vietnes sīkfailus un marķierus stingri saista ar klienta IP adresi, un, ja tā pēkšņi mainās, pieprasījums tiek noraidīts vai klients tiek izrakstīts no vietnes. To bieži atkārto klientu bankas sistēmās un citās vietnēs ar stingriem lietotāja sesijas noteikumiem. Šeit ir vienkāršs ilustratīvs piemērs: mūzikas faili vietnē VK.com ir pieejami tikai ar derīgu sesijas atslēgu, kas ir saistīta ar IP, un klienti, kuri izmanto šādu balansēšanu, bieži neatskaņo audio, jo pieprasījums netika nosūtīts caur pakalpojumu sniedzēju, kuram sesija ir neizšķirta.
Lejupielādējot torrentus, savienojuma līmeņa balansēšana summē visu kanālu joslas platumu
Šī balansēšana ļauj iegūt interneta kanāla ātruma summēšanu, izmantojot vairākus savienojumus. Piemēram, ja katram no trim pakalpojumu sniedzējiem ir 100 megabitu ātrums, tad, lejupielādējot torrentus, mēs iegūsim 300 megabitus. Tā kā torrents atver daudzus savienojumus, kas tiek izplatīti starp visiem pakalpojumu sniedzējiem un galu galā izmanto visu kanālu.
Ir svarīgi saprast, ka viens TCP savienojums vienmēr darbosies tikai caur vienu pakalpojumu sniedzēju. Tas ir, ja mēs lejupielādējam vienu lielu failu, izmantojot HTTP, tad šis savienojums tiks izveidots caur vienu no pakalpojumu sniedzējiem, un, ja savienojums ar šo pakalpojumu sniedzēju tiek pārtraukts, lejupielāde arī pārtrūks.
Viens savienojums vienmēr izmantos tikai vienu interneta kanālu
Tas attiecas arī uz video pārraidēm. Ja straumējat video uz kādu nosacītu Twitch, tad balansēšana IP savienojumu līmenī nekādu īpašu labumu nedos, jo video straume tiks pārraidīta viena IP savienojuma ietvaros. Šādā gadījumā, ja WAN 3 nodrošinātājam sāk rasties problēmas ar komunikāciju, piemēram, pakešu zudums vai samazināts ātrums, jūs nevarēsit uzreiz pārslēgties uz citu pakalpojumu sniedzēju. Pārraide būs jāpārtrauc un atkal jāpievieno.
Patiesa kanālu summēšana
Reāla kanālu summēšana ļauj palaist vienu savienojumu ar nosacīto Twitch caur visiem pakalpojumu sniedzējiem uzreiz tā, ka, ja kāds no pakalpojumu sniedzējiem sabojājas, savienojums netiks pārtraukts. Šī ir pārsteidzoši sarežģīta problēma, kurai joprojām nav optimāla risinājuma. Daudzi cilvēki pat nezina, ka tas ir iespējams!
No iepriekšējām ilustrācijām mēs atceramies, ka nosacītais Twitch serveris var saņemt video straumi no mums tikai no vienas avota IP adreses, kas nozīmē, ka tai mums vienmēr ir jābūt nemainīgai neatkarīgi no tā, kuri pakalpojumu sniedzēji ir atkrituši un kuri darbojas. Lai to panāktu, mums ir nepieciešams summēšanas serveris, kas pārtrauks visus mūsu savienojumus un apvienos tos vienā.
Summēšanas serveris visus kanālus apkopo vienā tunelī. Visi savienojumi rodas no summēšanas servera adreses
Šajā shēmā tiek izmantoti visi pakalpojumu sniedzēji, un jebkura no tiem atspējošana neizraisīs sakaru zudumu ar Twitch serveri. Būtībā šis ir īpašs VPN tunelis, zem kura pārsega vienlaikus atrodas vairāki interneta kanāli. Šādas shēmas galvenais uzdevums ir iegūt visaugstākās kvalitātes sakaru kanālu. Ja kādam no pakalpojumu sniedzējiem sākas problēmas, pakešu zudumi, palielināti kavējumi, tad tas nekādā veidā nedrīkst ietekmēt sakaru kvalitāti, jo slodze automātiski tiks sadalīta pa citiem, labākiem pieejamajiem kanāliem.
Komerciālie risinājumi
Šī problēma jau sen satrauc tos, kuri pārraida notikumus tiešraidē un kuriem nav piekļuves augstas kvalitātes internetam. Šādiem uzdevumiem ir vairāki komerciāli risinājumi, piemēram, uzņēmums Teradek izgatavo tādus briesmīgus maršrutētājus, kuros tiek ievietoti USB modemu pakotnes:
Maršrutētājs video pārraidēm ar kanālu summēšanas funkciju
Šādām ierīcēm parasti ir iebūvēta iespēja uztvert video signālus, izmantojot HDMI vai SDI. Kopā ar maršrutētāju tiek pārdots kanālu summēšanas pakalpojuma abonements, kā arī video straumes apstrāde, pārkodēšana un tālāka pārraide. Šādu ierīču cena sākas no USD 2k ar modemu komplektu, kā arī atsevišķu pakalpojuma abonementu.
Dažreiz tas izskatās diezgan biedējoši:
OpenMPTCPRuter iestatīšana
Protokols (MultiPath TCP) tika izgudrots, lai vienlaikus varētu izveidot savienojumu pa vairākiem kanāliem. Piemēram, viņa un vienlaikus var izveidot savienojumu ar attālo serveri, izmantojot WiFi un mobilo tīklu. Ir svarīgi saprast, ka tie nav divi atsevišķi TCP savienojumi, bet gan viens savienojums, kas izveidots pa diviem kanāliem vienlaikus. Lai tas darbotos, attālajam serverim ir jāatbalsta arī MPTCP.
ir atvērtā pirmkoda programmatūras maršrutētāja projekts, kas nodrošina patiesu kanālu kopsavilkumu. Autori norāda, ka projekts ir alfa versijas statusā, taču to jau var izmantot. Tas sastāv no divām daļām – summēšanas servera, kas atrodas internetā un maršrutētāja, kuram ir pieslēgti vairāki interneta pakalpojumu sniedzēji un pašas klienta ierīces: datori, telefoni. Pielāgotais maršrutētājs var būt Raspberry Pi, daži WiFi maršrutētāji vai parasts dators. Ir jau gatavi komplekti dažādām platformām, kas ir ļoti ērti.
Kā darbojas OpenMPTCPRuter
Kopsavilkuma servera iestatīšana
Summēšanas serveris atrodas internetā un pārtrauc savienojumus no visiem klienta maršrutētāja kanāliem vienā. Šī servera IP adrese būs ārējā adrese, piekļūstot internetam, izmantojot OpenMPTCPRuter.
Šim uzdevumam mēs izmantosim VPS serveri vietnē Debian 10.
Prasības summēšanas serverim:
- MPTCP nedarbojas OpenVZ virtualizācijā
- Vajadzētu būt iespējai instalēt savu kodolu Linux
Serveris tiek izvietots, palaižot vienu komandu. Skripts instalēs kodolu ar mptcp atbalstu un visas nepieciešamās pakotnes. Instalēšanas skripti ir pieejami priekš Ubuntu и Debian.
wget -O - http://www.openmptcprouter.com/server/debian10-x86_64.sh | sh
Veiksmīgas servera instalēšanas rezultāts.
Mēs saglabājam paroles, mums tās būs nepieciešamas, lai konfigurētu klienta maršrutētāju un atsāknētu. Ir svarīgi paturēt prātā, ka pēc instalēšanas SSH būs pieejams portā 65222. Pēc pārstartēšanas mums ir jāpārliecinās, ka mēs sāknējām ar jauno kodolu.
uname -a
Linux test-server.local 4.19.67-mptcp
Mēs redzam uzrakstu mptcp blakus versijas numuram, kas nozīmē, ka kodols tika instalēts pareizi.
Klienta maršrutētāja iestatīšana
uz Dažām platformām ir pieejamas gatavas versijas, piemēram, Raspberry Pi, Banana Pi, Lynksys maršrutētāji un virtuālās mašīnas.
Šī openmptcprouter daļa ir balstīta uz OpenWRT, izmantojot LuCI kā interfeisu, kas ir pazīstams ikvienam, kurš kādreiz ir saskāries ar OpenWRT. Izplatījums sver aptuveni 50 MB!
Kā testa stendu izmantošu Raspberry Pi un vairākus USB modemus ar dažādiem operatoriem: MTS un Megafon. Es nedomāju, ka man jums jāsaka, kā ierakstīt attēlu SD kartē.
Sākotnēji Raspberry Pi Ethernet ports ir konfigurēts kā LAN ar statisku IP adresi 192.168.100.1. Lai nekratītos ar vadiem uz galda, Raspberry Pi pievienoju WiFi piekļuves punktam un iestatīju datora WiFi adapteri uz statisku adresi. 192.168.100.2. DHCP serveris pēc noklusējuma nav iespējots, tāpēc ir jāizmanto statiskas adreses.
Tagad varat pieteikties tīmekļa saskarnē
Piesakoties pirmo reizi, sistēma lūgs iestatīt root paroli; SSH būs pieejams ar to pašu paroli.
LAN iestatījumos varat iestatīt vajadzīgo apakštīklu un iespējot DHCP serveri.
Es izmantoju modemus, kas ir definēti kā USB Ethernet saskarnes ar atsevišķu DHCP serveri, tāpēc šī instalēšana bija nepieciešama . Procedūra ir identiska modemu iestatīšanai parastajā OpenWRT, tāpēc es to šeit neaplūkošu.
Tālāk jums jākonfigurē WAN saskarnes. Sākotnēji sistēma izveidoja divas virtuālās saskarnes WAN1 un WAN2. Viņiem ir jāpiešķir fiziska ierīce, manā gadījumā tie ir USB modema saskarņu nosaukumi.
Lai izvairītos no sajaukšanas ar saskarņu nosaukumiem, iesaku skatīt dmesg ziņojumus, kad tiek izveidots savienojums, izmantojot SSH.
Tā kā mani modemi paši darbojas kā maršrutētāji un pašiem ir DHCP serveris, nācās mainīt to iekšējo tīklu diapazonu iestatījumus un atspējot DHCP serveri, jo sākotnēji abi modemi izdod adreses no viena tīkla un tas rada konfliktu.
OpenMPTCPRuter pieprasa, lai WAN interfeisa adreses būtu statiskas, tāpēc mēs izstrādājam modemu apakštīklus un konfigurējam tos sistēmas → openmptcprouter → interfeisa iestatījumu izvēlnē. Šeit jānorāda summēšanas servera instalēšanas laikā iegūtā IP adrese un servera atslēga.
Ja iestatīšana ir veiksmīga, statusa lapā jāparādās līdzīgam attēlam. Redzams, ka rūteris spējis sasniegt summēšanas serveri un abi kanāli strādā normāli.
Noklusējuma režīms ir shadowsocks + mptcp. Šis ir starpniekserveris, kas sevī ietver visus savienojumus. Sākotnēji tas ir konfigurēts, lai apstrādātu tikai TCP, taču var iespējot arī UDP.
Ja statusa lapā nav kļūdu, iestatīšanu var uzskatīt par pabeigtu.
Ar dažiem pakalpojumu sniedzējiem var rasties situācija, kad satiksmes ceļā tiek nogriezts mptcp karogs, tad parādīsies šāda kļūda:
Šajā gadījumā varat izmantot citu darbības režīmu, neizmantojot MPTCP, vairāk par to .
Secinājums
OpenMPTCPRuter projekts ir ļoti interesants un svarīgs, jo tas, iespējams, ir vienīgais atvērtais visaptverošais risinājums kanālu summēšanas problēmai. Viss pārējais ir vai nu cieši noslēgts un patentēts, vai vienkārši atsevišķi moduļi, ko parasts cilvēks nevar saprast. Pašreizējā izstrādes stadijā projekts vēl ir diezgan jēls, dokumentācija ir ārkārtīgi slikta, daudzas lietas vienkārši nav aprakstītas. Bet tajā pašā laikā tas joprojām darbojas. Ceru, ka tas turpinās attīstīties, un mēs iegūsim mājsaimniecības maršrutētājus, kas spēs pareizi apvienot kanālus no kastes.
Sekojiet mūsu izstrādātājam Instagram
Avots: www.habr.com
