Föranledde mig till detta inlägg .
Jag citerar det här:
idag kl 18:53
Jag var nöjd med leverantören idag. Tillsammans med uppdateringen av webbplatsblockeringssystemet förbjöds hans mailer mail.ru. Jag har ringt teknisk support sedan morgonen, men de kan inte göra någonting. Leverantören är liten, och uppenbarligen blockerar högre rankade leverantörer den. Jag märkte också en avmattning i öppningen av alla sajter, kanske de installerade någon form av sned DLP? Tidigare var det inga problem med åtkomsten. Förstörelsen av RuNet sker mitt framför mina ögon...
Faktum är att det verkar som att vi är samma leverantör :)
Och verkligen, Jag gissade nästan orsaken till problemen med mail.ru (även om vi vägrade att tro på en sådan sak under lång tid).
Det som följer kommer att delas upp i två delar:
- orsakerna till våra nuvarande problem med mail.ru och den spännande jakten på att hitta dem
- existensen av ISP i dagens verklighet, stabiliteten hos det suveräna RuNet.
Tillgänglighetsproblem med mail.ru
Åh, det är en ganska lång historia.
Faktum är att för att implementera statens krav (mer information i den andra delen) köpte, konfigurerade och installerade vi viss utrustning - både för att filtrera förbjudna resurser och för att implementera abonnenter.
För en tid sedan byggde vi äntligen om nätverkskärnan på ett sådant sätt att all abonnenttrafik passerade genom denna utrustning strikt i rätt riktning.
För några dagar sedan slog vi på förbjuden filtrering på det (medan vi lät det gamla systemet fungera) - allt verkade gå bra.
Därefter började de gradvis aktivera NAT på denna utrustning för olika delar av abonnenter. Från utseendet verkade allt också gå bra.
Men idag, efter att ha aktiverat NAT på utrustningen för nästa del av prenumeranterna, stod vi redan på morgonen inför ett anständigt antal klagomål om bristande tillgänglighet eller partiell tillgänglighet och andra Mail Ru Group-resurser.
De började kolla: något någonstans ibland, ibland skickar som svar på förfrågningar uteslutande till mail.ru-nätverk. Dessutom skickar den en felaktigt genererad (utan ACK), uppenbarligen artificiell TCP RST. Så här såg det ut:
Naturligtvis var de första tankarna om den nya utrustningen: fruktansvärd DPI, ingen tillit till den, man vet aldrig vad den kan göra - trots allt är TCP RST en ganska vanlig sak bland blockeringsverktyg.
Antagande Vi lade också fram idén att någon "överlägsen" filtrerar, men kasserade den omedelbart.
För det första har vi tillräckligt sunda upplänkar så att vi inte behöver lida så här :)
För det andra är vi anslutna till flera i Moskva, och trafik till mail.ru går genom dem - och de har varken ansvar eller något annat motiv att filtrera trafik.
Nästa halva dagen ägnades åt det som brukar kallas shamanism - tillsammans med utrustningsförsäljaren, som vi tackar dem för, gav de inte upp :)
- filtrering var helt inaktiverad
- NAT inaktiverades med det nya schemat
- testdatorn placerades i en separat isolerad pool
- IP-adressen har ändrats
På eftermiddagen tilldelades en virtuell maskin som var ansluten till nätverket enligt schemat för en vanlig användare, och representanter för säljaren fick tillgång till den och utrustningen. Shamanismen fortsatte :)
Till slut sa säljarens representant med tillförsikt att hårdvaran absolut inte hade något med det att göra: de första kommer från någonstans högre.
NoteraVid det här laget kan någon säga: men det var mycket lättare att ta en dumpning inte från testdatorn, utan från motorvägen ovanför DPI?
Nej, tyvärr, att ta en dump (och till och med bara spegla) 40+gbps är inte alls trivialt.
Efter detta, på kvällen, fanns det inget annat att göra än att återgå till antagandet om märklig filtrering någonstans ovanför.
Jag tittade igenom vilken IX trafiken till MRG-nätverken nu passerar och avbröt helt enkelt bgp-sessionerna till den. Och - se och se! - allt återgick direkt till det normala 🙁
Å ena sidan är det synd att hela dagen ägnades åt att leta efter problemet, även om det löstes på fem minuter.
Å andra sidan:
– I mitt minne är detta en sak utan motstycke. Som jag redan skrev ovan - IX verkligen det är ingen idé att filtrera transittrafiken. De har vanligtvis hundratals gigabit/terabit per sekund. Jag kunde bara inte på allvar föreställa mig något sådant förrän nyligen.
— ett otroligt lyckligt sammanträffande av omständigheter: en ny komplex hårdvara som inte är särskilt pålitlig och från vilken det inte är klart vad som kan förväntas — skräddarsydd specifikt för att blockera resurser, inklusive TCP RST:er
NOC för denna internetväxel letar för närvarande efter ett problem. Enligt dem (och jag tror dem) har de inget speciellt utplacerat filtreringssystem. Men gudskelov, det vidare sökandet är inte längre vårt problem :)
Detta var ett litet försök att rättfärdiga mig själv, snälla förstå och förlåt :)
PS: Jag nämner medvetet inte tillverkaren av DPI/NAT eller IX (i själva verket har jag inte ens några speciella klagomål om dem, det viktigaste är att förstå vad det var)
Dagens (liksom gårdagens och i förrgårs) verklighet från en internetleverantörs synvinkel
Jag har ägnat de senaste veckorna åt att avsevärt bygga om nätverkets kärna, utföra ett gäng manipulationer "för vinst", med risk för att avsevärt påverka live användartrafik. Med tanke på målen, resultaten och konsekvenserna av allt detta är det moraliskt sett ganska svårt. Speciellt - återigen lyssna på vackra tal om att skydda Runets stabilitet, suveränitet, etc. och så vidare.
I det här avsnittet kommer jag att försöka beskriva "utvecklingen" av nätverkskärnan hos en typisk ISP under de senaste tio åren.
Tio år sedan.
I dessa välsignade tider kan kärnan i ett leverantörsnätverk vara lika enkel och pålitlig som en trafikstockning:
I denna mycket, mycket förenklade bild, finns det inga trunkar, ringar, ip/mpls-routing.
Dess essens är att användartrafiken i slutändan kom till växling av kärnnivå - varifrån den gick till , varifrån, som regel, tillbaka till kärnväxlingen och sedan "ut" - genom en eller flera gränsportar till Internet.
Ett sådant schema är väldigt, väldigt enkelt att reservera både på L3 (dynamisk routing) och på L2 (MPLS).
Du kan installera N+1 av vad som helst: åtkomst till servrar, switchar, gränser – och på ett eller annat sätt reservera dem för automatisk failover.
Efter några år Det blev klart för alla i Ryssland att det var omöjligt att leva så här längre: det var brådskande att skydda barn från Internets skadliga inflytande.
Det fanns ett akut behov av att hitta sätt att filtrera användartrafik.
Det finns olika tillvägagångssätt här.
I ett inte särskilt bra fall sätts något "i gapet": mellan användartrafik och internet. Trafiken som passerar genom detta "något" analyseras och till exempel skickas ett falskt paket med en omdirigering mot abonnenten.
I ett lite bättre fall - om trafikvolymerna tillåter - kan du göra ett litet knep med öronen: skicka för filtrering endast trafik som kommer från användare endast till de adresser som behöver filtreras (för att göra detta kan du antingen ta IP-adresserna som anges där från registret, eller löser dessutom befintliga domäner i registret).
En gång, för dessa syften, skrev jag en enkel – även om jag inte ens vågar kalla honom så. Det är väldigt enkelt och inte särskilt produktivt – men det gjorde det möjligt för oss och dussintals (om inte hundratals) andra leverantörer att omedelbart lägga ut miljoner på industriella DPI-system, men det gav flera ytterligare år.
Förresten, om dåvarande och nuvarande DPIFörresten, många som köpte DPI-systemen som fanns på marknaden vid den tiden hade redan kastat dem. Tja, de är inte designade för detta: hundratusentals adresser, tiotusentals webbadresser.
Och samtidigt har inhemska producenter tagit sig mycket starkt till denna marknad. Jag pratar inte om hårdvarukomponenten - allt är klart för alla här, men mjukvara - det viktigaste som DPI har - är kanske idag, om inte den mest avancerade i världen, så säkerligen a) utvecklas med stormsteg, och b) till priset av en förpackad produkt - helt enkelt ojämförlig med utländska konkurrenter.
Jag skulle vilja vara stolt, men lite ledsen =)
Nu såg allt ut så här:
Om ett par år till alla hade redan revisorer; Det fanns fler och fler resurser i registret. För en del äldre utrustning (till exempel Cisco 7600) blev systemet med "sidofiltrering" helt enkelt otillämpligt: antalet rutter på 76 plattformar är begränsat till ungefär niohundratusen, medan antalet IPv4-rutter enbart idag närmar sig 800 tusen. Och om det också är ipv6... Och dessutom... hur mycket är det? 900000 XNUMX enskilda adresser i RKN-förbudet? =)
Någon bytte till ett schema med spegling av all stamnätstrafik till en filtreringsserver, som ska analysera hela flödet och, om något dåligt hittas, skicka RST åt båda håll (avsändare och mottagare).
Men ju mer trafik, desto mindre tillämpligt är detta system. Om det finns den minsta fördröjning i bearbetningen kommer den speglade trafiken helt enkelt att flyga förbi obemärkt och leverantören kommer att få en böterrapport.
Fler och fler leverantörer tvingas installera DPI-system med varierande grad av tillförlitlighet över motorvägar.
Ett eller två år sedan enligt rykten började nästan alla FSB kräva själva installationen av utrustning (Tidigare skötte de flesta leverantörer med godkännande från myndigheterna SORM plan - en plan för operativa åtgärder vid behov av att hitta något någonstans)
Förutom pengar (inte direkt orimliga, men fortfarande miljoner) krävde SORM många fler manipulationer med nätverket.
- SORM behöver se "grå" användaradresser innan nat översättning
- SORM har ett begränsat antal nätverksgränssnitt
Därför var vi särskilt tvungna att bygga om en del av kärnan - helt enkelt för att samla användartrafik till åtkomstservrarna någonstans på ett ställe. För att spegla det i SORM med flera länkar.
Det vill säga mycket förenklat var det (vänster) vs blev (höger):
Nu De flesta leverantörer kräver också implementering av SORM-3 – som bland annat inkluderar loggning av nat-sändningar.
För dessa ändamål var vi också tvungna att lägga till separat utrustning för NAT till diagrammet ovan (exakt vad som diskuteras i den första delen). Dessutom, lägg till i en viss ordning: eftersom SORM måste "se" trafiken innan översättning av adresser, måste trafiken gå strikt enligt följande: användare -> switching, kernel -> access servers -> SORM -> NAT -> switching, kernel - > Internet. För att göra detta var vi tvungna att bokstavligen "vända" trafikflödena åt andra hållet för vinst, vilket också var ganska svårt.
Sammanfattningsvis: under de senaste tio åren har kärndesignen hos en genomsnittlig leverantör blivit många gånger mer komplex, och ytterligare felpunkter (både i form av utrustning och i form av enstaka kopplingslinjer) har ökat avsevärt. Egentligen innebär själva kravet att "se allt" att reducera detta "allt" till en punkt.
Jag tror att detta kan extrapoleras ganska transparent till nuvarande initiativ för att suveränisera Runet, skydda den, stabilisera den och förbättra den :)
Och Yarovaya ligger fortfarande före.
Källa: will.com