Hy frege my nei dizze post .
Ik sitearje it hjir:
hjoed at 18:53
Ik wie hjoed bliid mei de provider. Tegearre mei de fernijing fan it site blocking systeem, syn mailer mail.ru waard ferbean. Ik haw al roppen technyske stipe sûnt de moarns, mar se kinne neat dwaan. De provider is lyts, en blykber hegere oanbieders blokkearje it. Ik fernaam ek in fertraging yn 'e iepening fan alle siden, miskien se ynstallearre in soarte fan krom DLP? Earder wiene d'r gjin problemen mei tagong. De ferneatiging fan RuNet bart krekt foar myn eagen ...
It feit is dat it liket dat wy deselde provider binne :)
En yndied, Ik ried hast de oarsaak fan 'e problemen mei mail.ru (hoewol't wy in lange tiid wegere te leauwen yn sa'n ding).
It folgjende sil wurde ferdield yn twa dielen:
- de redenen foar ús hjoeddeistige problemen mei mail.ru en de spannende syktocht om se te finen
- it bestean fan ISP yn de hjoeddeiske realiteiten, de stabiliteit fan de soevereine RuNet.
Tagonklikheid problemen mei mail.ru
Och, it is in hiel lang ferhaal.
It feit is dat om de easken fan 'e steat út te fieren (mear details yn it twadde diel), wy kochten, konfigureare en ynstalleare guon apparatuer - sawol foar it filterjen fan ferbeane boarnen as foar it útfieren abonnees.
In skoft lyn hawwe wy úteinlik de netwurkkearn sa opboud dat alle abonneeferkear troch dizze apparatuer strikt yn 'e goede rjochting gie.
In pear dagen lyn hawwe wy ferbean filtering derop ynskeakele (wylst it âlde systeem wurkje litte) - alles like goed te gean.
Dêrnei begon se stadichoan NAT yn te skeakeljen op dizze apparatuer foar ferskate dielen fan abonnees. Ut it each like alles ek goed te gean.
Mar hjoed, nei it ynskeakeljen fan NAT op 'e apparatuer foar it folgjende diel fan abonnees, waarden wy fan' e moarn te krijen mei in fatsoenlik oantal klachten oer net-beskikberens of foar in part beskikber en oare boarnen fan Mail Ru Group.
Se begûnen te kontrolearjen: earne wat soms, ynsidinteel stjoert yn antwurd op fersiken eksklusyf oan mail.ru netwurken. Boppedat, it stjoert in ferkeard oanmakke (sûnder ACK), fansels keunstmjittige TCP RST. Dit is hoe't it der út seach:
Fansels wiene de earste gedachten oer de nije apparatuer: ferskriklike DPI, gjin fertrouwen yn it, jo witte noait wat it kin dwaan - ommers, TCP RST is in frij gewoan ding ûnder blokkearjende ark.
Ferûnderstelling Wy sette ek it idee nei foaren dat immen "superior" filtert, mar hawwe it fuortendaliks wegere.
As earste, wy hawwe genôch ferstannige uplinks sadat wy net hoege te lije as dit :)
Twads binne wy ferbûn mei ferskate yn Moskou, en ferkear nei mail.ru giet troch har - en se hawwe gjin ferantwurdlikheden noch in oar motyf om ferkear te filterjen.
De folgjende helte fan 'e dei waard bestege oan wat normaal sjamanisme neamd wurdt - tegearre mei de apparatuerferkeaper, wêrfoar wy har tankje, joegen se net op :)
- filterjen wie folslein útskeakele
- NAT waard útskeakele mei it nije skema
- de test PC waard pleatst yn in apart isolearre pool
- IP-adressen feroare
Yn 'e middei waard in firtuele masine tawiisd dy't ferbûn is mei it netwurk neffens it skema fan in gewoane brûker, en fertsjintwurdigers fan' e ferkeaper krigen tagong ta har en de apparatuer. It sjamanisme gie troch :)
Uteinlik stelde de fertsjintwurdiger fan de ferkeaper mei fertrouwen dat de hardware der hielendal neat mei te krijen hie: de rsts komme earne heger wei.
remarkOp dit punt kin immen sizze: mar it wie folle makliker om in dump te nimmen net fan 'e test-PC, mar fan' e snelwei boppe de DPI?
Nee, spitigernôch, in dump nimme (en sels gewoan spegelje) 40+gbps is hielendal net triviaal.
Dêrnei wie der jûns neat mear te dwaan as werom te gean nei de oanname fan frjemde filtraasje earne boppe.
Ik seach troch hokker IX it ferkear nei de MRG-netwurken no trochgiet en annulearre gewoan de bgp-sesjes deroan. En - sjoch! - alles kaam fuortendaliks werom nei normaal 🙁
Oan 'e iene kant is it spitich dat de hiele dei nei it probleem siket, hoewol it yn fiif minuten oplost waard.
Oan de oare kant:
- yn myn ûnthâld is dit in ding dat net earder wie. Lykas ik hjirboppe al skreau - IX echt it hat gjin punt yn it filterjen fan transitferkear. Se hawwe normaal hûnderten gigabits / terabits per sekonde. Ik koe my gewoan net serieus soks foarstelle oant koartlyn.
- in ongelooflijk gelokkich tafal fan omstannichheden: in nije komplekse hardware dy't net spesjaal fertroud is en wêrfan it net dúdlik is wat kin wurde ferwachte - spesifyk oanpast foar blokkearjen fan boarnen, ynklusyf TCP RST's
It NOC fan dizze ynternetútwiksel is op it stuit op syk nei in probleem. Neffens har (en ik leau se) hawwe se gjin spesjaal ynset filtraasjesysteem. Mar, tank oan de himel, de fierdere syktocht is net mear ús probleem :)
Dit wie in lyts besykjen om mysels te rjochtfeardigjen, begryp asjebleaft en ferjaan :)
PS: Ik neam bewust de fabrikant fan DPI / NAT of IX net (yn feite haw ik gjin spesjale klachten oer har, it wichtichste is om te begripen wat it wie)
De realiteit fan hjoed (lykas fan juster en fan juster) út it eachpunt fan in ynternetprovider
Ik haw de lêste wiken de kearn fan it netwurk signifikant opnij opboud, in protte manipulaasjes "foar winst" útfiere, mei it risiko dat it live brûkersferkear signifikant beynfloedet. Sjoen de doelen, resultaten en gefolgen fan dit alles, moreel is it allegear frij lestich. Benammen - nochris harkje nei prachtige taspraken oer it beskermjen fan 'e stabiliteit fan' e Runet, soevereiniteit, ensfh. ensafuorthinne.
Yn dizze seksje sil ik besykje de "evolúsje" fan 'e netwurkkearn fan in typyske ISP oer de ôfrûne tsien jier te beskriuwen.
Tsien jier lyn.
Yn dy sillige tiden koe de kearn fan in providernetwurk sa ienfâldich en betrouber wêze as in file:
Yn dizze heul, heul ferienfâldige ôfbylding binne d'r gjin stammen, ringen, ip / mpls-routing.
Syn essinsje is dat brûkersferkear úteinlik kaam ta it wikseljen fan kernelnivo - fan wêr't it gie , fan wêr't, as regel, werom nei de kearn skeakeljen, en dan "út" - fia ien of mear grinspoarten nei it ynternet.
Sa'n skema is heul, heul maklik te reservearjen sawol op L3 (dynamyske rûte) as op L2 (MPLS).
Jo kinne N+1 fan alles ynstallearje: tagong ta tsjinners, skeakels, grinzen - en op ien of oare manier reservearje se foar automatyske failover.
Nei in pear jier It waard foar elkenien yn Ruslân dúdlik dat it ûnmooglik wie om sa langer te libjen: it wie driuwend om bern te beskermjen fan 'e skealike ynfloed fan it ynternet.
D'r wie in driuwend ferlet om manieren te finen om brûkersferkear te filterjen.
D'r binne hjir ferskate oanpak.
Yn in net hiel goed gefal wurdt wat "yn it gat" set: tusken brûkersferkear en ynternet. It ferkear dat troch dit "wat" giet, wurdt analysearre en bygelyks in neppakket mei in trochferwizing wurdt nei de abonnee stjoerd.
Yn in wat better gefal - as ferkearsvoluminten it tastean - kinne jo in lyts trúkje dwaan mei jo earen: stjoer foar filterjen allinich ferkear dat fan brûkers komt nei dy adressen dy't moatte wurde filtere (om dit te dwaan kinne jo de IP-adressen nimme oantsjutte dêr út it register, of ek besteande domeinen yn it register oplosse).
Op ien kear, foar dizze doelen, skreau ik in ienfâldige - al doar ik him net iens sa te neamen. It is heul ienfâldich en net heul produktyf - lykwols, it liet ús en tsientallen (as net hûnderten) oare providers net fuortendaliks miljoenen útjaan op yndustriële DPI-systemen, mar joech ferskate ekstra jierren fan tiid.
Troch de wei, oer de doe en hjoeddeiske DPITrouwens, in protte dy't kochten de DPI-systemen dy't op 'e merke op dat stuit beskikber wiene, hienen se al fuortsmiten. No, se binne hjir net foar ûntworpen: hûnderttûzenen adressen, tsientûzenen URL's.
En tagelyk binne ynlânske produsinten tige sterk opstien nei dizze merk. Ik haw it net oer de hardware-komponint - alles is hjir dúdlik foar elkenien, mar software - it wichtichste ding dat DPI hat - is miskien hjoed, as net de meast avansearre yn 'e wrâld, dan wis a) ûntwikkeljen mei sprongen en grinzen, en b) op 'e priis fan in doaze produkt - gewoan net te fergelykjen mei bûtenlânske konkurrinten.
Ik soe graach grutsk wêze, mar in bytsje tryst =)
No seach alles der sa út:
Oer noch in pear jier elkenien hie al rekkenkeamer; Der wiene mear en mear middels yn it register. Foar guon âldere apparatuer (bgl tûzen. En as it ek ipv7600 is ... En ek ... hoefolle is der? 76 yndividuele adressen yn it RKN-ferbod? =)
Immen skeakele nei in skema mei ôfspegeljen fan alle rêchbonke ferkear nei in filterjen tsjinner, dat moat analysearje de hiele stream en, as der wat slims wurdt fûn, stjoer RST yn beide rjochtingen (stjoerder en ûntfanger).
Hoe mear ferkear lykwols, hoe minder fan tapassing dizze regeling is. As d'r de minste fertraging is yn 'e ferwurking, sil it spegele ferkear gewoan ûngemurken troch fleane, en de provider sil in boete rapport krije.
Hieltyd mear providers wurde twongen om DPI-systemen te ynstallearjen fan ferskate graden fan betrouberens oer snelwegen.
In jier as twa lyn neffens geroften, hast alle FSB begûn te easkje de eigentlike ynstallaasje fan apparatuer (earder, de measte providers beheare mei goedkarring fan de autoriteiten SORM plan - in plan fan operasjonele maatregels yn gefal fan needsaak om earne wat te finen)
Neist jild (net krekt exorbitant, mar noch miljoenen), SORM fereasket folle mear manipulaasjes mei it netwurk.
- SORM moat "grize" brûkersadressen sjen foardat de nat oersetting
- SORM hat in beheind oantal netwurkynterfaces
Dêrom moasten wy benammen in stik fan 'e kernel opnij opbouwe - gewoan om brûkerferkear te sammeljen nei de tagongsservers earne op ien plak. Om it yn SORM te spegeljen mei ferskate keppelings.
Dat is, heul ferienfâldige, it wie (lofts) vs waard (rjochts):
No De measte oanbieders fereaskje ek de ymplemintaasje fan SORM-3 - dy't ûnder oare it loggjen fan nat-útstjoerings omfettet.
Foar dizze doelen, wy moasten ek tafoegje aparte apparatuer foar NAT oan it diagram hjirboppe (krekt wat wurdt besprutsen yn it earste diel). Foegje boppedat ta yn in bepaalde folchoarder: om't SORM it ferkear "sjogge" moat foardat adressen oersette, moat it ferkear strikt sa folgje: brûkers -> wikselje, kernel -> tagongstsjinners -> SORM -> NAT -> wikselje, kernel - > Ynternet. Om dit te dwaan, moasten wy ferkearsstreamen letterlik "draaie" yn 'e oare rjochting foar winst, wat ek frij lestich wie.
Gearfetsjend: oer de ôfrûne tsien jier is it kearnûntwerp fan in trochsneed provider in protte kearen komplekser wurden, en ekstra punten fan mislearring (sawol yn 'e foarm fan apparatuer as yn' e foarm fan ienige skeakellinen) binne gâns tanommen. Eigentlik betsjuttet de eask om "alles te sjen" it ferminderjen fan dit "alles" ta ien punt.
Ik tink dat dit frij transparant kin wurde ekstrapolearre nei hjoeddeistige inisjativen om de Runet te soevereinisearjen, it te beskermjen, it te stabilisearjen en it te ferbetterjen :)
En Yarovaya is noch altyd foarút.
Boarne: www.habr.com