Tilskyndet meg til dette innlegget .
Jeg siterer det her:
i dag kl 18:53
Jeg var fornøyd med leverandøren i dag. Sammen med oppdateringen av systemet for blokkering av nettsteder ble maileren mail.ru forbudt. Jeg har ringt teknisk støtte siden morgenen, men de kan ikke gjøre noe. Leverandøren er liten, og tilsynelatende høyere rangerte tilbydere blokkerer den. Jeg la også merke til en nedgang i åpningen av alle nettsteder, kanskje de installerte en slags skjev DLP? Tidligere var det ingen problemer med tilgang. Ødeleggelsen av RuNet skjer rett foran øynene mine...
Faktum er at det ser ut til at vi er den samme leverandøren :)
Og sannelig, Jeg gjettet nesten årsaken til problemene med mail.ru (selv om vi nektet å tro på noe slikt i lang tid).
Det som følger er delt i to deler:
- årsakene til våre nåværende problemer med mail.ru og den spennende søken etter å finne dem
- eksistensen av ISP i dagens realiteter, stabiliteten til det suverene RuNet.
Tilgjengelighetsproblemer med mail.ru
Å, det er en ganske lang historie.
Faktum er at for å implementere statens krav (mer detaljer i andre del), kjøpte, konfigurerte og installerte vi noe utstyr - både for å filtrere forbudte ressurser og for å implementere abonnenter.
For en tid siden bygde vi endelig om nettverkskjernen på en slik måte at all abonnenttrafikk gikk gjennom dette utstyret strengt tatt i riktig retning.
For noen dager siden slo vi på forbudt filtrering på det (mens vi lot det gamle systemet fungere) - alt så ut til å gå bra.
Deretter begynte de gradvis å aktivere NAT på dette utstyret for forskjellige deler av abonnenter. Sett ifra så alt også ut til å gå bra.
Men i dag, etter å ha aktivert NAT på utstyret for neste del av abonnenter, ble vi allerede fra morgenstunden møtt med et anstendig antall klager om utilgjengelighet eller delvis tilgjengelighet og andre Mail Ru Group-ressurser.
De begynte å sjekke: noe et sted noen ganger, av og til sender som svar på forespørsler utelukkende til mail.ru-nettverk. Dessuten sender den en feil generert (uten ACK), åpenbart kunstig TCP RST. Slik så det ut:
Naturligvis var de første tankene om det nye utstyret: forferdelig DPI, ingen tillit til det, du vet aldri hva det kan gjøre - tross alt er TCP RST en ganske vanlig ting blant blokkeringsverktøy.
Antagelse Vi fremmet også ideen om at noen "overordnet" filtrerer, men forkastet den umiddelbart.
For det første har vi tilstrekkelig fornuftige oppkoblinger til at vi ikke trenger å lide slik :)
For det andre er vi knyttet til flere i Moskva, og trafikk til mail.ru går gjennom dem - og de har verken ansvar eller noe annet motiv for å filtrere trafikk.
Den neste halvdelen av dagen ble brukt på det som vanligvis kalles sjamanisme - sammen med utstyrsleverandøren, som vi takker dem for, ga de ikke opp :)
- filtrering ble fullstendig deaktivert
- NAT ble deaktivert ved å bruke den nye ordningen
- test-PC-en ble plassert i et separat isolert basseng
- IP-adressering endret
På ettermiddagen ble det tildelt en virtuell maskin som koblet til nettverket i henhold til ordningen til en vanlig bruker, og representanter for leverandøren fikk tilgang til den og utstyret. Sjamanismen fortsatte :)
Til slutt uttalte leverandørens representant trygt at maskinvaren absolutt ikke hadde noe med det å gjøre: de første kommer fra et høyere sted.
NotePå dette tidspunktet kan noen si: men det var mye lettere å ta en dump ikke fra test-PC-en, men fra motorveien over DPI?
Nei, dessverre, å ta en dump (og til og med bare speile) 40+gbps er slett ikke trivielt.
Etter dette, på kvelden, var det ikke annet å gjøre enn å gå tilbake til antagelsen om merkelig filtrering et sted ovenfor.
Jeg så gjennom hvilken IX trafikken til MRG-nettverkene nå går gjennom og avbrøt ganske enkelt bgp-øktene til den. Og - se og se! - alt gikk umiddelbart tilbake til det normale 🙁
På den ene siden er det synd at hele dagen ble brukt på å lete etter problemet, selv om det ble løst på fem minutter.
På den annen side:
– I mitt minne er dette en ting uten sidestykke. Som jeg allerede skrev ovenfor - IX virkelig det er ingen vits i å filtrere transittrafikk. De har vanligvis hundrevis av gigabit/terabit per sekund. Jeg kunne bare ikke seriøst forestille meg noe slikt før nylig.
– et utrolig heldig sammentreff av omstendigheter: en ny kompleks maskinvare som ikke er spesielt pålitelig og som det ikke er klart hva som kan forventes – skreddersydd spesielt for blokkering av ressurser, inkludert TCP RST-er
NOC-en til denne internettsentralen ser for øyeblikket etter et problem. Ifølge dem (og jeg tror dem), har de ikke noe spesielt utplassert filtreringssystem. Men gudskjelov, den videre søken er ikke lenger vårt problem :)
Dette var et lite forsøk på å rettferdiggjøre meg selv, vær så snill å forstå og tilgi :)
PS: Jeg navngir bevisst ikke produsenten av DPI/NAT eller IX (faktisk har jeg ikke engang noen spesielle klager på dem, det viktigste er å forstå hva det var)
Dagens (så vel som gårsdagens og i forgårs) virkelighet fra en internettleverandørs synspunkt
Jeg har brukt de siste ukene betydelig på å gjenoppbygge kjernen av nettverket, utført en haug med manipulasjoner "for profitt", med risiko for å påvirke live brukertrafikk betydelig. Med tanke på målene, resultatene og konsekvensene av alt dette, er det moralsk sett ganske vanskelig. Spesielt - nok en gang å lytte til vakre taler om å beskytte stabiliteten til Runet, suverenitet, etc. og så videre.
I denne delen vil jeg prøve å beskrive «utviklingen» av nettverkskjernen til en typisk ISP de siste ti årene.
Ti år siden.
I disse velsignede tider kan kjernen i et leverandørnettverk være like enkelt og pålitelig som en trafikkork:
I dette veldig, veldig forenklede bildet er det ingen trunker, ringer, ip/mpls-ruting.
Essensen er at brukertrafikken til slutt kom til vekslingen av kjernenivå - fra der den gikk til , hvorfra, som regel, tilbake til kjernebytte, og deretter "ut" - gjennom en eller flere grenseporter til Internett.
Et slikt opplegg er veldig, veldig enkelt å reservere både på L3 (dynamisk ruting) og på L2 (MPLS).
Du kan installere N+1 av hva som helst: tilgang til servere, brytere, grenser - og på en eller annen måte reservere dem for automatisk failover.
Etter noen år Det ble klart for alle i Russland at det var umulig å leve slik lenger: det hastet å beskytte barn mot den ødeleggende påvirkningen fra Internett.
Det var et presserende behov for å finne måter å filtrere brukertrafikk på.
Det er forskjellige tilnærminger her.
I et lite godt tilfelle er noe satt "i gapet": mellom brukertrafikk og Internett. Trafikken som går gjennom dette "noe" blir analysert, og for eksempel sendes en falsk pakke med omdirigering mot abonnenten.
I et litt bedre tilfelle - hvis trafikkvolumet tillater det - kan du gjøre et lite triks med ørene: send for filtrering kun trafikk som stammer fra brukere kun til de adressene som må filtreres (for å gjøre dette kan du enten ta IP-adressene spesifisert der fra registret, eller i tillegg løse eksisterende domener i registret).
På en gang, for disse formålene, skrev jeg en enkel - selv om jeg ikke engang tør kalle ham det. Det er veldig enkelt og lite produktivt - men det tillot oss og dusinvis (om ikke hundrevis) av andre leverandører umiddelbart å betale ut millioner på industrielle DPI-systemer, men det ga flere år til.
Forresten, om daværende og nåværende DPIForresten, mange som kjøpte DPI-systemene som var tilgjengelig på markedet på den tiden, hadde allerede kastet dem. Vel, de er ikke laget for dette: hundretusenvis av adresser, titusenvis av nettadresser.
Og samtidig har innenlandske produsenter steget veldig sterkt til dette markedet. Jeg snakker ikke om maskinvarekomponenten - alt er klart for alle her, men programvare - det viktigste som DPI har - er kanskje i dag, om ikke den mest avanserte i verden, så absolutt a) utvikles med stormskritt, og b) til prisen for et produkt i eske – rett og slett uforlignelig med utenlandske konkurrenter.
Jeg vil gjerne være stolt, men litt trist =)
Nå så alt slik ut:
Om et par år til alle hadde allerede revisorer; Det ble stadig flere ressurser i registeret. For noe eldre utstyr (for eksempel Cisco 7600) ble "sidefiltrering"-ordningen rett og slett ubrukelig: antall ruter på 76 plattformer er begrenset til noe sånt som ni hundre tusen, mens antallet IPv4-ruter alene i dag nærmer seg 800 tusen. Og hvis det også er ipv6 ... Og også ... hvor mye er det? 900000 enkeltadresser i RKN-forbudet? =)
Noen har byttet til et opplegg med speiling av all ryggradstrafikk til en filtreringsserver, som skal analysere hele flyten og, hvis noe dårlig blir funnet, sende RST i begge retninger (avsender og mottaker).
Men jo mer trafikk, jo mindre anvendelig er denne ordningen. Hvis det er den minste forsinkelse i behandlingen, vil den speilede trafikken ganske enkelt fly ubemerket forbi, og leverandøren vil motta en bøterapport.
Flere og flere leverandører blir tvunget til å installere DPI-systemer med ulik grad av pålitelighet på tvers av motorveier.
For et år eller to siden ifølge rykter begynte nesten alle FSB å kreve selve installasjonen av utstyr (tidligere klarte de fleste tilbydere med godkjenning fra myndighetene SORM-plan - en plan for operasjonelle tiltak i tilfelle behov for å finne noe et sted)
I tillegg til penger (ikke akkurat ublu, men fortsatt millioner), krevde SORM mange flere manipulasjoner med nettverket.
- SORM må se "grå" brukeradresser før nat-oversettelse
- SORM har et begrenset antall nettverksgrensesnitt
Derfor måtte vi spesielt bygge om en del av kjernen - ganske enkelt for å samle brukertrafikk til tilgangsserverne et sted på ett sted. For å speile det i SORM med flere lenker.
Det vil si, veldig forenklet, det var (venstre) vs ble (høyre):
Nå De fleste tilbydere krever også implementering av SORM-3 – som inkluderer blant annet logging av nat-sendinger.
For disse formålene måtte vi også legge til eget utstyr for NAT i diagrammet ovenfor (nøyaktig det som er omtalt i første del). Dessuten, legg til i en bestemt rekkefølge: siden SORM må "se" trafikken før du oversetter adresser, må trafikken gå strengt tatt som følger: brukere -> bytter, kjerne -> tilgangsservere -> SORM -> NAT -> bytter, kjerne - > Internett. For å gjøre dette måtte vi bokstavelig talt "snu" trafikkstrømmene i den andre retningen for profitt, noe som også var ganske vanskelig.
Oppsummert: i løpet av de siste ti årene har kjernedesignen til en gjennomsnittlig leverandør blitt mange ganger mer kompleks, og flere feilpunkter (både i form av utstyr og i form av enkeltsvitsjelinjer) har økt betydelig. Faktisk innebærer selve kravet om å "se alt" å redusere dette "alt" til ett punkt.
Jeg tror dette kan ekstrapoleres ganske transparent til nåværende initiativer for å suverenisere Runet, beskytte det, stabilisere det og forbedre det :)
Og Yarovaya er fortsatt foran.
Kilde: www.habr.com