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

Det inspirerade mig att skriva detta inlägg den här kommentaren.

Jag tar med den här:

kaleman idag klockan 18:53

Min leverantör gladde mig idag. Tillsammans med uppdateringen av systemet för att blockera webbplatser hamnade mail.ru under blockad. Jag har kontaktat supporten hela morgonen, de kan inte göra något. Leverantören är liten, och de verkar blockeras av större leverantörer. Jag har också märkt av en försening när man öppnar alla webbplatser, kanske har de infört något felaktigt DLP? Tidigare hade vi inga problem med tillgången. Avgörandet av Runet går rakt framför mina ögon...

Grejen är den att det verkar som att vi är just den leverantören 🙁

Och det stämmer faktiskt, kaleman jag gissade nästan rätt med orsaken till problemen med mail.ru (även om vi länge vägrade att tro på något sådant).

Det kommande delas upp i två delar:

1. orsakerna till våra nuvarande problem med mail.ru och en spännande jakt för att lösa dem
2. existed av ISP i dagens verklighet, stabiliteten hos en suverän Runet.

Problem med tillgängligheten av mail.ru

Åh, det är en ganska lång historia.

Grejen är den att för att uppfylla statens krav (mer om detta i del två) har vi köpt, konfigurerat och installerat viss utrustning — både för filtrering av förbjudna resurser och för att genomföra NAT-översättningar för abonnenter.

För ett tag sedan omstrukturerade vi äntligen kärnan i nätverket så att all trafik från abonnenter passerade genom denna utrustning i strikt rätt riktning.

För några dagar sedan aktiverade vi filtreringen av de förbjudna resurserna på den (samtidigt som den gamla systemet fortfarande fungerade) — det såg bra ut.

Därefter började vi gradvis aktivera NAT för olika grupper av abonnenter på denna utrustning. Det såg också ut som om allt gick ganska bra.

Men idag, när vi aktiverade NAT för nästa grupp av abonnenter — stötte vi på ett stort antal klagomål om otillgänglighet eller delvis tillgänglighet mail.ru och andra resurser från Mail Ru Group.

Vi började kontrollera: något vart som helst ibland, någon gång skickar TCP RST som svar på begärningar specifikt till nätverken mail.ru. Mer än så - det skickar felaktigt genererade (utan ACK), uppenbart konstgjorda TCP RST. Ungefär så här såg det ut:

Naturligtvis var de första tankarna om den nya utrustningen: hemska DPI, ingen förtroende för den, vem vet vad den kan ställa till med — eftersom TCP RST är en ganska vanlig sak bland blockeringsverktyg.

Antagande kaleman om att någon "överordnad" filtrerar, har vi också framfört – men vi har genast avfärdat det.

För det första har vi tillräckligt fungerande uplinks för att inte 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 skyldigheter eller någon annan motivation att filtrera trafiken.

Den följande halvdagen spenderades på det som vanligtvis kallas schamanism – tillsammans med hårdvaruleverantören, som vi tackar, gav de inte upp 🙂

• filtreringen stängdes helt av
• NAT stängdes av enligt ny modell
• den testdata PC: n flyttades till en separat isolerad pool
• IP-adresseringen förändrades

Under andra halvan av dagen tilldelades en virtuell maskin som gick ut på nätet som en vanlig användare, och representanter från leverantören gavs tillgång till den och utrustningen. Schamanismen fortsatte 🙂

Till slut uttalade representanten för leverantören med säkerhet att hårdvaran absolut inte var inblandad: rst:er kommer någonstans uppifrån.

AnmärkningHär skulle någon kunna påstå: men det skulle vara mycket enklare att ta en dump inte från den testdata PC: n, utan från högre upp i DPI?

Nej, tyvärr är det inte trivialt 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 såg genom vilken IX trafiken nu går till MRG-näten och stängde helt enkelt bgp-sessionerna till den. Och – mirakulöst! – allt normaliserades omedelbart 🙁

Å ena sidan är det trevligt att hela dagen gick åt till att leta efter problemet, även om det löste sig på fem minuter.

Å andra sidan:

– på minnet är detta en utan motstycke händelse. Som jag redan skrev ovan – IX:erna verkligen har ingen anledning att filtrera transit-trafik. De har vanligtvis hundratals gigabit / terabit per sekund. Jag kunde helt enkelt inte seriöst föreställa mig något sådant.

– en otroligt lyckosam samverkande omständighet: ny komplex hårdvara som man inte har mycket förtroende för och man vet inte vad man kan vänta sig – utformad just för att blockera resurser, inklusive TCP RST:er.

För närvarande söker NOC för detta internetutbyte problemet. Enligt deras påstående (och jag tror dem) finns det ingen speciellt utrullad filtreringssystem. Men tack och lov är nästa quest redan inte vårt problem 🙂

Det här var ett litet försök att försvara sig, 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 ens några särskilda klagomål på 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ätverkskärnan, vilket innebar en massa 'live'-åtgärder, med risk för att störda levande användartrafik. Med tanke på målen, resultaten och konsekvenserna av allt detta är det moraliskt ganska tufft. Särskilt när man återigen lyssnar på vackra tal om att skydda stabiliteten i RuNet, suveränitet, osv.

I det här avsnittet kommer jag att försöka förklara 'evolutionen' av nätverkskärnan för en typisk internetleverantör under det senaste decenniet.

För ett decennium sedan.

På den välsignade tiden kunde en leverantörsnätverks kärna vara enkel och pålitlig, som en kork:

På den här mycket förenklade bilden saknas stora vägar, ringar, ip/mpls-ruttning.

Essensen var att användartrafiken i slutändan nådde kärnnivåns switchning – därifrån gick den till BNG, därifrån, som regel, tillbaka till kärnans switchning, och vidare 'ut' – genom en eller flera border gateway’s till internet.

En liknande ordning kan mycket lätt reserveras både på L3 (dynamisk routing) och på L2 (MPLS).

Man kan sätta upp N+1 av vad som helst: åtkomstservrar, switchar, border-enheter – och på det eller annat sätt reservera dem för automatisk failover.

Några år senare blev det klart för alla i Ryssland att det inte gick att fortsätta så här: vi måste 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ändartjänsttrafik.

Det finns olika tillvägagångssätt här.

I ett mindre 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 ett något bättre fall – om trafikvolymerna tillåter – kan man göra ett litet trick: endast skicka utgående trafik från användare för filtrering 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 upp domänerna som finns i registret).

För dessa syften skrev jag en enkel mini-dpi – även om språket knappt vill låta mig kalla det så. Det är väldigt enkelt och inte särskilt effektivt – men för både oss och tiotals (om inte hundratals) andra leverantörer har det gjort det möjligt att inte lägga ut miljontals på industriella DPI-system, utan har gett oss några extra år.

För övrigt, om dåtidens och dagens DPIMånga av dem som köpte de DPI-system som fanns på marknaden vid den tiden har redan kastat bort dem. De är helt enkelt inte anpassade för sådant: hundratusentals adresser, tiotusentals URL:er.

Samtidigt har inhemska tillverkare verkligen fått upp farten i detta segment. Jag pratar inte om den hårdvarumässiga delen – det är klart för alla, men mjukvaran – det viktigaste i DPI – är kanske, om inte den mest avancerade i världen, så åtminstone a) utvecklas i rasande fart och b) när det gäller priset på förpackningar – är helt enkelt oöverträffbar i förhållande till utländska konkurrenter.

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

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

Ännu några år senare hade alla redan revisorer installerade; resurserna i registret blev fler och fler. För viss gammal utrustning (till exempel Cisco 7600) blev schemat med "sido-filtrering" helt enkelt oanvändbart: antalet rutter på 76-plattformar är begränsat till cirka nio hundra tusen, medan antalet IPv4-rutter idag redan närmar sig 800 tusen. Och om vi dessutom räknar med ipv6… Och ytterligare… hur många var det nu? 900000 enskilda adresser blockeras av RKN? =)

Vissa gick över till ett schema där all kärntrafik speglades till en filtreringsserver som måste analysera hela flödet och, vid upptäckten av något olämpligt, skicka RST i båda riktningarna (till avsändaren och mottagaren).

Men ju mer trafik, desto mindre tillämpbar blir ett sådant schema. Vid den minsta fördröjningen i bearbetningen kommer den speglade trafiken helt enkelt att osynligt flyga iväg, och leverantören får en protokoll om bötfällning.

All the more providers are forced to implement DPI systems of varying reliability in the fiber optic routes.

A year or two ago it was rumored that practically all the FSB began to require real equipment installation SORM (previously, most providers managed with mere agreements with the authorities) the SORM plan — a plan of operational measures in case something needs to be found somewhere)

Besides the cost (not excessively high, but still millions), SORM required many to make additional manipulations with the network.

• SORM needs to see the users' 'gray' addresses before NAT translation
• SORM has a limited number of network interfaces

Therefore, we had to significantly restructure a part of the core — just to gather user traffic to access servers in one place. To mirror it to SORM via several links.

That is, very simply put, what was (on the left) vs what has become (on the right):

Nu Most providers are also required to implement SORM-3 — which includes, among other things, logging of NAT translations.

For this purpose, we had to add separate equipment for NAT to the scheme above (exactly that which was mentioned in the first part). Moreover, to add it in a certain order: since SORM must 'see' the traffic before address translation — the traffic must follow this path strictly: users -> switching, core -> access servers -> SORM -> NAT -> switching, core -> internet. For this, we literally had to 'reverse' the traffic flows alive, which was also quite challenging.

In total: over a decade, the core structure of the average provider has become several times more complex, and the number of additional points of failure (both in the form of equipment and unified switching lines) has significantly increased. The requirement to 'see everything' in itself implies bringing all this 'everything' to one point.

I believe this can be quite transparently extrapolated onto the current initiatives for the sovereignty of Runet, its protection, stabilization, and improvement 🙂

And ahead, there’s still Yarovaya.

Källa: habr.com