Paskatino mane į šį įrašą .
Cituoju čia:
šiandien 18:53 val
Šiandien buvau patenkintas tiekėju. Kartu su svetainės blokavimo sistemos atnaujinimu buvo uždraustas jo laiškas mail.ru Nuo pat ryto skambinau techninei pagalbai, bet jie nieko negali padaryti. Teikėjas yra mažas, ir, matyt, aukštesnio rango teikėjai jį blokuoja. Pastebėjau irgi sulėtėjusį visų svetainių atsidarymą, gal įdėjo kažkokį kreivą DLP? Anksčiau problemų su prieiga nebuvo. „RuNet“ sunaikinimas vyksta tiesiai prieš mano akis...
Faktas yra tas, kad atrodo, kad mes esame tie patys tiekėjai :)
Ir tikrai, Beveik atspėjau mail.ru problemų priežastį (nors mes ilgą laiką atsisakėme tikėti tokiu dalyku).
Tai, kas toliau bus padalinta į dvi dalis:
- dabartinių problemų, susijusių su mail.ru, priežastis ir įdomų ieškojimą jas rasti
- IPT egzistavimas šiandieninėje realybėje, suverenios RuNet stabilumas.
Prieinamumo problemos su mail.ru
O, tai gana ilga istorija.
Faktas yra tas, kad siekdami įgyvendinti valstybės reikalavimus (plačiau antroje dalyje) įsigijome, sukonfigūravome ir sumontavome tam tikrą įrangą – tiek draudžiamiems resursams filtruoti, tiek diegti. prenumeratorių.
Prieš kurį laiką pagaliau perstatėme tinklo branduolį taip, kad visas abonentų srautas per šią įrangą praeitų griežtai tinkama kryptimi.
Prieš kelias dienas jame įjungėme draudžiamą filtravimą (palikdami seną sistemą) - viskas lyg ir gerai.
Tada jie palaipsniui pradėjo įjungti NAT šioje įrangoje skirtingoms abonentų dalims. Iš pažiūros taip pat atrodė, kad viskas klostėsi gerai.
Tačiau šiandien, įjungus NAT įrangoje kitai abonentų daliai, nuo pat ryto sulaukėme nemažai skundų dėl nepasiekiamumo ar dalinio pasiekiamumo. ir kiti „Mail Ru Group“ ištekliai.
Jie pradėjo tikrinti: kažkas kažkur kartais, retkarčiais siunčia atsakant į užklausas tik mail.ru tinklams. Be to, jis siunčia neteisingai sugeneruotą (be ACK), akivaizdžiai dirbtinį TCP RST. Štai kaip atrodė:
Natūralu, kad pirmosios mintys buvo apie naują įrangą: baisus DPI, nepasitiki juo, niekada nežinai, ką ji gali – juk TCP RST yra gana dažnas dalykas tarp blokavimo įrankių.
Ėmimas į dangų Mes taip pat iškėlėme idėją, kad kažkas „viršesnis“ filtruoja, bet iškart ją atmetėme.
Pirma, turime pakankamai protingų nuorodų, kad nereikėtų taip kentėti :)
Antra, esame susiję su keletu Maskvoje, o srautas į mail.ru eina per juos – ir jie neturi nei pareigų, nei kitų motyvų filtruoti srautą.
Kita dienos pusė buvo skirta tam, kas paprastai vadinama šamanizmu - kartu su įrangos pardavėja, už ką dėkojame, jie nepasidavė :)
- filtravimas buvo visiškai išjungtas
- NAT buvo išjungtas naudojant naują schemą
- bandomasis kompiuteris buvo patalpintas į atskirą izoliuotą baseiną
- Pakeistas IP adresas
Po pietų buvo skirta virtuali mašina, kuri prisijungė prie tinklo pagal eilinio vartotojo schemą, o pardavėjo atstovams buvo suteikta prieiga prie jos ir įrangos. Šamanizmas tęsėsi :)
Pabaigoje pardavėjo atstovas užtikrintai pareiškė, kad aparatinė įranga su tuo visiškai nesusijusi: rsts ateina iš kažkur aukščiau.
Atkreipti dėmesįŠiuo metu kas nors gali pasakyti: bet daug lengviau buvo paimti sąvartyną ne iš bandomojo kompiuterio, o iš greitkelio virš DPI?
Ne, deja, 40+gbps išmetimas (ir netgi tiesiog atspindėjimas) nėra visai nereikšmingas.
Po to, vakare, neliko nieko kito, kaip grįžti prie keistos filtravimo prielaidos kažkur aukščiau.
Pažiūrėjau per kurį IX dabar eina srautas į MRG tinklus ir tiesiog atšaukiau jo bgp seansus. Ir – štai ir štai! - viskas iškart grįžo į savo vėžes 🙁
Viena vertus, gaila, kad visa diena buvo praleista ieškant problemos, nors ji buvo išspręsta per penkias minutes.
Kita vertus:
— mano atmintyje tai precedento neturintis dalykas. Kaip jau rašiau aukščiau – IX tikrai nėra prasmės filtruoti tranzito srautą. Paprastai jie turi šimtus gigabitų / terabitų per sekundę. Tiesiog dar neseniai negalėjau rimtai įsivaizduoti kažko panašaus.
— neįtikėtinai laimingas aplinkybių sutapimas: nauja sudėtinga aparatinė įranga, kuria nelabai pasitikima ir iš kurios neaišku, ko galima tikėtis, – specialiai pritaikyta blokuoti išteklius, įskaitant TCP RST.
Šios interneto biržos NOC šiuo metu ieško problemos. Anot jų (ir aš jais tikiu), jie neturi jokios specialiai įrengtos filtravimo sistemos. Bet, ačiū dangui, tolesnės paieškos nebėra mūsų problema :)
Tai buvo mažas bandymas pasiteisinti, prašau suprasti ir atleisti :)
PS: Sąmoningai neįvardiju DPI/NAT ar IX gamintojo (tiesą sakant, ypatingų priekaištų jiems net neturiu, svarbiausia suprasti, kas tai buvo)
Šiandienos (kaip ir vakar bei užvakar) realybė interneto tiekėjo požiūriu
Paskutines savaites praleidau gerokai atstatydamas tinklo branduolį, atlikdamas daugybę manipuliacijų „siekdamas pelno“, rizikuodamas smarkiai paveikti tiesioginį vartotojų srautą. Turint omenyje viso to tikslus, rezultatus ir pasekmes, morališkai viskas yra gana sunku. Ypač - dar kartą klausantis gražių kalbų apie Runeto stabilumo apsaugą, suverenitetą ir kt. ir taip toliau.
Šiame skyriuje pabandysiu aprašyti tipiško IPT tinklo branduolio „evoliuciją“ per pastaruosius dešimt metų.
Prieš dešimt metų.
Tais palaimintais laikais tiekėjų tinklo branduolys gali būti toks paprastas ir patikimas kaip eismo kamštis:
Šiame labai, labai supaprastintame paveikslėlyje nėra magistralinių tinklų, žiedų, ip/mpls maršruto parinkimo.
Jo esmė ta, kad naudotojų srautas galiausiai pateko į branduolio lygio perjungimą – iš kur jis nukeliavo , iš kur, kaip taisyklė, grįžtama į pagrindinį perjungimą, o tada „išeina“ - per vieną ar daugiau pasienio vartų į internetą.
Tokią schemą labai labai lengva rezervuoti tiek L3 (dinaminis maršrutas), tiek L2 (MPLS).
Galite įdiegti N+1 bet ką: pasiekti serverius, jungiklius, kraštines – ir vienaip ar kitaip rezervuoti juos automatiniam perkėlimui.
Po kelerių metų Visiems Rusijoje tapo aišku, kad ilgiau taip gyventi neįmanoma: reikia skubiai apsaugoti vaikus nuo žalingos interneto įtakos.
Reikėjo skubiai ieškoti būdų, kaip filtruoti vartotojų srautą.
Čia yra įvairių požiūrių.
Nelabai geru atveju kažkas įdedama „į tarpą“: tarp vartotojų srauto ir interneto. Analizuojamas srautas, einantis per šį „kažką“ ir, pavyzdžiui, padirbtas paketas su peradresavimu siunčiamas į abonentą.
Šiek tiek geresniu atveju – jei leidžia srauto apimtys – galite padaryti nedidelį triuką su ausimis: siųsti filtruoti tik srautą, kilusį iš vartotojų tik tais adresais, kuriuos reikia filtruoti (tam galite paimti IP adresus ten nurodytas iš registro arba papildomai išspręsti esamus registre esančius domenus).
Vienu metu šiems tikslams parašiau paprastą - nors aš net nedrįstu jo taip vadinti. Tai labai paprasta ir ne itin produktyvu – tačiau tai leido mums ir dešimtims (jei ne šimtams) kitų tiekėjų iš karto neišmokėti milijonų pramoninėms DPI sistemoms, tačiau suteikė keletą papildomų metų laiko.
Beje, apie tuometinį ir dabartinį DPIBeje, daugelis įsigijusių tuo metu rinkoje esančias DPI sistemas jau buvo jas išmetę. Na, jie tam neskirti: šimtai tūkstančių adresų, dešimtys tūkstančių URL.
Ir tuo pat metu vietiniai gamintojai labai stipriai pakilo į šią rinką. Nekalbu apie aparatūros komponentą – čia visiems viskas aišku, bet programinė įranga – pagrindinis dalykas, kurį turi DPI – galbūt šiandien, jei ne pati pažangiausia pasaulyje, tai tikrai a) tobulinama šuoliais, ir b) supakuoto produkto kaina – tiesiog nepalyginama su užsienio konkurentais.
Norėčiau didžiuotis, bet šiek tiek liūdna =)
Dabar viskas atrodė taip:
Dar po poros metų visi jau turėjo auditorius; Registre atsirado vis daugiau išteklių. Kai kuriai senesnei įrangai (pavyzdžiui, Cisco 7600) „šoninio filtravimo“ schema tiesiog tapo nebetaikoma: 76 platformose maršrutų skaičius ribojamas iki devynių šimtų tūkstančių, o vien IPv4 maršrutų skaičius šiandien artėja prie 800. tūkstantis. O jei tai taip pat ipv6... Ir taip pat... kiek ten kainuoja? 900000 XNUMX individualių adresų RKN draudime? =)
Kažkas perėjo prie schemos su viso pagrindinio srauto atspindėjimu į filtravimo serverį, kuris turėtų išanalizuoti visą srautą ir, jei randama kažkas blogo, siųsti RST abiem kryptimis (siuntėjui ir gavėjui).
Tačiau kuo didesnis srautas, tuo ši schema mažiau taikoma. Jei apdorojimas šiek tiek vėluoja, veidrodinis srautas tiesiog praskris nepastebimai, o paslaugų teikėjas gaus puikią ataskaitą.
Vis daugiau tiekėjų yra priversti diegti įvairaus patikimumo DPI sistemas greitkeliuose.
Prieš metus ar dvejus Pasak gandų, beveik visi FSB pradėjo reikalauti iš tikrųjų įrengti įrangą (anksčiau dauguma paslaugų teikėjų buvo valdomi gavus valdžios institucijų leidimą SORM planas - operatyvinių priemonių planas, jei prireiktų ką nors kur nors rasti)
Be pinigų (ne visai didelių, bet vis tiek milijonų), SORM prireikė daug daugiau manipuliacijų su tinklu.
- Prieš nat vertimą SORM turi matyti „pilkus“ vartotojų adresus
- SORM turi ribotą tinklo sąsajų skaičių
Todėl, visų pirma, turėjome gerokai perdaryti dalį branduolio – tiesiog tam, kad surinktume vartotojų srautą į prieigos serverius kažkur vienoje vietoje. Norėdami tai atspindėti SORM su keliomis nuorodomis.
Tai yra, labai supaprastinta, buvo (kairėje) ir tapo (dešinėje):
Dabar Dauguma paslaugų teikėjų taip pat reikalauja įdiegti SORM-3, kuris, be kita ko, apima nat transliacijų registravimą.
Šiems tikslams mes taip pat turėjome pridėti atskirą NAT įrangą į aukščiau pateiktą diagramą (būtent tai, kas aptarta pirmoje dalyje). Be to, pridėkite tam tikra tvarka: kadangi SORM turi „matyti“ srautą prieš versdamas adresus, srautas turi vykti griežtai taip: vartotojai -> perjungimas, branduolys -> prieigos serveriai -> SORM -> NAT -> perjungimas, branduolys - > Internetas. Norėdami tai padaryti, siekdami pelno turėjome tiesiogine prasme „pasukti“ eismo srautus kita kryptimi, o tai taip pat buvo gana sunku.
Apibendrinant: per pastaruosius dešimt metų pagrindinė vidutinio paslaugų teikėjo konstrukcija tapo daug kartų sudėtingesnė, o papildomų gedimų taškų (tiek įrangos, tiek atskirų perjungimo linijų pavidalu) žymiai padaugėjo. Tiesą sakant, pats reikalavimas „matyti viską“ reiškia šio „visko“ sumažinimą iki vieno taško.
Manau, kad tai gali būti gana skaidriai ekstrapoliuota į dabartines iniciatyvas suvereni Runetą, ją apsaugoti, stabilizuoti ir tobulinti :)
Ir Yarovaya vis dar priekyje.
Šaltinis: www.habr.com