Iruzkinari erantzun zehatza, baita Errusiar Federazioko hornitzaileen bizitzari buruzko apur bat ere

Mezu honetara bultzatu nau hau da iruzkina.

Hemen aipatzen dut:

kaleman gaur 18:53etan

Gaur hornitzailearekin gustura nago. Guneak blokeatzeko sistema eguneratzearekin batera, bere posta elektronikoko mail.ru debekatu egin zuten.Goizetik laguntza teknikoa deitzen ari naiz, baina ezin dute ezer egin. Hornitzailea txikia da, eta itxuraz maila altuagoko hornitzaileek blokeatzen dute. Gune guztien irekieran moteltze bat ere nabaritu nuen, agian DLP makurren bat instalatu zuten? Aurretik ez zegoen arazorik sarbidearekin. RuNet-en suntsipena nire begien aurrean gertatzen ari da...

Kontua da badirudi hornitzaile bera garela :)

Eta hain zuzen ere, kaleman Mail.ru-rekin arazoen zergatia ia asmatzen nuen (nahiz eta luzaroan horrelakorik sinisteari uko egin genion).

Hurrengoa bi zatitan banatuko da:

1. mail.ru-rekin gaur egun ditugun arazoen arrazoiak eta horiek aurkitzeko bilaketa zirraragarria
2. ISPren existentzia gaur egungo errealitateetan, RuNet subiranoaren egonkortasuna.

Mail.ru-rekin irisgarritasun arazoak

Oh, nahiko istorio luzea da.

Izan ere, estatuaren eskakizunak ezartzeko (xehetasun gehiago bigarren zatian), ekipamendu batzuk erosi, konfiguratu eta instalatu ditugu, bai debekatutako baliabideak iragazteko, bai inplementatzeko. NAT itzulpenak harpidedunak.

Duela denbora pixka bat, azkenean sarearen nukleoa berreraiki genuen, harpidedunen trafiko guztia ekipamendu honetatik zorrozki norabide egokian igarotzeko.

Duela egun batzuk debekatutako iragazketa aktibatu genuen (sistema zaharra funtzionatzen utzi genuen bitartean) - dena ondo joan zela zirudien.

Ondoren, pixkanaka-pixkanaka ekipo honetan NAT gaitzen hasi ziren harpidedunen zati ezberdinetarako. Itxura ikusita, dena ere ondo joan omen zen.

Baina gaur, harpidedunen hurrengo zatirako ekipoan NAT gaituta, goizetik bertatik kexa dezente izan ditugu erabilgarritasun edo erabilgarritasun partzialagatik. mail.ru eta Mail Ru Taldeko beste baliabide batzuk.

Egiaztatzen hasi ziren: zerbait nonbait batzuetan, noizean behin bidaltzen du TCP RST mail.ru sareei soilik egindako eskaerei erantzunez. Gainera, gaizki sortutako (ACK gabe), TCP RST artifiziala bidaltzen du. Honela zirudien:

Jakina, lehen pentsamenduak ekipamendu berriei buruzkoak ziren: DPI ikaragarria, ez da konfiantzarik, inoiz ez dakizu zer egin dezakeen - azken finean, TCP RST nahiko ohikoa da blokeo tresnen artean.

Suposizioa kaleman “Goiko” norbait iragazten ari den ideia ere plazaratu genuen, baina berehala baztertu genuen.

Lehenik eta behin, goranzko esteka nahikoak ditugu, horrela sufritu beharrik ez izateko :)

Bigarrenik, hainbatekin lotuta gaude IX Moskun, eta mail.ru-rako trafikoa haietatik pasatzen da, eta ez dute ez erantzukizunik ezta trafikoa iragazteko beste motiborik ere.

Egunaren hurrengo erdia xamanismoa deitzen den horretan igaro zen - ekipamendu-saltzailearekin batera, eskerrak ematen dizkiegu, ez zuten amore eman :)

• iragazketa guztiz desgaituta zegoen
• NAT desgaitu egin zen eskema berria erabiliz
• probako ordenagailua igerileku isolatu batean jarri zen
• IP helbidea aldatu da

Arratsaldean, ohiko erabiltzaile baten eskemaren arabera sarera konektatzen zen makina birtual bat esleitu zen, eta horra eta ekipamendurako sarbidea eman zitzaien saltzailearen ordezkariei. Xamanismoak jarraitu zuen :)

Azkenean, saltzaileen ordezkariak ziur esan zuen hardwareak ez zuela zerikusirik: lehenengoak goragotik datoz.

Kontuan izanUne honetan, norbaitek esan dezake: baina askoz errazagoa zen zabortegi bat ateratzea ez probako PCtik, baizik eta DPIaren gaineko autobidetik?

Ez, zoritxarrez, 40+gbps-ko ispilu bat hartzea (eta ispilu besterik ez) ez da batere hutsala.

Honen ostean, arratsaldean, ez zen ezer egin behar, nonbait goian filtrazio arraroaren suposiziora itzultzea baino.

MRG sareetarako trafikoa zeinetatik pasatzen ari den begiratu nuen eta bertan bgp saioak bertan behera utzi nituen. Eta - hara! - Dena berehala itzuli zen normaltasunera 🙁

Batetik, pena da egun osoa arazoaren bila pasatzea, bost minututan konpondu bazen ere.

Bestalde:

— Nire oroimenean aurrekaririk gabeko gauza bat da. Goian idatzi dudan bezala - IX benetan ez du zentzurik garraio-trafikoa iragazteak. Segundoko ehunka gigabit/terabit izan ohi dituzte. Duela gutxi arte ezin nuen horrelako zerbait serioski imajinatu.

— Zirkunstantzien kointzidentzia izugarri zorionekoa: bereziki fidagarria ez den hardware konplexu berria eta zer espero daitekeen argi ez dagoena — baliabideak blokeatzeko bereziki egokitua, TCP RSTak barne.

Interneteko truke honen NOC arazo baten bila dabil gaur egun. Haien arabera (eta uste dut), ez dute bereziki zabaldutako iragazketa sistemarik. Baina, zeruari eskerrak, bilaketa gehiago ez da gure arazoa :)

Hau nire burua justifikatzeko saiakera txiki bat izan zen, mesedez, ulertu eta barkatu :)

PS: nahita ez dut DPI/NAT edo IX fabrikatzailea izendatzen (izan ere, ez dut horiei buruzko kexa berezirik ere, gauza nagusia zer zen ulertzea da)

Gaurko errealitatea (baita atzokoa eta bezperakoa ere) Interneteko hornitzaile baten ikuspuntutik

Azken asteak sarearen muina nabarmen berreraikitzen eman ditut, manipulazio mordoa egiten "irabazirako", zuzeneko erabiltzaileen trafikoa nabarmen eragiteko arriskuarekin. Honen guztiaren helburuak, emaitzak eta ondorioak kontuan hartuta, moralki dena nahiko zaila da. Batez ere - berriro ere Runet-en egonkortasuna, subiranotasuna eta abar babesteari buruzko hitzaldi ederrak entzuten. eta abar.

Atal honetan, ISP tipiko baten sare-nukleoaren "bilakaera" deskribatzen saiatuko naiz azken hamar urteotan.

Duela hamar urte.

Garai bedeinkatu horietan, hornitzaile-sare baten muina trafiko-ilarak bezain erraza eta fidagarria izan liteke:

Oso-oso sinplifikatutako irudi honetan, ez dago trunk, eraztun, ip/mpls bideratzerik.

Bere funtsa da erabiltzaileen trafikoa azken finean nukleo-maila aldatzera iritsi zela, nondik joan zen BNG, nondik, normalean, itzulera nukleoko aldakuntzara, eta gero "kanpora" - Interneterako mugako ate baten edo gehiagoren bidez.

Halako eskema bat oso-oso erraza da L3-n (bideratze dinamikoa) eta L2-n (MPLS) erreserbatzea.

N+1 edozer gauza instala dezakezu: zerbitzariak, etengailuak, ertzak atzitu eta modu batera edo bestera hutsegite automatikorako gorde ditzakezu.

Urte gutxiren buruan Errusian denek argi geratu zen ezinezkoa zela horrela bizitzea: premiazkoa zen haurrak Interneten eragin kaltegarritik babestea.

Premiazkoa zen erabiltzaileen trafikoa iragazteko bideak aurkitzeko.

Hemen planteamendu desberdinak daude.

Kasu ez oso on batean, zerbait jartzen da “hutsunean”: erabiltzaileen trafikoaren eta Interneten artean. “Zerbait” horretatik pasatzen den trafikoa aztertzen da eta, adibidez, birbideraketa duen pakete faltsu bat bidaltzen da harpidedunari.

Kasu apur bat hobeago batean -trafiko-bolumenak ahalbidetzen badu- belarriekin trikimailu txiki bat egin dezakezu: erabiltzaileengandik sortutako trafikoa soilik iragazi behar diren helbideetara bidali iragazteko soilik (horretarako, IP helbideak har ditzakezu. erregistrotik zehaztuta, edo, gainera, erregistroan dauden domeinuak ebatzi).

Garai batean, helburu horietarako, sinple bat idatzi nuen mini dpi - hala deitzen ere ausartzen ez naizen arren. Oso sinplea da eta ez da oso produktiboa; hala ere, guri eta beste dozenaka (ehunka ez bada) hornitzaileri aukera eman zigun DPI industrial-sistemetan milioika ez ateratzeko berehala, baina hainbat urte gehiago eman zizkigun.

Bide batez, orduko eta egungo DPIri buruzBide batez, garai hartan merkatuan zeuden DPI sistemak erosi zituzten askok jada bota zituzten. Bada, ez daude horretarako diseinatuta: ehunka mila helbide, hamarnaka mila URL.

Eta, aldi berean, etxeko ekoizleak oso indartsu igo dira merkatu honetara. Ez naiz hardware osagaiaz ari - dena argi dago hemen, baina softwarea - DPIk duen gauza nagusia - beharbada gaur egun, munduko aurreratuena ez bada, zalantzarik gabe a) jauzi eta mugaz garatzen da, eta b) kutxako produktu baten prezioan -atzerriko lehiakideekin konparaezina.

Harro egon nahiko nuke, baina triste apur bat =)

Orain dena honela zegoen:

Urte pare bat gehiago barru denek jada ikuskariak zituzten; Erregistroan gero eta baliabide gehiago zeuden. Ekipo zaharrago batzuetarako (adibidez, Cisco 7600), "alboko iragazketa" eskema besterik gabe ez da aplikagarria izan: 76 plataformetan ibilbide kopurua bederatziehun mila bezalako zerbaitetara mugatzen da, eta IPv4 ibilbideen kopurua 800ra hurbiltzen ari den bitartean. mila. Eta ipv6 ere bada... Eta gainera... zenbat dago? 900000 helbide indibidual RKN debekuan? =)

Norbaitek bizkarrezurreko trafiko guztia iragazketa zerbitzari batera ispilu duen eskema batera aldatu zuen, honek fluxu osoa aztertu beharko luke eta, zerbait txarra aurkitzen bada, RST bi noranzkoetan (igorlea eta hartzailea) bidali beharko luke.

Hala ere, zenbat eta trafiko gehiago, orduan eta gutxiago aplikagarria da eskema hau. Prozesatzeko atzerapenik txikiena baldin badago, ispiluko trafikoa oharkabean igaroko da eta hornitzaileak txosten fin bat jasoko du.

Gero eta hornitzaile gehiago autobideetan fidagarritasun maila ezberdineko DPI sistemak instalatzera behartuta daude.

Duela urtebete edo bi zurrumurruen arabera, ia FSB guztiak ekipamenduen benetako instalazioa eskatzen hasi ziren SORM (lehen, hornitzaile gehienek agintarien oniritziarekin kudeatzen zuten SORM plana - Neurri operatiboen plana nonbait aurkitu behar izanez gero)

Diruaz gain (ez zehazki gehiegizkoa, baina oraindik milioika), SORMek sarearekin askoz manipulazio gehiago behar zituen.

• SORM-ek erabiltzaile-helbide "grisak" ikusi behar ditu nat itzulpenaren aurretik
• SORM sareko interfaze kopuru mugatua du

Hori dela eta, bereziki, nukleoaren zati bat berreraiki behar izan dugu, besterik gabe, nonbait leku batean sarbide-zerbitzarietarako erabiltzaileen trafikoa biltzeko. SORM-en ispilu hainbat estekarekin.

Hau da, oso sinplifikatuta, (ezkerrean) vs bihurtu zen (eskuinean):

Orain Hornitzaile gehienek SORM-3 inplementatzea ere eskatzen dute; besteak beste, nat emisioen erregistroa barne hartzen du.

Helburu horietarako, NATerako ekipamendu bereiziak ere gehitu behar izan genituen goiko diagraman (lehen zatian eztabaidatzen dena zehazki). Gainera, gehitu ordena jakin batean: SORMek helbideak itzuli aurretik trafikoa “ikusi” behar duenez, trafikoa zorrozki honela joan behar da: erabiltzaileak -> aldatzea, nukleoa -> sarbide zerbitzariak -> SORM -> NAT -> aldatzea, nukleoa - > Internet. Horretarako, literalki, trafiko-fluxuak beste noranzkoan "biratu" behar izan genituen irabaziak lortzeko, eta hori ere nahiko zaila zen.

Laburbilduz: azken hamar urteotan, batez besteko hornitzaile baten oinarrizko diseinua hainbat aldiz konplexuagoa bihurtu da, eta hutsegite puntu gehigarriak (bai ekipamendu moduan, bai kommutazio-lerro bakarrean) nabarmen handitu dira. Izan ere, "dena ikusteko" eskakizunak berak "dena" hori puntu batera murriztea dakar.

Uste dut hori nahiko garden estrapola daitekeela Runet subiranoizatzeko, babesteko, egonkortzeko eta hobetzeko egungo ekimenetara :)

Eta Yarovaya oraindik aurretik dago.

Iturria: www.habr.com