Tilskyndede mig til dette indlæg .
Jeg citerer det her:
i dag klokken 18:53
Jeg var tilfreds med udbyderen i dag. Sammen med opdateringen af webstedsblokeringssystemet blev hans mailer mail.ru forbudt. Jeg har ringet til teknisk support siden morgen, men de kan ikke gøre noget. Udbyderen er lille, og tilsyneladende blokerer højere rangerende udbydere den. Jeg bemærkede også en opbremsning i åbningen af alle websteder, måske installerede de en slags skæv DLP? Tidligere var der ingen problemer med adgangen. Ødelæggelsen af RuNet sker lige foran mine øjne...
Faktum er, at det ser ud til, at vi er den samme udbyder :)
Og sandelig, Jeg gættede næsten årsagen til problemerne med mail.ru (selvom vi nægtede at tro på sådan noget i lang tid).
Det følgende vil blive opdelt i to dele:
- årsagerne til vores nuværende problemer med mail.ru og den spændende søgen efter at finde dem
- eksistensen af ISP i nutidens realiteter, stabiliteten af det suveræne RuNet.
Tilgængelighedsproblemer med mail.ru
Åh, det er en ret lang historie.
Faktum er, at for at implementere statens krav (flere detaljer i anden del), købte, konfigurerede og installerede vi noget udstyr - både til filtrering af forbudte ressourcer og til implementering abonnenter.
For noget tid siden ombyggede vi endelig netværkskernen på en sådan måde, at al abonnenttrafik passerede gennem dette udstyr strengt taget i den rigtige retning.
For et par dage siden aktiverede vi forbudt filtrering på det (mens vi lod det gamle system fungere) - alt så ud til at gå godt.
Dernæst begyndte de gradvist at aktivere NAT på dette udstyr for forskellige dele af abonnenter. Ud fra dens udseende så alt også ud til at gå godt.
Men i dag, efter at have aktiveret NAT på udstyret for den næste del af abonnenter, stod vi fra morgenstunden over for et anstændigt antal klager over utilgængelighed eller delvis tilgængelighed og andre Mail Ru Group-ressourcer.
De begyndte at tjekke: noget et eller andet sted undertiden, en gang imellem sender som svar på anmodninger udelukkende til mail.ru-netværk. Desuden sender den en forkert genereret (uden ACK), naturligvis kunstig TCP RST. Sådan så det ud:
Naturligvis var de første tanker om det nye udstyr: frygtelig DPI, ingen tillid til det, man ved aldrig, hvad det kan gøre - trods alt er TCP RST en ret almindelig ting blandt blokeringsværktøjer.
Antagelse Vi fremsatte også ideen om, at nogen "overlegen" filtrerer, men kasserede den straks.
For det første har vi tilstrækkeligt fornuftige uplinks, så vi ikke behøver at lide sådan :)
For det andet er vi forbundet med flere i Moskva, og trafikken til mail.ru går igennem dem - og de har hverken ansvar eller noget andet motiv til at filtrere trafik.
Den næste halvdel af dagen blev brugt på det, man normalt kalder shamanisme - sammen med udstyrsleverandøren, som vi takker dem for, gav de ikke op :)
- filtrering var fuldstændig deaktiveret
- NAT blev deaktiveret ved hjælp af den nye ordning
- test-pc'en blev placeret i en separat isoleret pool
- IP-adressen er ændret
Om eftermiddagen blev en virtuel maskine tildelt, der var forbundet til netværket i henhold til skemaet for en almindelig bruger, og repræsentanter for sælgeren fik adgang til den og udstyret. Shamanismen fortsatte :)
Til sidst udtalte leverandørens repræsentant trygt, at hardwaren absolut intet havde med det at gøre: de første kommer fra et højere sted.
BemærkPå dette tidspunkt kan nogen sige: men det var meget nemmere at tage et dump ikke fra test-pc'en, men fra motorvejen over DPI?
Nej, desværre er det slet ikke trivielt at tage et dump (og endda bare spejle) 40+gbps.
Efter dette, om aftenen, var der ikke andet at gøre end at vende tilbage til antagelsen om mærkelig filtrering et sted ovenover.
Jeg kiggede igennem hvilken IX trafikken til MRG-netværkene nu passerer igennem og annullerede simpelthen bgp-sessionerne til den. Og - se og se! - alt vendte straks tilbage til det normale 🙁
På den ene side er det ærgerligt, at hele dagen gik med at lede efter problemet, selvom det blev løst på fem minutter.
På den anden side:
- i min hukommelse er dette en ting uden fortilfælde. Som jeg allerede skrev ovenfor - IX virkelig der er ingen mening i at filtrere transittrafik. De har normalt hundredvis af gigabit/terabit per sekund. Jeg kunne bare ikke seriøst forestille mig sådan noget før for nylig.
— et utroligt heldigt sammenfald af omstændigheder: en ny kompleks hardware, der ikke er særlig tillid til, og hvorfra det ikke er klart, hvad der kan forventes — skræddersyet specifikt til at blokere ressourcer, herunder TCP RST'er
NOC'en for denne internetudveksling leder i øjeblikket efter et problem. Ifølge dem (og jeg tror på dem), har de ikke noget specielt indsat filtreringssystem. Men gudskelov, den videre søgen er ikke længere vores problem :)
Dette var et lille forsøg på at retfærdiggøre mig selv, vær venlig at forstå og tilgive :)
PS: Jeg nævner bevidst ikke producenten af DPI/NAT eller IX (faktisk har jeg ikke engang nogen specielle klager over dem, det vigtigste er at forstå, hvad det var)
Dagens (såvel som gårsdagens og i forgårs) virkelighed set fra en internetudbyders synspunkt
Jeg har brugt de sidste uger på at genopbygge kernen af netværket markant, udført en masse manipulationer "for profit", med risiko for at påvirke live brugertrafik markant. I betragtning af målene, resultaterne og konsekvenserne af alt dette, er det moralsk set ret svært. Især - endnu en gang at lytte til smukke taler om at beskytte Runets stabilitet, suverænitet mv. og så videre.
I dette afsnit vil jeg forsøge at beskrive "udviklingen" af netværkskernen hos en typisk internetudbyder i løbet af de sidste ti år.
Ti år siden.
I disse velsignede tider kunne kernen i et udbydernetværk være lige så enkel og pålidelig som en trafikprop:
I dette meget, meget forenklede billede er der ingen trunks, ringe, ip/mpls-routing.
Dens essens er, at brugertrafik i sidste ende kom til at skifte kerneniveau - hvorfra den gik til , hvorfra, som regel, tilbage til kerneomskiftningen og derefter "ud" - gennem en eller flere grænsegateways til internettet.
En sådan ordning er meget, meget nem at reservere både på L3 (dynamisk routing) og på L2 (MPLS).
Du kan installere N+1 af hvad som helst: få adgang til servere, switche, grænser - og på en eller anden måde reservere dem til automatisk failover.
Efter få år Det blev klart for alle i Rusland, at det var umuligt at leve sådan længere: det hastede med at beskytte børn mod internettets ødelæggende indflydelse.
Der var et presserende behov for at finde måder at filtrere brugertrafik på.
Der er forskellige tilgange her.
I et ikke særlig godt tilfælde sættes noget "i gabet": mellem brugertrafik og internettet. Trafikken, der passerer gennem dette "noget", analyseres, og for eksempel sendes en falsk pakke med en omdirigering mod abonnenten.
I et lidt bedre tilfælde - hvis trafikmængden tillader det - kan du lave et lille trick med ørerne: send til filtrering kun trafik, der kun stammer fra brugere til de adresser, der skal filtreres (for at gøre dette kan du enten tage IP-adresserne angivet der fra registreringsdatabasen, eller yderligere løse eksisterende domæner i registreringsdatabasen).
På et tidspunkt, til disse formål, skrev jeg en enkel - selvom jeg ikke engang tør kalde ham det. Det er meget simpelt og ikke særlig produktivt - dog gav det os og snesevis (hvis ikke hundredvis) af andre udbydere mulighed for ikke straks at udskyde millioner på industrielle DPI-systemer, men det gav flere års tid.
I øvrigt om det daværende og nuværende DPIMange, der købte de DPI-systemer, der var på markedet på det tidspunkt, havde i øvrigt allerede smidt dem ud. Nå, de er ikke designet til dette: hundredtusindvis af adresser, titusindvis af webadresser.
Og samtidig er indenlandske producenter steget meget stærkt til dette marked. Jeg taler ikke om hardwarekomponenten - alt er klart for alle her, men software - det vigtigste, som DPI har - er måske i dag, hvis ikke det mest avancerede i verden, så helt sikkert a) udvikles med stormskridt, og b) til prisen for et produkt i æske - simpelthen uforlignelig med udenlandske konkurrenter.
Jeg vil gerne være stolt, men lidt trist =)
Nu så alt sådan her ud:
Om et par år mere alle havde allerede revisorer; Der var flere og flere ressourcer i registret. For noget ældre udstyr (for eksempel Cisco 7600) blev "sidefiltreringsordningen" simpelthen uanvendelig: antallet af ruter på 76 platforme er begrænset til noget i retning af ni hundrede tusinde, mens antallet af IPv4-ruter alene i dag nærmer sig 800 tusind. Og hvis det også er ipv6... Og også... hvor meget er der? 900000 individuelle adresser i RKN-forbuddet? =)
Nogen skiftede til et skema med spejling af al backbone-trafik til en filtreringsserver, som skulle analysere hele flowet og, hvis noget dårligt bliver fundet, sende RST i begge retninger (afsender og modtager).
Men jo mere trafik, jo mindre anvendelig er denne ordning. Hvis der er den mindste forsinkelse i behandlingen, vil den spejlede trafik simpelthen flyve ubemærket forbi, og udbyderen vil modtage en bøderapport.
Flere og flere udbydere er tvunget til at installere DPI-systemer af varierende grad af pålidelighed på tværs af motorveje.
Et år eller to siden ifølge rygter begyndte næsten alle FSB at kræve den faktiske installation af udstyr (tidligere klarede de fleste udbydere sig med godkendelse fra myndighederne SORM plan - en plan for operationelle foranstaltninger i tilfælde af behov for at finde noget et sted)
Ud over penge (ikke ligefrem ublu, men stadig millioner), krævede SORM mange flere manipulationer med netværket.
- SORM skal se "grå" brugeradresser før nat-oversættelse
- SORM har et begrænset antal netværksgrænseflader
Derfor var vi især nødt til i høj grad at genopbygge et stykke af kernen - simpelthen for at samle brugertrafik til adgangsserverne et sted ét sted. For at spejle det i SORM med flere links.
Det vil sige meget forenklet, det var (venstre) vs blev (højre):
Nu De fleste udbydere kræver desuden implementering af SORM-3 – som blandt andet omfatter logning af nat-udsendelser.
Til disse formål var vi også nødt til at tilføje separat udstyr til NAT til diagrammet ovenfor (præcis hvad der er diskuteret i første del). Tilføj desuden i en bestemt rækkefølge: da SORM skal "se" trafikken før oversættelse af adresser, skal trafikken foregå strengt som følger: brugere -> switching, kernel -> adgangsservere -> SORM -> NAT -> switching, kernel - > internettet. For at gøre dette måtte vi bogstaveligt talt "vende" trafikstrømmene i den anden retning for at tjene penge, hvilket også var ret svært.
Sammenfattende: I løbet af de sidste ti år er kernedesignet hos en gennemsnitlig udbyder blevet mange gange mere komplekst, og yderligere fejlpunkter (både i form af udstyr og i form af enkelte koblingslinjer) er steget markant. Faktisk indebærer selve kravet om at "se alt" at reducere dette "alt" til et punkt.
Jeg tror, at dette ganske transparent kan ekstrapoleres til nuværende initiativer for at suverænisere Runet, beskytte det, stabilisere det og forbedre det :)
Og Yarovaya er stadig foran.
Kilde: www.habr.com