Spodbudil me je k tej objavi .
Citiram tukaj:
danes ob 18:53
Danes sem bil zadovoljen s ponudnikom. Skupaj s posodobitvijo sistema za blokiranje strani je bil prepovedan njegov mailer mail.ru, od jutra kličem tehnično podporo, vendar ne morejo storiti nič. Ponudnik je majhen in očitno ga višji ponudniki blokirajo. Opazil sem tudi upočasnitev odpiranja vseh strani, morda so namestili kakšen pokvarjen DLP? Prej ni bilo težav z dostopom. Uničenje Runeta se dogaja pred mojimi očmi ...
Dejstvo je, da se zdi, da smo isti ponudnik :)
In res, Skoraj sem uganil vzrok težav z mail.ru (čeprav dolgo nismo verjeli v kaj takega).
Kar sledi bo razdeljeno na dva dela:
- razloge za naše trenutne težave z mail.ru in razburljivo iskanje le-teh
- obstoj ponudnika internetnih storitev v današnji realnosti, stabilnost suverenega RuNeta.
Težave z dostopnostjo mail.ru
Oh, to je kar dolga zgodba.
Dejstvo je, da smo za izvajanje zahtev države (podrobneje v drugem delu) kupili, konfigurirali in namestili nekaj opreme – tako za filtriranje prepovedanih virov kot za izvajanje naročnikov.
Pred časom smo končno obnovili jedro omrežja na način, da je ves naročniški promet skozi to opremo potekal strogo v pravi smeri.
Pred nekaj dnevi smo na njem vklopili prepovedano filtriranje (medtem ko smo pustili stari sistem delovati) - vse je bilo videti dobro.
Nato so postopoma začeli omogočati NAT na tej opremi za različne dele naročnikov. Tudi po videzu se je vse zdelo dobro.
Toda danes, ko smo omogočili NAT na opremi za naslednji del naročnikov, smo se od samega jutra soočili z dostojnim številom pritožb glede nedosegljivosti ali delne razpoložljivosti in drugi viri skupine Mail Ru.
Začeli so preverjati: nekje nekaj včasih, občasno pošlje kot odgovor na zahteve izključno za omrežja mail.ru. Poleg tega pošlje nepravilno generiran (brez ACK), očitno umeten TCP RST. Takole je to izgledalo:
Seveda so bile prve misli o novi opremi: grozen DPI, brez zaupanja vanj, nikoli ne veš, kaj zmore - navsezadnje je TCP RST precej običajna stvar med orodji za blokiranje.
Predpostavka Predstavili smo tudi idejo, da filtrira nekdo »nadrejeni«, a smo jo takoj zavrgli.
Prvič, imamo dovolj zdrave uplinke, da nam ni treba tako trpeti :)
Drugič, povezani smo z več v Moskvi in promet na mail.ru gre prek njih - in nimajo ne odgovornosti ne katerega koli drugega motiva za filtriranje prometa.
Naslednja polovica dneva je minila v običajnem šamanizmu - skupaj s prodajalcem opreme, za kar se jim zahvaljujemo, niso odnehali :)
- filtriranje je bilo popolnoma onemogočeno
- NAT je bil onemogočen z uporabo nove sheme
- testni računalnik je bil postavljen v ločen izoliran bazen
- Naslov IP spremenjen
V popoldanskih urah je bil dodeljen virtualni stroj, ki se je povezal v omrežje po shemi navadnega uporabnika, predstavnikom prodajalca pa je bil omogočen dostop do njega in opreme. Šamanizem se nadaljuje :)
Na koncu je predstavnik prodajalca samozavestno izjavil, da strojna oprema nima prav nič s tem: prvi prihajajo od nekje višje.
ObvestiloNa tej točki lahko nekdo reče: a je bilo veliko lažje vzeti odlagališče ne iz testnega računalnika, ampak z avtoceste nad DPI?
Ne, na žalost narediti dump (in celo samo zrcaljenje) 40+gbps sploh ni trivialno.
Po tem zvečer ni preostalo drugega kot vrnitev k domnevi čudne filtracije nekje zgoraj.
Pogledal sem, skozi kateri IX zdaj poteka promet do omrežij MRG, in preprosto preklical seje bgp do njega. In – glej ga zlomka! - takoj se je vse vrnilo v normalno stanje 🙁
Po eni strani je škoda, da je cel dan iskal problem, čeprav je bil rešen v petih minutah.
Po drugi strani:
— v mojem spominu je to nekaj brez primere. Kot sem že napisal zgoraj - IX res nima smisla filtrirati tranzitnega prometa. Običajno imajo na stotine gigabitov/terabitov na sekundo. Česa takega si preprosto nisem mogel resno predstavljati do nedavnega.
— neverjetno srečno naključje okoliščin: nova zapletena strojna oprema, ki ji ni posebej zaupanja in od katere ni jasno, kaj lahko pričakujemo — prilagojena posebej za blokiranje virov, vključno s protokoli TCP RST
NOC te internetne izmenjave trenutno išče težavo. Po njihovem mnenju (in jaz jim verjamem) nimajo nobenega posebej nameščenega filtrirnega sistema. Ampak, hvala nebesom, nadaljnje iskanje ni več naš problem :)
To je bil majhen poskus opravičevanja, prosim za razumevanje in odpuščanje :)
PS: namerno ne imenujem proizvajalca DPI/NAT ali IX (pravzaprav niti nimam posebnih pritožb glede njih, glavna stvar je razumeti, kaj je bilo)
Današnja (pa tudi včerajšnja in predvčerajšnja) realnost z vidika internetnega ponudnika
Zadnje tedne sem porabil za pomembno prenovo jedra omrežja, pri čemer sem izvedel kup manipulacij "za dobiček", s tveganjem, da bi bistveno vplival na promet uporabnikov v živo. Glede na cilje, rezultate in posledice vsega tega je moralno vse skupaj precej težko. Še posebej - še enkrat poslušati lepe govore o zaščiti stabilnosti Runeta, suverenosti itd. in tako naprej.
V tem razdelku bom poskušal opisati "razvoj" omrežnega jedra tipičnega ponudnika internetnih storitev v zadnjih desetih letih.
Pred desetimi leti.
V tistih blagoslovljenih časih je lahko jedro omrežja ponudnikov preprosto in zanesljivo kot prometni zastoj:
Na tej zelo, zelo poenostavljeni sliki ni nobenih povezav, obročev, usmerjanja ip/mpls.
Njegovo bistvo je, da je uporabniški promet na koncu prišel do preklopa ravni jedra – od koder je šel do , od koder praviloma nazaj do jedrnega preklopa in nato "ven" - skozi enega ali več mejnih prehodov v internet.
Takšno shemo je zelo, zelo enostavno rezervirati tako na L3 (dinamično usmerjanje) kot na L2 (MPLS).
Namestite lahko N+1 česar koli: dostopovnih strežnikov, stikal, mej - in jih tako ali drugače rezervirate za samodejno preklop.
Po nekaj letih Vsem v Rusiji je postalo jasno, da tako ni več mogoče živeti: otroke je treba nujno zaščititi pred škodljivim vplivom interneta.
Nujno je bilo treba najti načine za filtriranje uporabniškega prometa.
Tukaj so različni pristopi.
V ne preveč dobrem primeru se nekaj postavi "v vrzel": med uporabniški promet in internet. Promet, ki gre skozi to »nekaj«, se analizira in na primer pošilja lažni paket s preusmeritvijo k naročniku.
V nekoliko boljšem primeru - če obseg prometa dopušča - lahko naredite majhen trik s svojimi ušesi: pošljete v filtriranje samo promet, ki izvira od uporabnikov, samo na tiste naslove, ki jih je treba filtrirati (za to lahko vzamete naslove IP tam določene iz registra ali dodatno razrešite obstoječe domene v registru).
Nekoč sem za te namene napisal preprosto - čeprav si ga sploh ne upam tako klicati. Je zelo preprost in premalo produktiven - vendar je nam in na desetine (če ne stotine) drugih ponudnikov omogočil, da niso takoj odšteli milijonov za industrijske sisteme DPI, ampak je dal nekaj dodatnih let časa.
Mimogrede, o takratnem in sedanjem DPIMimogrede, mnogi, ki so kupili sisteme DPI, ki so bili takrat na trgu, so jih že zavrgli. No, niso zasnovani za to: na stotine tisoč naslovov, na desettisoče URL-jev.
In hkrati so se domači proizvajalci zelo močno povzpeli na ta trg. Ne govorim o strojni komponenti - tukaj je vsem vse jasno, ampak programska oprema - glavna stvar, ki jo ima DPI - je morda danes, če že ne najnaprednejša na svetu, potem zagotovo a) razvija se skokovito, in b) po ceni izdelka v škatli - preprosto neprimerljivo s tujimi konkurenti.
Rad bi bil ponosen, a malo žalosten =)
Zdaj je vse izgledalo takole:
Čez še nekaj let vsi so že imeli revizorje; Virov v registru je bilo vedno več. Za nekatere starejše naprave (na primer Cisco 7600) je shema »stranskega filtriranja« preprosto postala neuporabna: število poti na 76 platformah je omejeno na približno devetsto tisoč, medtem ko se samo število poti IPv4 danes približuje 800. tisoč. In če je tudi ipv6 ... In tudi ... koliko je tam? 900000 posameznih naslovov v prepovedi RKN? =)
Nekdo je prešel na shemo z zrcaljenjem celotnega hrbteničnega prometa na filtrirni strežnik, ki naj analizira celoten tok in, če se najde kaj slabega, pošlje RST v obe smeri (pošiljatelja in prejemnika).
Vendar, več kot je prometa, manj uporabna je ta shema. Če pride do najmanjše zamude pri obdelavi, bo zrcaljeni promet preprosto preletel neopazno, ponudnik pa bo prejel dobro poročilo.
Vedno več ponudnikov je prisiljenih vgraditi sisteme DPI različnih stopenj zanesljivosti po avtocestah.
Leto ali dve nazaj po govoricah je skoraj vsa FSB začela zahtevati dejansko namestitev opreme (prej je večina ponudnikov upravljala z odobritvijo oblasti Načrt SORM - načrt operativnih ukrepov, če bi morali nekje kaj najti)
Poleg denarja (ne ravno pretiranega, a vseeno milijonskega) je SORM zahteval še veliko več manipulacij z omrežjem.
- SORM mora pred prevajanjem nat videti "sive" naslove uporabnikov
- SORM ima omejeno število omrežnih vmesnikov
Predvsem zato smo morali delček jedra močno prenoviti - zgolj zato, da bi nekje na enem mestu zbirali uporabniški promet do dostopnih strežnikov. Da bi ga zrcalili v SORM z več povezavami.
Se pravi, zelo poenostavljeno, bilo je (levo) vs postalo (desno):
Zdaj Večina ponudnikov zahteva tudi implementacijo SORM-3 - ki med drugim vključuje beleženje nat oddaj.
Za te namene smo morali zgornjemu diagramu dodati tudi ločeno opremo za NAT (natančno to, kar je obravnavano v prvem delu). Poleg tega dodajte v določenem vrstnem redu: ker mora SORM "videti" promet pred prevajanjem naslovov, mora promet potekati strogo takole: uporabniki -> preklapljanje, jedro -> dostopni strežniki -> SORM -> NAT -> preklapljanje, jedro - > Internet. Za to smo morali zaradi dobička dobesedno »obrniti« prometne tokove v drugo smer, kar je bilo tudi precej težko.
Če povzamemo: v zadnjih desetih letih je osnovna zasnova povprečnega ponudnika postala mnogokrat bolj kompleksna, dodatne točke odpovedi (tako v obliki opreme kot v obliki posameznih stikalnih vodov) pa so se znatno povečale. Pravzaprav zahteva po »videti vse« pomeni redukcijo tega »vsega« na eno točko.
Mislim, da je to mogoče precej pregledno ekstrapolirati na trenutne pobude za suverenizacijo Runeta, njegovo zaščito, stabilizacijo in izboljšanje :)
In Yarovaya je še naprej.
Vir: www.habr.com