Det fik mig til at skrive dette indlĂŠg. .
Jeg bringer den her:
i dag kl. 18:53
Udbyderen glĂŠdede mig i dag. Sammen med opdateringen af blokeringen af websider, havnede mail.ru ogsĂ„ under forbud. Jeg har ringet til supporten hele morgenen, men de kan ikke gĂžre noget. Udbyderen er lille, og de bliver tilsyneladende blokeret af de stĂžrre udbydere. Jeg har ogsĂ„ bemĂŠrket en forsinkelse i Ă„bningen af alle websites, mĂ„ske har de installeret noget skĂŠvt DLP? Tidligere var der ingen problemer med adgangen. Nedbrydningen af runet sker lige foran mine ĂžjneâŠ
Sagen er, at det ser ud til, at vi er den udbyder đ
Og ja, jeg gÊttede nÊsten rigtigt med hensyn til problemerne med mail.ru (selvom vi lÊnge nÊgtede at tro pÄ det).
Den nĂŠste del vil blive delt op i to dele:
- Ă„rsagerne til vores nuvĂŠrende problemer med mail.ru og en spĂŠndende quest for at finde dem.
- eksistensen af ISPer i dagens realiteter, stabiliteten i det suverĂŠne runet.
Problemer med tilgĂŠngeligheden af mail.ru.
Ă h, det er en ret lang historie.
Sagen er, at for at opfylde statens krav (mere i anden del) har vi kĂžbt, konfigureret og installeret noget udstyr â bĂ„de til filtrering af forbudte ressourcer og til at udfĂžre. af abonnenter.
For nogen tid siden omstrukturerede vi endelig netvÊrkskernen, sÄ al trafik fra abonnenter passerede gennem dette udstyr strengt i den rigtige retning.
For nogle dage siden aktiverede vi filtreringen af det forbudte (samtidig med at vi lod det gamle system kĂžre) â det sĂ„ ud til at gĂ„ godt.
Derefter begyndte vi gradvist at aktivere NAT for forskellige grupper af abonnenter pÄ dette udstyr. Det sÄ ogsÄ ud til at gÄ fint.
Men i dag, efter at have aktiveret NAT for endnu en gruppe abonnenter â stĂždte vi om morgenen pĂ„ et betydeligt antal klager over utilgĂŠngelighed eller delvis tilgĂŠngelighed og andre ressourcer fra Mail Ru Group.
Vi begyndte at tjekke: noget sender et eller andet sted, nogle gange,, sporadisk, sender tilbage som svar pÄ anmodninger udelukkende til netvÊrkene mail.ru. Desuden sender det en fejlgenereret (uden ACK), Äbenlyst kunstig TCP RST. SÄdan sÄ det ud:
SelvfĂžlgelig var de fĂžrste tanker om det nye udstyr: skrĂŠmmende DPI, ingen tillid til det, hvad nu hvis det finder pĂ„ noget â for TCP RST er ret almindeligt blandt blokeringvĂŠrktĂžjer.
Antagelsen om at nogen 'overordnet' filtrerer, satte vi ogsĂ„ frem â men afviste det straks.
For det fĂžrste har vi rimeligt solide uplinks, sĂ„ vi lider ikke under sĂ„dan noget đ
For det andet er vi tilsluttet flere i Moskva, og trafikken til mail.ru gĂ„r netop igennem dem â og de har hverken forpligtelser eller nogen anden motivation for at filtrere trafikken.
Den nĂŠste halvdel af dagen blev brugt pĂ„ det, der normalt kaldes shamanisme â sammen med udstyrsleverandĂžren, tak for det, gav vi ikke op đ
- filtreringen blev helt deaktiveret
- NAT blev deaktiveret efter et nyt schema
- test-PC'en blev taget ud i en separat isoleret pulje
- IP-adresseringen blev ĂŠndret
I den anden halvdel af dagen blev der tildelt en virtuel maskine, der gik pĂ„ nettet som en almindelig bruger, og bĂ„de maskinen og udstyret fik adgang af reprĂŠsentanterne fra leverandĂžren. Shamanismen fortsatte đ
Til slut erklĂŠrede reprĂŠsentanten fra leverandĂžren med sikkerhed, at udstyret absolut ikke var skyld i det: rst'erne kommer et sted fra hĂžjere op.
BemÊrkHer kan nogen mÄske udtale sig: men det ville da vÊre meget lettere at tage dumpen ikke fra test-PC'en, men fra hovedlinjen over DPI?
Nej, desvĂŠrre er det slet ikke trivielt at tage en dump (og endda bare spejle) 40+ gbps.
Efter dette, allerede om aftenen â var der ikke andet at gĂžre end at vende tilbage til antagelsen om en underlig filtrering et sted hĂžjere op.
Jeg kiggede pĂ„, gennem hvilken IX trafikken nu gĂ„r til MRG-netvĂŠrkene og slukkede simpelthen bgp-sessionerne til det. Og â oh miracle! â alt normaliserede sig straks đ
PĂ„ den ene side â det er virkelig ĂŠrgerligt, at hele dagen blev brugt pĂ„ at finde problemet, selvom det kunne lĂžses pĂ„ fem minutter.
PĂ„ den anden side:
â efter min hukommelse er dette en uforudset ting. Som jeg skrev tidligere â IX'erne faktisk har ikke noget som helst incitament til at filtrere transittrafik. De har som regel hundrede gigabit / terabit pr. sekund. Jeg kunne bare ikke i sidste ende tage sĂ„dan en antagelse alvorligt.
â en utrolig heldig sammentrĂŠf: nyt kompliceret udstyr, som man ikke har sĂŠrlig tillid til, og man ved ikke, hvad man kan forvente â skrĂŠddersyet netop til at blokere ressourcer, herunder TCP RST'er.
I Ăžjeblikket sĂžger NOC for denne internet exchange efter et problem. IfĂžlge dem (og jeg tror pĂ„ dem) har de ikke nogen specielt udrullet filtreringssystem. Men, tak gud, den videre quest â er ikke lĂŠngere vores problem đ
Det var et lille forsĂžg pĂ„ at retfĂŠrdiggĂžre os, vi beder om forstĂ„else og tilgivelse đ
P.S.: jeg nÊvner bevidst hverken producenter af DPI/NAT eller IX (jeg har i Þvrigt ikke sÊrlige klager til dem, det vigtigste er at forstÄ, hvad der skete)
Dagens (sÄvel som i gÄrs og forgÄrs) virkelighed set fra en internetudbyders perspektiv
De seneste uger har jeg brugt pÄ betydeligt at omstrukturere netvÊrkskernen, hvilket har medfÞrt mange 'live' manipulationer med risiko for at pÄvirke den aktive brugertrafik. Givet mÄlene, resultaterne og konsekvenserne af dette, er det moralsk set ret tungt. IsÊr nÄr man igen hÞrer de himmelrÄbende taler om at beskytte stabiliteten i runet, suverÊnitet, osv.
I dette afsnit vil jeg forsĂžge at fortĂŠlle om 'evolutionen' af netvĂŠrkskernen for en typisk internetudbyder i lĂžbet af det sidste Ă„rti.
For ti Ă„r siden.
I de velsignede tider kunne kerne-netvÊrket hos en udbyder vÊre simpel og pÄlidelig som en prop:
PĂ„ dette meget, meget forenklede billede mangler der motorveje, ringe, ip/mpls-routing.
Essensen er, at brugertrafikken i sidste ende kom ind i kernekontakten â derfra gik den til , hvor den som regel â gik tilbage til kernekontakten, og derefter 'ud' â gennem en eller flere border gateways til internettet.
En sÄdan ordning kan meget, meget nemt reserveres bÄde pÄ L3 (dynamisk routing) og pÄ L2 (MPLS).
Man kan sĂŠtte N+1 af hvad som helst: adgangsservere, switches, border routers â og pĂ„ den ene eller den anden mĂ„de reservere dem til automatisk failover.
Efter nogle Är blev alle i Rusland klar over, at det ikke kunne fortsÊtte sÄdan: det var nÞdvendigt hurtigt at beskytte bÞrnene mod netvÊrkets forpestende indflydelse.
Der opstod et presserende behov for hurtigt at finde mÄder at filtrere brugertrafik pÄ.
Her er der forskellige tilgange.
I ikke sÊrlig gode tilfÊlde bliver noget sat 'i skÊring': mellem brugertrafikken og internettet. Trafikken, der passerer gennem dette 'noget', undergÄr analyse, og for eksempel sendes der en falsk pakke med en omdirigering til abonnenten.
I et lidt bedre tilfĂŠlde - hvis trafikmĂŠngderne tillader det - kan man lave et lille trick: sende trafik fra brugerne til filtrering kun til de adresser, der skal filtreres (til dette kan man enten tage IP-adresserne angivet i registret, eller yderligere oplĂžse de domĂŠner, der findes i registret).
Engang skrev jeg en simpel â selvom man ikke rigtig fĂ„r sig selv til at kalde det sĂ„dan. Det er meget simpelt og ikke sĂŠrlig effektivt - men det har gjort det muligt for os og titals (hvis ikke hundreder) af andre udbydere at undgĂ„ at bruge millioner pĂ„ industrielle DPI-systemer med det samme, og har givet os et par ekstra Ă„r.
For at nÊvne noget om dengang og nuvÊrende DPIMange af dem, der kÞbte de eksisterende DPI-systemer pÄ markedet dengang - har allerede smidt dem vÊk. De er ikke lavet til noget sÄdant: hundrede tusinde adresser, titusinder af URL'er.
Og samtidig er der kommet meget lokale producenter frem pÄ dette marked. Jeg taler ikke om hardware - her er alle med pÄ, hvad der foregÄr, men softwaren - det primÊre, der findes i DPI - er muligvis, hvis ikke den mest avancerede i verden nu, sÄ i hvert fald a) udviklet i eksplosiv hastighed og b) prisen pÄ pakken - er simpelthen uforlignelig med udenlandske konkurrenter.
Man kunne vĂŠre stolt, men det er lidt trist =)
Nu sÄ det hele sÄdan ud:
Endnu to Är senere havde alle revisorer; ressourcerne i registret blev flere og flere. For noget gammelt udstyr (for eksempel Cisco 7600) blev det simpelthen umuligt at bruge ordningen med 'filtrering fra siden': antallet af ruter pÄ 76 platforme er begrÊnset til omkring ni hundrede tusinde, mens antallet af IPv4-ruter i dag nÊrmer sig 800 tusinde. Og hvis man ogsÄ tÊller ipv6... og hvor mange er der? 900000 separate adresser i RKN-forbud? =)
Nogle gik over til en ordning hvor hele trafikstrĂžmme blev spejlet til en filtreringsserver, som skulle analysere hele strĂžmmen og ved opdagelse af noget skidt sende RST til begge parter (afsender og modtager).
Men jo mere trafik, jo mindre anvendelig er denne ordning. Ved den mindste forsinkelse i behandlingen - flyver den spejlede trafik simpelthen uhindret vÊk, og udbyderen fÄr en bÞde.
Flere og flere udbydere er nÞdt til at installere DPI-systemer med forskellig pÄlidelighed i krydsfeltet af hovedledningerne.
For et til to Ă„r siden ifĂžlge rygterne, begyndte praktisk talt alle FSB at krĂŠve en reel installation af udstyr (tidligere kunne stĂžrstedelen af udbydere klare sig med godkendelse fra myndighederne SORM-planen â planen for operationelle foranstaltninger i tilfĂŠlde af, at man skal finde noget et sted)
Udover penge (ikke helt astronomiske, men stadig millioner), krĂŠvede SORM for mange endnu flere manipulationer med netvĂŠrket.
- SORM skal kunne se de 'grÄ' adresser fra brugerne, fÞr nat-transformationen
- SORM har et begrĂŠnset antal netvĂŠrksinterfaces
Derfor mĂ„tte vi blandt andet omstrukturere en del af kernen kraftigt â blot for at samle trafikken af brugerne til adgangsserverne Ă©t sted. For derefter at spejle det til SORM med flere links.
Det vil sige, meget forenklet, var (til venstre) vs blev (til hĂžjre):
Nu de fleste udbydere krĂŠver ogsĂ„ implementering af SORM-3 â som inkluderer, blandt andet, logfĂžring af nat-transformationer.
Til disse formĂ„l mĂ„tte vi i det ovenstĂ„ende diagram ogsĂ„ tilfĂžje separat udstyr til NAT (netop det, der blev nĂŠvnt i fĂžrste del). Og det skulle tilfĂžjes i en bestemt rĂŠkkefĂžlge: fordi SORM skal 'se' trafikken fĂžr adresserne bliver transformeret â sĂ„ trafikken skal gĂ„ strengt som fĂžlger: brugere -> kommutation, kerne -> adgangsservere -> SORM -> NAT -> kommutation, kerne -> internettet. For at gĂžre dette mĂ„tte vi bogstaveligt talt 'vende' trafikstrĂžmmene den anden vej i realtid, hvilket ogsĂ„ var ganske vanskeligt.
Sammenfattende: I lÞbet af et Ärti er kernen af den gennemsnitlige udbyder blevet vÊsentligt mere kompliceret, og antallet af yderligere fejlpunkter (bÄde i form af udstyr og i form af enhedskommunikationslinjer) er steget betydeligt. Faktisk implicerer kravet om at 'se alt' en samling af dette 'alt' pÄ ét sted.
Jeg mener, dette kan extrapoleres ret klart til de nuvĂŠrende initiativer for suverĂŠnitet af Runet, dets beskyttelse, stabilisering og forbedring đ
Og der er stadig Yarovaya forude.
Kilde: habr.com
