Ett utförligt svar på kommentaren, samt lite om livet för leverantörer i Ryssland.

Inspiration for this post this comment.

I'm sharing it here:

kaleman today at 18:53

Today I was pleased by the provider. Along with the update of the website blocking system, they accidentally blocked the mail.ru email service. I've been contacting tech support since morning, but they can't do anything. The provider is small, and they probably get blocked by higher-tier providers. I've also noticed a slowdown in opening all websites; perhaps they’ve implemented some faulty DLP? There were no access issues before. The destruction of the RuNet is happening right before my eyes...

The thing is, it seems we are that very provider 🙁

And indeed, kaleman I almost guessed the reason for the problems with mail.ru (although we long refused to believe it).

The continuation will be divided into two parts:

1. the reasons for our current problems with mail.ru and an exciting quest to find them
2. the existence of ISPs in today's realities, the stability of a sovereign RuNet.

Problems with the availability of mail.ru

Oh, it's quite a long story.

The thing is, to comply with government requirements (more details in the second part), we acquired, configured, and installed some equipment — both for filtering prohibited resources and for executing NAT translations of subscribers.

Some time ago, we finally restructured the network core so that all subscriber traffic would strictly pass through this equipment in the required direction.

A few days ago, we turned on filtering for prohibited content on it (while keeping the old system operational) — everything seemed to go well.

Next, we gradually started enabling NAT for different parts of subscribers on this equipment. It also seemed to go fine.

But today, after enabling NAT for another group of subscribers — since this morning, we faced quite a number of complaints about the unavailability or partial availability of mail.ru and other resources of Mail Ru Group.

We started checking: something somewhere sometimes, occasionally was sending TCP RST in response to requests exclusively to the mail.ru networks. Moreover — it's sending incorrectly generated (without ACK), clearly artificial TCP RST. It looked something like this:

Naturally, the first thoughts were about the new equipment: scary DPI, no trust in it, who knows what it might do — after all, TCP RST is quite a common occurrence among blocking tools.

Antagande kaleman om att någon "överordnad" filtrerar, har vi också framfört — men vi avvisade det omedelbart.

För det första har vi tillräckligt bra uplinkar för att inte behöva drabbas av sådant 🙂

För det andra är vi anslutna till flera IX i Moskva, och trafiken till mail.ru går just genom dem — och de har varken några skyldigheter eller motivation att filtrera trafik.

Den nästa halvan av dagen spenderades på det som vanligtvis kallas schamanism — tillsammans med utrustningsleverantören, vilket jag tackar dem för, gav vi oss inte 🙂

• filtreringen stängdes helt av
• NAT stängdes av enligt en ny plan
• test-PC:n placerades i en separat isolerad pool
• IP-adresseringen ändrades

Under andra halvan av dagen tilldelades en virtuell maskin som gick ut på nätverket som en vanlig användare, och både den och utrustningen fick tillgång till representanter för leverantören. Schamanismen fortsatte 🙂

Till slut förklarade representanten för leverantören med självsäkerhet att hårdvaran inte alls var involverad: rst:erna kommer från någonstans högre upp.

AnmärkningHär kan någon påstå: men det hade ju varit mycket enklare att ta en dump inte från test-PC:n, utan från huvudledningen ovanför DPI?

Nej, tyvärr är det långt ifrån enkelt att ta en dump (och även bara spegla) 40+gbps.

Efter detta, redan på kvällen — fanns det inget annat att göra än att återgå till antagandet om konstig filtrering någonstans högre upp.

Jag kollade vilket IX trafiken till MRG-näten nu går genom och stängde helt enkelt BGP-sessionerna till det. Och — åh underverk! — allt normaliserades omedelbart 🙁

Å ena sidan — det är verkligen tråkigt att hela dagen gick till att hitta problemet, även om det löstes på fem minuter.

Å andra sidan:

— enligt min åsikt är detta en utan motstycke händelse. Som jag redan skrev tidigare — IX:er verkligen har ingen anledning att filtrera överföringstrafik. De har vanligtvis hundratals gigabit / terabit per sekund. Jag kunde helt enkelt inte seriöst föreställa mig något sådant fram till sista stund.

— en otroligt lycklig slump: ny komplicerad hårdvara, som inte har något särskilt förtroende, och som det är oklart vad man kan förvänta sig av — precis framställd för att blockera resurser, däribland TCP RST:er

För närvarande söker NOC för den här internetutbytet ett problem. Enligt deras påstående (och jag tror dem) har de ingen speciellt avsedd filtreringssystem. Men tack vare himlen är det kommande kvestet — inte längre vårt problem 🙂

Det var ett litet försök att förklara, vi ber om förståelse och förlåtelse 🙂

P.S.: Jag nämner medvetet varken tillverkaren av DPI/NAT eller IX (jag har faktiskt inte heller några speciella klagomål mot dem, det viktiga är att förstå vad som hände)

Dagens (liksom gårdagens och föregårdagens) verklighet ur en internetleverantörs perspektiv

De senaste veckorna har jag tillbringat med att omstrukturera nätverkets kärna, utfört en massa 'live' manipulationer, med risken att påverka den levande användartrafiken. Med tanke på målen, resultaten och konsekvenserna av allt detta — är det känslomässigt ganska tungt. Särskilt när man än en gång lyssnar på de vackra tal om att skydda stabiliteten i det ryska nätet, suveränitet, etc.

I detta avsnitt försöker jag berätta om 'evolutionen' av nätverkskärnan hos en typisk internetleverantör under det senaste decenniet.

För ett decennium sedan.

I de välsignade tiderna kunde kärnan i en leverantörsnät vara enkel och pålitlig som en kork:

I denna mycket, mycket förenklade bild saknas motorvägar, ringar, ip/MPLS-ruttning.

Dess kärna är att användartrafiken till slut kom till kärnnivåns switchning — därifrån gick den till BNG, där den vanligtvis — gick tillbaka till kärnswitchningen, och vidare 'ut' — genom en eller flera border gateways till internet.

En sådan lösning är mycket, mycket lätt att reservkoppla både på L3 (dynamisk routing) och på L2 (MPLS).

Man kan sätta upp N+1 av vad som helst: åtkomstservrar, switchar, border gateways — och på ett eller annat sätt reservkoppla dem för automatisk övergång.

Efter några år blev det klart för alla i Ryssland att man inte kunde fortsätta så här: det var nödvändigt att snabbt skydda barnen från det fördärvande inflytandet från nätet.

Det uppstod ett behov av att snabbt hitta sätt att filtrera användartrafik.

Här finns det olika tillvägagångssätt.

I ett inte så bra fall sätts något 'i skärning': mellan användartrafiken och internet. Trafiken som passerar genom detta 'något' analyseras och, till exempel, skickas en falsk paket med en omdirigering till abonnenten.

I det lite bättre fallet — om trafikvolymerna tillåter — kan man göra en liten trick: skicka filter endast på den trafik som går ut till användarna till de adresser som behöver filtreras (för detta kan man antingen ta de angivna IP-adresserna från registret eller ytterligare lösa domänerna som finns i registret).

För dessa ändamål skrev jag en enkel mini-dpi — även om jag knappt kan kalla det så. Det är väldigt enkelt och inte särskilt prestandakraftigt — men både för oss och för tiotals (om inte hundratals) andra leverantörer har det gjort att vi inte behöver spendera miljoner på industriella DPI-system direkt, utan fått några extra år på oss.

För att nämna dåvarande och nuvarande DPIMånga som köpte de DPI-system som fanns på marknaden vid den tiden har redan slängt dem. De är inte lämpade för detta: hundratusentals adresser, tiotusentals URL:er.

Samtidigt har inhemska tillverkare verkligen blomstrat i detta segment. Jag pratar inte om hårdvaran — där är det självklart, men mjukvaran — den som finns i DPI — är kanske, om inte den mest avancerade i världen, så i alla fall a) utvecklas i rasande takt och b) billigare i boxformat — helt oöverträffad mot utländska konkurrenter.

Jag skulle vilja vara stolt, men det är lite sorgligt =)

Nu såg allt ut så här:

Ytterligare om ett par år hade alla redan revisorer installerade; resurserna i registret blev fler och fler. För viss gammal utrustning (till exempel Cisco 7600) blev schemat med 'sidofiltering' helt enkelt oanvändbart: antalet rutter på 76-plattformar är begränsat till omkring nio hundratusen, medan antalet IPv4-rutter idag redan når nära 800 tusen. Och om vi även inkluderar ipv6… Och dessutom… hur många är det? 900000 separata adresser i banan av RKN? =)

Några bytte till ett schema där all masttrafik speglas till en filtrerande server, som måste analysera hela flödet och vid upptäckten av något dåligt skicka RST åt båda hållen (till avsändaren och mottagaren).

Men ju mer trafik, desto mindre tillämplig blir en sådan metod. Vid minsta försening i behandlingen — speglad trafik kommer helt osynligt att passera någonstans, och leverantören får en straffprotokoll.

Fler och fler leverantörer tvingas installera DPI-system av olika tillförlitlighet i tvärsnittet av huvudlinjer.

För ett eller två år sedan enligt rykten, började praktiskt taget alla FSB kräva verklig installation av utrustning SORM (tidigare nöjde sig majoriteten av leverantörerna med överenskommelse med myndigheterna SORM-planen — en plan för operativa åtgärder vid behov av att hitta något någonstans)

Förutom pengar (inte så att det är helt absurda summor, men ändå miljontals), krävde SORM för många ytterligare manipulationer med nätverket.

• SORM behöver se användarnas «grå» adresser före nat-översättning
• SORM har ett begränsat antal nätverksgränssnitt

Därför var vi, särskilt, tvungna att omstrukturera en del av kärnan drastiskt — bara för att samla användartrafik till åtkomstservrar någonstans på ett ställe. Så att vi med några länkar kunde spegla det till SORM.

Det vill säga, väldigt förenklat, var (till vänster) vs blev (till höger):

Nu De flesta leverantörer kräver också implementering av SORM-3 — som bland annat omfattar loggning av nat-översättningar.

För dessa syften var vi tvungna att lägga till ytterligare utrustning för NAT i schemat ovan (det som vi talade om i första delen). Dessutom måste det läggas till i en viss ordning: eftersom SORM måste 'se' trafiken före adressöversättning — måste trafiken gå exakt på följande sätt: användare -> växling, kärnan -> åtkomstservrar -> SORM -> NAT -> växling, kärnan -> internet. För detta var vi bokstavligen tvungna att 'vända' trafikflöden i motsatt riktning i realtid, vilket också var ganska svårt.

Sammanfattningsvis: under det senaste decenniet har schemat för kärnan hos en genomsnittlig leverantör blivit avsevärt mer komplicerat, och antalet ytterligare punkter för fel (både i form av utrustning och enskilda kopplingslinjer) har ökat betydligt. Egetligen innebär kravet på att 'se allt' just detta — att sammanföra detta 'allt' på en punkt.

Jag tror att detta ganska transparent kan extrapoleras till nuvarande initiativ för suveränisering av Runet, dess skydd, stabilisering och förbättring 🙂

Och framöver har vi fortfarande Yarovaya.

Källa: habr.com