Vyzval mě k tomuto příspěvku .
Cituji to zde:
dnes v 18: 53
Dnes jsem byl s poskytovatelem spokojen. Spolu s aktualizací systému blokování stránek byl zabanován jeho mailer mail.ru.Od rána volám na technickou podporu, ale nemohou nic dělat. Poskytovatel je malý a zřejmě ho blokují vyšší poskytovatelé. Také jsem zaznamenal zpomalení otevírání všech stránek, možná nainstalovali nějaké křivé DLP? Dříve nebyly s přístupem žádné problémy. Zničení RuNetu se děje přímo před mýma očima...
Faktem je, že se zdá, že jsme stejný poskytovatel :)
A vskutku Téměř jsem uhodl příčinu problémů s mail.ru (ačkoli jsme v něco takového dlouho odmítali věřit).
To, co následuje, bude rozděleno do dvou částí:
- důvody našich současných problémů s mail.ru a vzrušující snaha je najít
- existence ISP v dnešní realitě, stabilita suverénního RuNetu.
Problémy s přístupností na mail.ru
Oh, to je docela dlouhý příběh.
Faktem je, že za účelem implementace požadavků státu (podrobněji ve druhé části) jsme zakoupili, nakonfigurovali a nainstalovali některá zařízení - jak pro filtrování zakázaných zdrojů, tak pro implementaci předplatitelů.
Před časem jsme konečně přestavěli jádro sítě tak, aby veškerý účastnický provoz procházel tímto zařízením striktně správným směrem.
Před pár dny jsme na něm zapnuli zakázané filtrování (přičemž starý systém zůstal funkční) - zdálo se, že je vše v pořádku.
Dále postupně začali umožňovat NAT na tomto zařízení pro různé části účastníků. Podle vzhledu se také zdálo, že všechno jde dobře.
Ale dnes, po aktivaci NAT na zařízení pro další část předplatitelů, jsme hned od rána čelili slušnému počtu stížností na nedostupnost nebo částečnou dostupnost a další zdroje Mail Ru Group.
Začali kontrolovat: něco někde někdy, občas posílá v reakci na požadavky výhradně do sítí mail.ru. Navíc posílá chybně vygenerovaný (bez ACK), evidentně umělý TCP RST. Takhle to vypadalo:
První myšlenky se přirozeně týkaly nového vybavení: příšerné DPI, nedůvěra v něj, nikdy nevíte, co dokáže – ostatně TCP RST je mezi blokovacími nástroji poměrně běžná věc.
Předpoklad Také jsme předložili myšlenku, že někdo „nadřazený“ filtruje, ale okamžitě jsme to zavrhli.
Za prvé, máme dostatečně zdravé uplinky, abychom nemuseli takhle trpět :)
Za druhé, jsme spojeni s několika v Moskvě a provoz na mail.ru prochází přes ně - a nemají ani odpovědnost, ani žádný jiný motiv filtrovat provoz.
Další půlka dne se věnovala tomu, čemu se obvykle říká šamanismus - spolu s prodejcem vybavení, za což jim děkujeme, to nevzdali :)
- filtrování bylo zcela zakázáno
- NAT byl deaktivován pomocí nového schématu
- testovaný počítač byl umístěn do odděleného izolovaného bazénu
- IP adresa změněna
Odpoledne byl přidělen virtuální stroj, který se připojoval k síti podle schématu běžného uživatele, a zástupci dodavatele dostali přístup k němu a vybavení. Šamanismus pokračoval :)
Nakonec zástupce prodejce sebevědomě prohlásil, že hardware s tím nemá absolutně nic společného: první pochází odněkud výše.
PoznámkaV tuto chvíli si možná někdo řekne: ale bylo mnohem jednodušší vzít skládku ne z testovacího PC, ale z dálnice nad DPI?
Ne, bohužel vzít výpis (a dokonce jen zrcadlení) 40+gbps není vůbec triviální.
Po tomto večer nezbývalo nic jiného, než se vrátit k předpokladu podivné filtrace někde nahoře.
Podíval jsem se, kterým IX nyní prochází provoz do sítí MRG, a jednoduše jsem zrušil relace bgp. A - ejhle! - vše se okamžitě vrátilo do normálu 🙁
Na jednu stranu je škoda, že se celý den hledal problém, ačkoliv byl vyřešen za pět minut.
Na druhé straně:
— v mé paměti je to bezprecedentní věc. Jak jsem již psal výše - IX doopravdy nemá smysl filtrovat tranzitní dopravu. Obvykle mají stovky gigabitů/terabitů za sekundu. Něco takového jsem si ještě nedávno nedokázal vážně představit.
— neuvěřitelně šťastná shoda okolností: nový komplexní hardware, kterému se příliš nedůvěřuje a od kterého není jasné, co lze očekávat — šitý na míru speciálně pro blokování zdrojů, včetně TCP RST
NOC této internetové burzy aktuálně hledá problém. Podle nich (a já jim věřím) nemají žádný speciálně nasazený filtrační systém. Ale díky bohu, další hledání už není náš problém :)
Toto byl malý pokus o ospravedlnění, prosím pochopte a odpusťte :)
PS: Záměrně neuvádím výrobce DPI/NAT nebo IX (vlastně k nim ani nemám žádné zvláštní stížnosti, hlavní je pochopit, co to bylo)
Dnešní (stejně jako včerejší a předvčerejší) realita z pohledu poskytovatele internetu
Poslední týdny jsem strávil výraznou přestavbou jádra sítě, prováděl jsem spoustu manipulací „za účelem zisku“, s rizikem výrazného ovlivnění živého provozu uživatelů. Vezmeme-li v úvahu cíle, výsledky a důsledky toho všeho, morálně je to všechno docela obtížné. Zvláště - ještě jednou poslouchat krásné řeči o ochraně stability Runetu, suverenitě atd. a tak dále.
V této části se pokusím popsat „evoluci“ síťového jádra typického ISP za posledních deset let.
Před deseti lety.
V těchto požehnaných časech mohlo být jádro sítě poskytovatelů tak jednoduché a spolehlivé jako dopravní zácpa:
V tomto velmi, velmi zjednodušeném obrázku nejsou žádné trunky, kruhy, ip/mpls směrování.
Jeho podstatou je, že uživatelský provoz nakonec přišel na přepínání na úrovni jádra – odkud šel , odkud zpravidla zpět k přepínání jádra a poté „ven“ - přes jednu nebo více hraničních bran do internetu.
Takové schéma je velmi, velmi snadné rezervovat jak na L3 (dynamické směrování), tak na L2 (MPLS).
Můžete nainstalovat N+1 čehokoli: přístup k serverům, přepínačům, hranicím – a tak či onak je vyhradit pro automatické převzetí služeb při selhání.
Po několika letech Všem v Rusku bylo jasné, že takto už nelze žít: bylo naléhavé chránit děti před zhoubným vlivem internetu.
Bylo naléhavě nutné najít způsoby, jak filtrovat uživatelský provoz.
Jsou zde různé přístupy.
V nepříliš dobrém případě se něco vkládá „do mezery“: mezi uživatelským provozem a internetem. Provoz procházející tímto „něčím“ je analyzován a k účastníkovi je například odeslán falešný paket s přesměrováním.
V trochu lepším případě – pokud to objem provozu dovolí – můžete udělat malý trik s ušima: posílat k filtrování pouze provoz pocházející od uživatelů pouze na ty adresy, které je třeba filtrovat (k tomu můžete buď vzít IP adresy specifikované tam z registru, nebo dodatečně vyřešit existující domény v registru).
Svého času jsem pro tyto účely napsal jednoduchý - i když se mu tak ani neodvažuji říkat. Je to velmi jednoduché a nepříliš produktivní – nicméně nám a desítkám (ne-li stovkám) dalších poskytovatelů umožnilo nevyhazovat okamžitě miliony za průmyslové DPI systémy, ale poskytlo to několik let navíc.
Mimochodem o tehdejším a současném DPIMimochodem, mnozí, kteří si tehdy na trhu dostupné DPI systémy zakoupili, je již vyhodili. No, na tohle nejsou určeny: stovky tisíc adres, desítky tisíc URL.
A přitom domácí výrobci na tento trh velmi silně vystoupali. Nemluvím o hardwarové složce - tady je všem jasné, ale software - to hlavní, co DPI má - je dnes možná, když ne nejpokročilejší na světě, tak určitě a) vyvíjející se mílovými kroky, a b) za cenu krabicového produktu – prostě nesrovnatelná se zahraniční konkurencí.
Chtěl bych být hrdý, ale trochu smutný =)
Nyní vše vypadalo takto:
Ještě za pár let všichni už měli auditory; V registru bylo stále více zdrojů. Pro některá starší zařízení (například Cisco 7600) se schéma „bočního filtrování“ jednoduše stalo nepoužitelným: počet tras na 76 platformách je omezen na něco kolem devíti set tisíc, zatímco počet samotných IPv4 tras se dnes blíží 800. tisíc. A pokud je to také ipv6... A také... kolik tam je? 900000 XNUMX jednotlivých adres v zákazu RKN? =)
Někdo přešel na schéma se zrcadlením veškerého páteřního provozu na filtrační server, který by měl analyzovat celý tok a pokud se najde něco špatného, poslat RST oběma směry (odesílatel i příjemce).
Čím je však větší provoz, tím méně je toto schéma použitelné. Pokud dojde k sebemenšímu zpoždění ve zpracování, zrcadlený provoz jednoduše proletí bez povšimnutí a poskytovatel dostane slušnou zprávu.
Stále více poskytovatelů je nuceno instalovat DPI systémy různého stupně spolehlivosti napříč dálnicemi.
Před rokem nebo dvěma podle pověstí téměř všechny FSB začaly vyžadovat skutečnou instalaci zařízení (dříve to většina poskytovatelů spravovala se souhlasem úřadů plán SORM - plán provozních opatření pro případ potřeby někde něco najít)
Kromě peněz (ne zrovna horentních, ale přesto milionů) vyžadoval SORM mnohem více manipulací se sítí.
- SORM potřebuje před překladem nat vidět „šedé“ uživatelské adresy
- SORM má omezený počet síťových rozhraní
Zejména jsme proto museli značně přebudovat kus jádra – jednoduše proto, abychom někde na jednom místě shromáždili uživatelský provoz na přístupové servery. Aby bylo možné jej zrcadlit v SORM s několika odkazy.
To znamená, velmi zjednodušeně, bylo to (vlevo) vs stalo se (vpravo):
Nyní Většina poskytovatelů také vyžaduje implementaci SORM-3 – což mimo jiné zahrnuje logování vysílání nat.
Pro tyto účely jsme také museli do výše uvedeného schématu přidat samostatné zařízení pro NAT (přesně to, o čem je řeč v první části). Navíc přidejte v určitém pořadí: protože SORM musí „vidět“ provoz před překladem adres, provoz musí probíhat přesně takto: uživatelé -> přepínání, jádro -> přístupové servery -> SORM -> NAT -> přepínání, jádro - > Internet. Abychom to udělali, museli jsme doslova „otočit“ dopravní proudy opačným směrem za účelem zisku, což bylo také docela obtížné.
Stručně řečeno: za posledních deset let se základní návrh průměrného poskytovatele mnohonásobně zkomplikoval a výrazně přibylo dalších míst selhání (jak ve formě zařízení, tak ve formě jednotlivých spojovacích linek). Ve skutečnosti samotný požadavek „vidět všechno“ znamená zredukovat toto „vše“ na jeden bod.
Myslím, že to lze docela transparentně extrapolovat na současné iniciativy suverénní Runet, chránit ji, stabilizovat a zlepšovat :)
A Yarovaya je stále napřed.
Zdroj: www.habr.com