Přimělo mě to k tomuto příspěvku .
Uvedu ho zde:
dnes v 18:53
Dnes mě potěšil poskytovatel. Společně s aktualizací systému blokování webů, spadl do zákazu mail.ru. Od rána volám technickou podporu, nemohou s tím nic udělat. Poskytovatel je malý a blokují ho zřejmě nadřízené společnosti. Taktéž jsem si všiml zpomalení otevírání všech webů, možná nasadili nějaké špatné DLP? Dříve nebyly žádné problémy s přístupem. Zničení ruského internetu se děje přímo před mýma očima…
Je skutečností, že se zdá, že jsme tímto poskytovatelem 🙁
A opravdu, skoro jsme uhádli příčinu problémů s mail.ru (i když jsme dlouho nechtěli věřit v takové něco).
Dále bude rozděleno na dvě části:
- příčiny našich dnešních problémů s mail.ru a vzrušující hon na jejich nalezení
- existence ISP v dnešních podmínkách, stabilita suverénního ruského internetu.
Problémy s dostupností mail.ru
Och, to je docela dlouhá historie.
Je skutečností, že pro splnění požadavků státu (více ve druhé části) jsme zakoupili, nastavili a nainstalovali jisté zařízení – jak pro filtraci zakázaných zdrojů, tak pro provádění uživatelů.
Před nějakým časem jsme konečně přestavěli jádro sítě tak, aby veškerý provoz uživatelů procházel tímto zařízením přesně požadovaným směrem.
Před několika dny jsme na něm zapnuli filtraci zakázaných stránek (zároveň jsme nechali fungovat i starý systém) – na první pohled vše proběhlo dobře.
Dále jsme postupně začali zapínat NAT pro různé skupiny uživatelů na tomto zařízení. Vzhledem k tomu – také to vypadalo, že vše šlo celkem dobře.
Ale dnes, když jsme na zařízení zapnuli NAT pro další skupinu uživatelů – od rána jsme čelili značnému počtu stížností na nedostupnost nebo částečnou dostupnost a dalších zdrojů Mail Ru Group.
Začali jsme kontrolovat: něco někde občas, občasně posílá jako odpověď na dotazy výhradně k sítím mail.ru. Navíc – posílá špatně generovaný (bez ACK), zjevně umělý TCP RST. Přibližně takto to vypadalo:
Samozřejmě, první myšlenky směřovaly na nové zařízení: strašný DPI, důvěra v něj žádná, kdo ví, co může provést – vždyť TCP RST je poměrně běžná záležitost mezi prostředky blokace.
Předpoklad o tom, že filtruje někdo "vyšší", jsme také navrhli — ale hned jsme to zavrhli.
Za prvé, máme dostatečně rozumné uplinky, abychom tímto netrpěli 🙂
Za druhé, jsme připojeni k několika v Moskvě, a provoz na mail.ru jde právě přes ně — a ti nemají žádné povinnosti, ani jinou motivaci filtrovat provoz.
Následující část dne byla věnována tomu, co se obvykle nazývá šamanství — spolu s dodavatelem zařízení, za což jim děkujeme, jsme to nevzdali 🙂
- filtrace byla kompletně vypnuta
- NAT se odpojil podle nové schématu
- testovací PC bylo vyvedeno do samostatného izolovaného poolu
- měnila se IP adresace
Ve druhé polovině dne byla vyčleněna virtuálka, která vycházela na síť podle schématu běžného uživatele, a k ní a zařízení dostali přístup zástupci dodavatele. Šamanství pokračovalo 🙂
Nakonec zástupce dodavatele sebevědomě prohlásil, že hardware je naprosto v pořádku: rst'y přicházejí odkudsi výše.
PoznámkaNa tomto místě může někdo tvrdit: ale bylo by mnohem jednodušší vzít dump ne z testovacího PC, ale z magistrály nad DPI?
Ne, bohužel, pořídit dump (a dokonce i pouze odmirrorovat) 40+gbps — vůbec není triviální.
Po tom, už večer — nezbývalo nic jiného, než se vrátit k předpokladu o podivném filtrování kdesi nahoře.
Podíval jsem se, přes který IX nyní prochází provoz do sítí MRG a jednoduše jsem ztlumil k němu bgp relace. A — ó zázrak! — všechno se okamžitě normalizovalo 🙁
Na jedné straně — je mi moc líto, že na hledání problému byl utracen celý den, i když se vyřešil za pět minut.
Na druhou stranu:
— v mé paměti je to bezprecedentní záležitost. Jak jsem již psal výše — IX'ům opravdu nema smysl filtrovat tranzitní provoz. Obvykle mají stovky gigabitů / terabity za sekundu. Pro mě to prostě byla naprostá spekulace až do poslední chvíle.
— neuvěřitelně šťastná shoda okolností: nové složité zařízení, kterému není moc důvěry a od kterého není jasné, co lze očekávat — zacílené právě na blokaci zdrojů, včetně TCP RST'y
V současné době NOC tohoto internetového exchange hledá problém. Podle jejich tvrzení (a věřím jim) žádný speciálně nasazený filtrační systém nemají. Ale, díky nebi, další quest — už není náš problém 🙂
Byla to malá snaha se omluvit, prosíme o pochopení a odpuštění 🙂
P.S.: Úmyslně nezmiňuji výrobce DPI/NAT ani IX (na ně vlastně nemám žádné zvláštní námitky, hlavní je pochopit, co se stalo)
Dnešní (a také včerejší a předevčírem) realita z pohledu internetového poskytovatele
Poslední týdny jsem strávil zásadní restrukturalizací jádra sítě, přičemž jsem mnohokrát prováděl manipulace "za chodu", s rizikem výrazně zasáhnout do živého uživatelského provozu. S ohledem na cíle, výsledky a důsledky tohoto všeho — je to morálně docela těžké. Zvlášť když znovu poslouchám vzletné řeči o ochraně stability ruského internetu, suverenitě atd.
V této části se pokusím přiblížit „evoluci“ jádra sítě typického internetového poskytovatele za poslední dekádu.
Před deseti lety.
V těch požehnaných časech mohlo být jádro poskytovatelské sítě jednoduché a spolehlivé jako zátka:
Na tomto velmi zjednodušeném obrázku chybí magistrály, kruhy, ip/MPLS směrování.
Jeho podstatou bylo, že provoz uživatelů nakonec přicházel do jádrové komutace — odkud putoval do , odkud obvykle — zpět do komutace jádra a dále „na výstup“ — přes jednu nebo více brán do internetu.
Takovýto způsob je velmi snadno redundantní jak na L3 (dynamické směrování), tak na L2 (MPLS).
Můžete nasadit N+1 čehokoliv: přístupových serverů, switchů, borderů — a tímto způsobem je rezervovat pro automatický failover.
Pár let později se všem v Rusku stalo jasné, že takto dál žít nelze: je nutné urgentně chránit děti před škodlivým vlivem sítě.
Objevila se nutnost urgentně hledat způsoby, jak filtrovat uživatelský provoz.
Existují různé přístupy.
V méně dobrém případě se něco nasadí "napříč": mezi uživatelským provozem a internetem. Procházející provoz tímto "něčím" je analyzován a například směrem k uživateli je odeslán falešný paket s přesměrováním.
V lepším případě – pokud objemy provozu to dovolují – je možné provést malý trik: posílat na filtrování pouze odcházející provoz od uživatelů na adresy, které je třeba filtrovat (k tomu lze buď použít uvedené IP adresy z registru, nebo dále resolvovat domény uvedené v registru).
Kdysi jsem pro tyto účely napsal jednoduchý – i když se mi ani jazyk neobrací to tak nazvat. Je to velmi jednoduché a nikterak výkonné – avšak nám, a desítkám (pokud ne stovkám) dalších poskytovatelů, to umožnilo nevydat hned miliony na průmyslové DPI systémy, ale dalo nám několik dalších let času.
Mimochodem, o tehdejších a nynějších DPIMusím říct, že mnozí, kteří v té době zakoupili dostupné DPI systémy – už je vyhodili. Prostě nejsou uzpůsobeny pro něco takového: stovky tisíc adres, desítky tisíc URL.
A zároveň se v tomto trhu výrazně vzchopili tuzemští výrobci. Nemluvím o hardwarové stránce – tam je to jasné, ale software – to nejdůležitější, co v DPI je – se možná dnes, pokud ne řadí mezi nejpokročilejší na světě, tak určitě a) vyvíjí neuvěřitelným tempem, a b) co se ceny krabicové verze týče – je nesrovnatelný se zahraničními konkurenty.
Rád bych se pochlubil, ale je to trochu smutné =)
Teď to vypadalo takto:
O pár let později už všichni měli revizory; počet zdrojů v registru stále rostl. Pro některé staré vybavení (například cisco 7600) se stávalo schéma s ’filtrací z boku‘ jednoduše neaplikovatelným: počet tras na 76 platformách je omezen na asi devět set tisíc, zatímco počet pouze IPv4 tras se dnes blíží 800 tisícům. A pokud ještě ipv6… A co tam ještě? 900000 jednotlivých adres v banku rkn? =)
Někteří přešli na schéma s zrcadlením veškerého páteřního provozu na filtrovací server, který musí analyzovat celý tok a při zjištění něčeho špatného poslat oběma směry (odesílateli a příjemci) RST.
Avšak čím více provozu, tím méně je podobné schéma aplikovatelné. Při sebemenším zpoždění zpracování – zrcadlený provoz prostě nepozorovaně projede nikam, a poskytovatel dostane protokol o pokutě.
Stále více poskytovatelů je nuceno instalovat systémy DPI různé úrovně spolehlivosti na páteřní síť.
Před rokem či dvěma se podle zpráv téměř od všech začalo vyžadovat skutečné nasazení zařízení od FSB. (dříve většina poskytovatelů obcházela souhlas s orgány plánu SORM — plán operativních opatření v případě potřeby něco někde najít)
Kromě peněz (ne, že by to byly zcela astronomické částky, ale stále — v milionech) SORM od mnohých vyžadoval další manipulace se sítí.
- SORM potřebuje vidět „šedé“ adresy uživatelů před NAT transformací.
- SORM má omezený počet síťových rozhraní.
Proto jsme také museli výrazně přestavět část jádra — jednoduše abychom mohli sbírat někde na jednom místě provoz uživatelů k přístupovým serverům. Abychom ho několika linkami zrcadlili do SORM.
To znamená, velmi zjednodušeně, bylo (vlevo) vs. stalo se (vpravo):
Teď u většiny poskytovatelů vyžadují také implementaci SORM-3 — která zahrnuje i logging NAT transformací.
Za tímto účelem jsme do výše uvedeného schématu museli přidat i samostatné vybavení pro NAT (přesně to, o čem byla řeč v první části). A to v určitém pořadí: protože SORM musí „vidět“ provoz před transformací adres — provoz musí jít striktně tímto způsobem: uživatelé -> přepínač, jádro -> přístupové servery -> SORM -> NAT -> přepínač, jádro -> internet. Pro to jsme museli doslova „otočit“ tok provozu na druhou stranu za chodu, což také nebylo zrovna jednoduché.
Celkově: za deset let se schéma jádra průměrného poskytovatele výrazně zkomplikovalo a přidalo se také mnoho dalších míst selhání (jak v podobě zařízení, tak i v podobě jednotných přepínacích linek). Samotné požadování „vidět vše“ vlastně implikuje shrnutí tohoto „všechna“ do jednoho bodu.
Myslím, že to lze zcela transparentně extrapolovat na aktuální iniciativy zaměřené na suverenitu ruského internetu, jeho ochranu, stabilizaci a zlepšení 🙂
A před námi je ještě Jarovaja.
Zdroj: habr.com
