Ahoj všem. Měl jsem původně napsat PR článek o našem produktu ISP Gateway, ale nakonec jsem se rozhodl, že téma pojmu mírně obecněji a snad tak tento článek bude mít nějaký přínos i pro ISP, kteří mají pro rozdělování konektivity vlastní řešení a hodlají ho nadále používat, a dále také pro ty, kteří se třeba jen o danou tématiku zajímají.
Na začátek si ale neodpustím jednu osobní vsuvku: S Miloslavem Sovou, zakladatelem tohoto serveru a předsedou Internetu pro všechny, se znám už od malička a byl jsem u toho, když v době nástupu ISDN v ČR, kdy na západě od nás už dávno měli ADSL, a „bezdrátoví ISP“ u nás byli v plenkách, zakládal Internet pro všechny. Byl jsem i u toho, když většinu své mzdy dal za účet za mobil, protože volal celé hodiny po všech čertech a snažil se příslušné orgány a osoby přesvědčit o tom, že s internetem u nás díky monopolu SPT Telecom není něco v pořádku. Byl jsem u toho, když začal pořádat první konference „Kam kráčí bezdrátové sítě“, později přejmenované na „Kam kráčí telekomunikační sítě“. A bohužel jsem teď i u toho, kdy prochází dost těžkým obdobím. Míla není rozený expert na telekomunikace. Má ale jednu vlastnost, kterou mu většina z nás může závidět. Když si něco vezme do hlavy a ví, že je to správná věc, tak za tím jde a je schopný tomu obětovat velkou část svého života. A tak když se před téměř dvaceti lety naštval na to, že dostupnost internetu pro něj jako pro občana tohoto státu je tristní, rozhodl se, že s tím něco udělá. A to „udělá“ u něj znamenalo ne jen obvyklé nadávání v hospodě, či v lepším případě vybudování malé bezdrátové sítě a propojení pár kamarádů, ale úsilí takové, které by v konečném důsledku pomohlo všem. A jistě nebudu daleko od pravdy, když řeknu, že jen málo lidí v tomto státě mělo za posledních dvacet let takový přínos pro dostupnost internetu u nás, jako on. Díky Mílo. Držíme ti palce a přejeme ti, abys stejně jako posledních skoro dvacet let i nadále spojoval lidi kolem telekomunikací a bojoval za „Internet pro všechny“.
Tak a teď k zábavnějším věcem. Rozdělování konektivity mezi zákazníky se na první pohled může zdát jako triviální záležitost, která si nezaslouží nějakého obsáhlejšího článku či zkoumání. Opak je ale pravdou. Jasně, jsou lidé, kteří konektivitu rozdělují tak, že ji prostě jen přivedou k zákazníkovi. Ono mu to nějak funguje a problém je vyřešen. Pak jsou lidé, kteří chtějí zákazníky kapacitně omezovat, ať už z obchodních či z technických důvodů. Často si vystačí s nastavením portové rychlosti či s jednoduchým shapingem. Opět to nějak funguje a světe div se, dokonce lépe než v prvním případě. Z mých zkušeností je takových lidí velká většina. Ovšem svět paketů a konexí je věc zrádná, data tekoucí vaší infrastrukturou se řídí podle mnoha různých norem a protokolů, kterých většina je z pohledu telekomunikací ne historických, ale přímo prahistorických. Jen pro srovnání: Deset let v telekomunikacích je šílená doba. Jen si vzpomeňte, jaký telefon jste měli před deseti lety a co uměl. A teď si představte, že nejrozšířenější internetový protokol, TCP/IP, je starý přes čtyřicet let. A stejně tak stará je většina základů, na kterých je internet postaven. Ano, během doby se jednotlivé normy a protokoly postupně vylepšovaly a přidávaly se další, ale výsledkem je slušně řečeno chaos, který sice nějakým způsobem funguje, ale má obrovské množství neduhů a nedostatků. V ideálním světě bychom měli jeden protokol, který by byl otevřený, bezpečný, samoopravný, sám by řídil komunikaci dle topologie, umožňoval by různé druhy přenosu dat dle požadavků na latenci či objem, měl by vestavěný systém autentizace, autorizace a účtování, neobsahoval by prvky „security by obscurity“ a díky návrhu by umožňoval zpětně kompatibilní rozšíření v případě potřeby. Místo toho ale máme změť různých protokolů, většina z nich je téměř nepoužívaných, ale zařízení s nimi fungovat musí, pro některé funkce se používá více různých protokolů, některé na sobě více či méně závisí, některé mezi sebou kolidují, takže je celkem jasné, že celý ten guláš má k ideálu daleko. A právě aby tato změť co nejlépe fungovala, je třeba používat různé metody, které alespoň trochu přispějí ke zlepšení takto neutěšeného stavu. A jedním z typů těchto metod jsou metody známé pod označení „Quality of Service (QoS)“, tj. česky „kvalita služby“, pod které spadá i shaping, opět česky „tvarování“. A tím se v tomto článku budeme zabývat.
Co vlastně je ale třeba řešit? Nestačí opravdu jen přivést dostatečnou a kvalitní konektivitu k zákazníkovi? … Bohužel ne. Jak už jsem psal v předchozím odstavci, v ideálním světě nějakého dokonalého superprotokolu by to asi stačilo. Ale realita znamená neustálý boj s výpadky či zahlcením spojů, zpožděním paketů, nestabilitou zpoždění, zhoršenou dostupností služeb, vzájemným ovlivňováním služeb a ve finále tak s nespokojeným zákazníkem, který často má problémy se základním používáním počítače a internetu, natož pak abychom mu přidělávali další problémy nekvalitní konektivitou (omlouvám se všem zákazníkům, ale dlouholetá statistika říká, že většina volání na hotline je problém na straně zákazníka – alespoň tedy v naší firmě). Představte si třeba situaci, kdy zákazníkovi přivedete pomocí bezdrátové sítě třeba 50Mbps. Máte všechno udělané kvalitně, rychlost omezujete pomocí jednoduchého shapingu, používáte plošný dohled všech přípojek, sledujete i provoz, takže vidíte, že váš zákazník žádné výpadky na bezdrátové přípojce nemá a vesele stahuje téměř maximální rychlostí připojení. Vše se zdá naprosto perfektní. Ale najednou ten zákazník zavolá a řekne vám, že se mu pomalu natahují stránky. A že na video z internetu se skoro vůbec nedá koukat, jak se seká. A pokud má ten nebožák telefon přes VoIP, tak ho má zřejmě jen tak pro parádu. Samozřejmě je naštvaný, protože za nefunkčnost internetu přece můžete vždy vy. Trochu vás to v první chvíli naštve, protože letmou kontrolou dohledu zjistíte, že kvalita přípojky je z vaší strany perfektní. Pak se kouknete na graf provozu a hned vám to dojde. Zeptáte se, zda něco nestahuje. Zákazník ale tvrdí, že ne, dokonce je ochotný počítač vypnout. A hle, i po vypnutí graf ukazuje maximální využití přípojky. To už jste skoro doma a ptáte se na to, zda za domácím směrovačem nejsou připojeny další počítače … Samozřejmě že ano. Děti vedle v pokoji si pomocí tisíců konexí přes peer-to-peer sítě stahují nejnovější Linuxové distribuce, aby se zdokonalily v práci s převládajícím operačním systémem dnešní doby, a už se nemohou dočkat, jaké novinky má nová verze jádra a jaké vychytávky nabízí nové KDE 😀 😀 😀 A tak vašemu milému zákazníkovi sdělíte, že má děti donutit, aby stahování vypnuly, a že mu pak vše zase bude fungovat tak, jak má. To se mu ale nebude líbit, protože osvěta a vzdělávání dětí, zvláště pak v oblasti free open source operačních systémů, leží každému zodpovědnému rodiči na srdci. Nakonec se tedy možná smíří s tím, že bude muset při každé nefunkčnosti internetu nejdříve kontrolovat děti, ale velkou radost z toho mít nebude. A ta radost bude o dost menší, když zjistí, že soused, který má konektivitu od jiného poskytovatele internetu, takové problémy nemá. A to má o dvě děti více a každé má svůj počítač! Jak je to možné? …
Ve skutečnosti je to velice prosté. Stačí místo jednoduchého shapingu nasadit shaping s prioritizací, a pak následně použít metody přerovnávání front paketů takové, které jednak dokáží spravedlivě rozdělit maximální šířku pásma mezi jednotlivé datové toky, a dokonce datovým tokům, které se blíží limitu jejich přidělené části pásma, sdělit, že zařízení na jejich koncích musí snížit rychlost vysílání, aby nemuselo docházet k výpadkům paketů z důvodu nedostatečné kapacity, a tím k přerušování datového toku. Tyto metody jsou na Linuxu běžně dostupné, a kdo na Linuxu shapuje, má možnost je celkem jednoduše použít. HFSC vám umožní rozdělit konektivitu včetně řešení různých priorit, navíc můžete u každé služby definovat dvě části křivky, což lze s výhodou využít u sdílených linek k nastavení vyšší priority v první části křivky, aby zákazník, který začal zrovna internet používat, měl větší podíl na sdílené lince, než ten, kdo stahuje už několik hodin naplno. FQ_CoDel vám zase zajistí, že jednotlivé datové toky budou mít nezávisle na sobě „rozumné“ latence díky tomu, že budou v případě blížení se k limitu jejich přidělené části pásma zpomaleny, a to bez výpadku paketu.
Dalším nešvarem, který sice s tématem bezprostředně nesouvisí, ale je třeba na něj dát pozor, protože je mezi poskytovateli internetu poměrně rozšířen, je rozdělování konektivity na zařízeních, které mají více než jedno CPU jádro a přitom neumějí pakety v daném datovém toku přiřadit vždy jen jednomu jádru. Říká se tomu affinita a vícejaderná zařízení (rozuměj zařízení zpracovávající pakety na více jádrech), která ji nemají, z principu věci začnou od relativně malého zatížení přehazovat pořadí paketů v jednotlivých datových tocích. Což je samozřejmě velice špatně. Dvakrát špatně je ale to, že se to na první pohled nepozná, protože například protokol TCP si s tímto dokáže za cenu podstatného snížení propustnosti poradit, takže vám zůstanou občasné výpadky u jiných protokolů, u kterých to až zas tak nepoznáte a často si myslíte, že je chyba někde jinde. Stačí ale dát takové zařízení, které máte na polovině uzlů v síti, na měřák, a trefí vás šlak 😀 Ano, před pár lety jsme si takovým šokem prošli 😀 Už směrování na těchto zařízeních je cesta do pekla, natož pak shaping. A to si přitom dovolím říci, že dané konkrétní zařízení, které mám na mysli, je nejpoužívanější zařízení na shaping v České republice. Modří už vědí, o které zařízení jde 😀
Posledním tématem z oblasti QoS (z mnoha dalších, kterými vás ale teď nebudu nudit), o kterém bych se chtěl v tomto zcela povrchním článku zmínit, je ochrana sítí před DoS a DDoS útoky, skenováním portů, různými botnety apod. Tyto nepříjemnosti určitě nemusím zkušeným provozovatelům internetových sítí představovat. Jistě jste si s nimi užili dost zábavy. Jak už jsem psal na začátku, internet je směsicí postarších protokolů, při jejichž návrhu nikoho ani nenapadlo, že by na síti někdo mohl dělat něco zlého. A tak je internet jako globální struktura ze své podstaty velice zranitelný proti různým druhům zlovolného jednání. Ano, během času se zavedly určité protokoly a metody, které situaci zlepšují, ale jen v několika málo oblastech. Jinak je internet i přes svůj věk skoro čtyřiceti let prakticky bezbranné dítě. Proto se musí na různých místech sítě používat postupy, které když už nezabrání projevům zlovolného jednání, tak alespoň potlačí jejich důsledky. Co se týče ochrany před DoS a DDoS útoky, tak jste se již možná setkali s RTBH (Remotely Triggered Black Hole), což je vlastně postup na blokování cílové IP adresy útoku již na úrovni propojení sítí různých operátorů. Výhodou je, že pokud na nějakou veřejnou IP adresu z vaší sítě útok přijde, je možné daný provoz zablokovat ještě dříve, než se do vaší sítě dostane. Což ochrání nejen cílovou IP adresu, ale i vaši infrastrukturu před zahlcením. Daný postup má ale i několik dost podstatných nevýhod: Zablokování pomocí RTBH obecně není automatické, a tak reakční doba je v řádu minut až desítek minut, tj. k nějaké škodě (výpadkům, přerušení služby, nárůstu latencí apod.) už dojde, než se vám útok podaří zablokovat. Po zablokování pak daná veřejná IP adresa přestane fungovat úplně, což vašeho zákazníka jistě nepotěší. A nebude mít také radost z toho, že po zablokování prakticky nemáte žádný rozumný postup, jak zjistit, zda útok nadále pokračuje, nebo ne. Takže ho pro jistotu necháte zablokovaného dostatečně dlouho, abyste blokování nemuseli dělat pořád dokola. Tolik tedy k RTBH. Další možností je využít různé druhy filtrování na straně dodavatele vaší konektivity. Obecně fungují tak, že internetový provoz je před vstupem do vaší sítě analyzován a v případě detekce útoku je přesměrován na zařízení, které závadný provoz začne odfiltrovávat a zbytek propouští dál do vaší sítě. Výhodou je v tomto případě vyšší rychlost reakce než u RTBH, řádově sekundy až desítky sekund, nevýhodou pak mírný nárůst zpoždění paketů a cena 🙂 No a poslední možností, o které se chci zmínit, je ochrana proti DoS a DDoS útokům, kterou má implementovanou ISP Gateway (hurá, konečně se na konci článku dostáváme k PR). Ta kromě shapingu a mnoha dalších věcí kontinuálně analyzuje provoz a v případě detekce útoku (a nejen útoku, dokáže detekovat i skenování portů apod.) selektivně blokuje jen pakety útoku. Reakční doba se u nejintenzivnějších útoků pohybuje v řádu stovek milisekund, tj. útok je zablokován prakticky okamžitě bez toho, že by došlo k nějaké škodě, a zákazník vesele používá internet dál, aniž by si čehokoliv všiml. K odblokování dochází po definovaném intervalu automaticky (s možností manuálního odblokování), a pokud by útok nadále pokračoval, je opět bleskově zablokován. Nevýhodou je, že ISP Gateway je většinou nasazena až za vyhrazeným okruhem, kterým k vám proudí konektivita od dodavatele, či z nějaké kolokace, takže tento okruh chráněn není. Ale to v dnešní době není až zas takový problém, protože útoků, které by ohrozily 10Gbps okruh, je dnes už naprosté minimum. Vlastně si ani nepamatuji, kdy naposledy na nás tak silný útok šel. Zato malých útoků, které dokáží výrazně zhoršit dostupnost konektivity pro zákazníka, či zahltit bezdrátový přípojný bod nebo nějaký slabší páteřní spoj, detekujeme a blokujeme denně jednotky až desítky. Za normálních okolností bychom o nich vůbec nevěděli, ale díky ISP Gateway máme ochranu i před nimi.
Děkuji všem, kteří dočetli až sem 🙂 Snad jsem vás tímto „PR“ článkem moc nenudil a pokud vás zaujal a chtěli byste se o ISP Gateway dovědět víc, dovolím si vás pozvat na naše stránky www.ispgateway.cz, případně nás můžete kontaktovat přímo a domluvit si schůzku.
Diskuze: 
Diskuze k článku