Vyzvalo ma na tento príspevok .
citujem to tu:
dnes o 18:53
Dnes som bol spokojný s poskytovateľom. Spolu s aktualizáciou systému blokovania stránok bol zakázaný aj jeho mailer mail.ru.Od rána volám na technickú podporu, no nevedia nič robiť. Poskytovateľ je malý a zrejme ho blokujú vyššie postavení poskytovatelia. Všimol som si aj spomalenie otvárania všetkých stránok, možno nainštalovali nejaké krivé DLP? Predtým neboli žiadne problémy s prístupom. Zničenie RuNetu sa deje priamo pred mojimi očami...
Faktom je, že sa zdá, že sme ten istý poskytovateľ :)
Naozaj, Takmer som uhádol príčinu problémov s mail.ru (hoci sme takémuto niečomu dlho odmietali veriť).
Nasledujúce bude rozdelené do dvoch častí:
- dôvody našich súčasných problémov s mail.ru a vzrušujúca snaha ich nájsť
- existencia ISP v dnešnej realite, stabilita suverénneho RuNetu.
Problémy s dostupnosťou na mail.ru
Oh, to je dosť dlhý príbeh.
Faktom je, že s cieľom implementovať požiadavky štátu (podrobnejšie v druhej časti) sme zakúpili, nakonfigurovali a nainštalovali niektoré zariadenia - na filtrovanie zakázaných zdrojov aj na implementáciu predplatiteľov.
Pred časom sme konečne prestavali jadro siete tak, aby všetka účastnícka prevádzka prechádzala cez toto zariadenie striktne správnym smerom.
Pred pár dňami sme na ňom zapli zakázané filtrovanie (pričom starý systém sme nechali fungovať) - zdalo sa, že všetko ide dobre.
Ďalej postupne začali povoľovať NAT na tomto zariadení pre rôzne časti účastníkov. Na pohľad sa tiež zdalo, že všetko ide dobre.
Ale dnes, keď sme povolili NAT na zariadení pre ďalšiu časť predplatiteľov, od samého rána sme čelili slušnému počtu sťažností na nedostupnosť alebo čiastočnú dostupnosť a ďalšie zdroje Mail Ru Group.
Začali kontrolovať: niekde niečo niekedy, príležitostne posiela v reakcii na požiadavky výlučne do sietí mail.ru. Navyše posiela nesprávne vygenerovaný (bez ACK), zjavne umelý TCP RST. Takto to vyzeralo:
Prirodzene, prvé myšlienky sa týkali nového vybavenia: hrozné DPI, nedôverovať mu, nikdy neviete, čo dokáže – napokon, TCP RST je medzi blokovacími nástrojmi pomerne bežná vec.
predpoklad Tiež sme predložili myšlienku, že niekto „nadradený“ filtruje, ale okamžite sme to zahodili.
Po prvé, máme dostatočne zdravé uplinky, aby sme nemuseli takto trpieť :)
Po druhé, sme spojení s viacerými v Moskve a návštevnosť na mail.ru prechádza cez nich - a nemajú ani zodpovednosť, ani iný motív filtrovať návštevnosť.
Ďalšia polovica dňa bola venovaná tomu, čomu sa zvyčajne hovorí šamanizmus - spolu s predajcom vybavenia, za čo im ďakujeme, to nevzdali :)
- filtrovanie bolo úplne vypnuté
- NAT bol zakázaný pomocou novej schémy
- testovaný počítač sa umiestnil do samostatnej izolovanej skupiny
- IP adresa zmenená
V popoludňajších hodinách bol pridelený virtuálny stroj, ktorý sa pripájal k sieti podľa schémy bežného používateľa, a zástupcom predajcu bol umožnený prístup k nemu a zariadeniu. Šamanizmus pokračoval :)
Zástupca predajcu nakoniec s istotou vyhlásil, že hardvér s tým nemá absolútne nič spoločné: tie prvé pochádzajú odniekiaľ vyššie.
PoznámkaNa tomto mieste si možno niekto povie: ale bolo oveľa jednoduchšie zobrať skládku nie z testovacieho PC, ale z diaľnice nad DPI?
Nie, bohužiaľ, urobiť výpis (a dokonca len zrkadlenie) 40+gbps nie je vôbec triviálne.
Po tomto večer už nezostávalo nič iné, len sa vrátiť k domnienke o podivnej filtrácii niekde vyššie.
Pozrel som sa, cez ktorý IX teraz prechádza prevádzka do sietí MRG a jednoducho som tam zrušil relácie bgp. A - hľa! - všetko sa okamžite vrátilo do normálu 🙁
Na jednej strane je škoda, že celý deň sa hľadal problém, hoci bol vyriešený za päť minút.
Na druhej strane:
— v mojej pamäti je to bezprecedentná vec. Ako som už písal vyššie - IX naozaj nemá zmysel filtrovať tranzitnú dopravu. Zvyčajne majú stovky gigabitov/terabitov za sekundu. Až donedávna som si niečo také nevedela vážne predstaviť.
— neuveriteľne šťastná zhoda okolností: nový komplexný hardvér, ktorý nie je obzvlášť dôveryhodný a od ktorého nie je jasné, čo možno očakávať – prispôsobený špeciálne na blokovanie zdrojov vrátane TCP RST
NOC tejto internetovej burzy momentálne hľadá problém. Podľa nich (a ja im verím) nemajú žiadny špeciálne nasadený filtračný systém. Ale, chvalabohu, ďalšie hľadanie už nie je náš problém :)
Toto bol malý pokus ospravedlniť sa, prosím pochopte a odpustite :)
PS: Zámerne neuvádzam výrobcu DPI/NAT alebo IX (v skutočnosti k nim ani nemám žiadne špeciálne sťažnosti, hlavné je pochopiť, čo to bolo)
Dnešná (ale aj včerajšia a predvčera) realita z pohľadu poskytovateľa internetu
Posledné týždne som strávil výraznou prestavbou jadra siete, vykonávaním množstva manipulácií „pre zisk“, s rizikom výrazného ovplyvnenia živej návštevnosti používateľov. Ak vezmeme do úvahy ciele, výsledky a dôsledky toho všetkého, morálne je to všetko dosť ťažké. Najmä - ešte raz počúvať krásne reči o ochrane stability Runetu, suverenity atď. a tak ďalej.
V tejto časti sa pokúsim opísať „evolúciu“ sieťového jadra typického ISP za posledných desať rokov.
Pred desiatimi rokmi.
V týchto požehnaných časoch by jadro siete poskytovateľov mohlo byť také jednoduché a spoľahlivé ako dopravná zápcha:
V tomto veľmi, veľmi zjednodušenom obrázku nie sú žiadne kmene, kruhy, ip/mpls smerovanie.
Jeho podstatou je, že návštevnosť používateľov nakoniec prišla k prepínaniu na úrovni jadra – odkiaľ smerovala , odkiaľ sa spravidla vracia späť k prepínaniu jadra a potom „von“ - cez jednu alebo viacero hraničných brán na internet.
Takáto schéma je veľmi, veľmi ľahko rezervovateľná ako na L3 (dynamické smerovanie), tak aj na L2 (MPLS).
Môžete si nainštalovať N+1 čohokoľvek: prístup k serverom, prepínačom, hraniciam – a tak či onak ich vyhradiť na automatické prepnutie pri zlyhaní.
Po niekoľkých rokoch Každému v Rusku bolo jasné, že takto už nie je možné žiť: bolo nevyhnutné chrániť deti pred zhubným vplyvom internetu.
Bola naliehavá potreba nájsť spôsoby, ako filtrovať návštevnosť používateľov.
Sú tu rôzne prístupy.
V nie veľmi dobrom prípade je niečo vložené „do medzery“: medzi návštevnosťou používateľov a internetom. Prevádzka prechádzajúca týmto „niečím“ sa analyzuje a napríklad sa účastníkovi odošle falošný paket s presmerovaním.
V trochu lepšom prípade – ak to objemy návštevnosti umožňujú – môžete urobiť malý trik s ušami: posielať na filtrovanie iba návštevnosť pochádzajúcu od používateľov iba na tie adresy, ktoré je potrebné filtrovať (na tento účel môžete použiť adresy IP tam uvedené z registra, alebo dodatočne vyriešiť existujúce domény v registri).
Svojho času som na tieto účely napísal jednoduchý - hoci sa ho tak ani neodvážim nazvať. Je to veľmi jednoduché a málo produktívne – umožnilo nám to však a desiatkam (ak nie stovkám) ďalších poskytovateľov okamžite vyhodiť milióny za priemyselné DPI systémy, ale poskytlo nám to niekoľko rokov navyše.
Mimochodom, o vtedajšom a súčasnom DPIMimochodom, mnohí, ktorí si zakúpili DPI systémy v tom čase dostupné na trhu, ich už vyhodili. No, nie sú na to určené: státisíce adries, desaťtisíce adries URL.
A zároveň domáci výrobcovia veľmi silno stúpli na tento trh. Nehovorím o hardvérovej zložke - tu je všetko jasné, ale softvér - to hlavné, čo DPI má - je dnes možno, ak nie najvyspelejší na svete, tak určite a) vyvíjajúci sa míľovými krokmi, a b) za cenu krabicového produktu – jednoducho neporovnateľné so zahraničnými konkurentmi.
Chcel by som byť hrdý, ale trochu smutný =)
Teraz všetko vyzeralo takto:
O pár rokov viac každý už mal audítorov; V registri bolo stále viac zdrojov. Pre niektoré staršie zariadenia (napríklad Cisco 7600) sa schéma „bočného filtrovania“ jednoducho stala nepoužiteľnou: počet trás na 76 platformách je obmedzený na niečo ako deväťstotisíc, zatiaľ čo počet trás IPv4 sa dnes blíži k 800. tisíc. A ak je to aj ipv6... A tiež... koľko je tam? 900000 XNUMX individuálnych adries v zákaze RKN? =)
Niekto prešiel na schému so zrkadlením všetkej chrbticovej prevádzky na filtrovací server, ktorý by mal celý tok analyzovať a v prípade zistenia niečoho zlého poslať RST oboma smermi (odosielateľ aj príjemca).
Čím je však väčšia návštevnosť, tým je táto schéma menej použiteľná. Ak dôjde k najmenšiemu oneskoreniu spracovania, zrkadlená prevádzka jednoducho preletí bez povšimnutia a poskytovateľ dostane dobrú správu.
Čoraz viac poskytovateľov je nútených inštalovať na diaľniciach systémy DPI rôzneho stupňa spoľahlivosti.
Pred rokom alebo dvoma podľa povestí takmer všetky FSB začali požadovať skutočnú inštaláciu zariadení (predtým väčšina poskytovateľov spravovala so súhlasom úradov plán SORM - plán prevádzkových opatrení v prípade potreby niekde niečo nájsť)
Okrem peňazí (nie práve premrštených, ale stále miliónov) si SORM vyžiadal oveľa viac manipulácií so sieťou.
- SORM potrebuje pred prekladom nat vidieť „sivé“ adresy používateľov
- SORM má obmedzený počet sieťových rozhraní
Preto sme museli najmä značne prebudovať časť jadra – jednoducho preto, aby sme niekde na jednom mieste zhromaždili návštevnosť používateľov na prístupové servery. Aby sa to zrkadlilo v SORM s niekoľkými odkazmi.
To znamená, že veľmi zjednodušene to bolo (vľavo) vs stalo sa (vpravo):
Teraz Väčšina poskytovateľov vyžaduje aj implementáciu SORM-3 – ktorá okrem iného zahŕňa logovanie vysielania nat.
Na tieto účely sme museli do vyššie uvedeného diagramu pridať aj samostatné vybavenie pre NAT (presne to, čo je popísané v prvej časti). Navyše pridajte v určitom poradí: keďže SORM musí „vidieť“ prevádzku pred prekladom adries, prevádzka musí prebiehať striktne takto: používatelia -> prepínanie, jadro -> prístupové servery -> SORM -> NAT -> prepínanie, jadro - > Internet. Aby sme to dosiahli, museli sme doslova „otočiť“ dopravné toky opačným smerom za účelom zisku, čo bolo tiež dosť náročné.
Stručne povedané: za posledných desať rokov sa základný návrh priemerného poskytovateľa mnohonásobne skomplikoval a ďalšie body zlyhania (vo forme zariadení aj vo forme jednotlivých spínacích liniek) sa výrazne zvýšili. V skutočnosti samotná požiadavka „vidieť všetko“ znamená zredukovať toto „všetko“ na jeden bod.
Myslím, že sa to dá celkom transparentne extrapolovať na súčasné iniciatívy na suverenizáciu Runetu, jeho ochranu, stabilizáciu a zlepšenie :)
A Yarovaya je stále vpredu.
Zdroj: hab.com