Hij inspireerde me tot deze post .
Hier breng ik het naar voren:
vandaag om 18:53
Vandaag heeft de provider me blij gemaakt. In combinatie met de update van het blokkadesysteem is de mailprovider mail.ru geblokkeerd geraakt. 's Ochtends heb ik de technische ondersteuning gebeld, maar ze konden niets doen. De provider is klein en blijkbaar blokkeren ze de hogere providers. Ik merkte ook vertraging bij het openen van alle websites, misschien hebben ze iets fout met DLP geïnstalleerd? Eerder waren er geen toegangproblemen. De vernietiging van het Runet gebeurt met mijn eigen ogen...
Het punt is dat we blijkbaar die provider zijn 🙁
En dat klopt echt, ik heb bijna de oorzaak van de problemen met mail.ru geraden (hoewel we daar lange tijd niet in konden geloven).
Het vervolg zal in twee delen worden verdeeld:
- de oorzaken van onze huidige problemen met mail.ru en een fascinerende zoektocht naar hun oorzaak
- het bestaan van ISP's in de huidige realiteit, de stabiliteit van een soeverein Runet.
Problemen met de toegankelijkheid van mail.ru
Oh, dit is een vrij lang verhaal.
Het punt is dat we om aan de eisen van de staat te voldoen (meer details in het tweede deel) enige apparatuur hebben aangeschaft, ingesteld en geïnstalleerd — zowel voor het filteren van verboden bronnen als voor het uitvoeren van van abonnees.
Een tijdje geleden hebben we eindelijk de netwerkstructuur zo veranderd dat al het verkeer van abonnees strikt door deze apparatuur in de juiste richting gaat.
Enkele dagen geleden hebben we de filtering van de verboden inhoud ingeschakeld (terwijl we ook het oude systeem operationeel lieten) — het leek goed te werken.
Daarna hebben we geleidelijk NAT ingeschakeld voor verschillende delen van de abonnees op deze apparatuur. Ook dat leek, al met al, goed te gaan.
Maar vandaag, toen we NAT inschakelden voor opnieuw een deel van de abonnees — kregen we 's ochtends een behoorlijk aantal klachten over de onbeschikbaarheid of gedeeltelijke beschikbaarheid van en andere bronnen van Mail Ru Group.
We begonnen te controleren: iets ergens soms, af en toe zendt als reactie op verzoeken specifiek naar de netwerken van mail.ru. Bovendien – verstuurt het een verkeerd gegenereerde (zonder ACK), duidelijk kunstmatige TCP RST. Zo zag het eruit:
Natuurlijk waren de eerste gedachten over de nieuwe apparatuur: vreselijke DPI, geen vertrouwen erin, wie weet wat het kan uithalen – omdat TCP RST een vrij veelvoorkomende zaak is onder blokkeringtools.
Veronderstelling dat iemand van 'hogere' instantie filtert, hebben we ook geopperd - maar hebben het meteen verworpen.
Ten eerste hebben we voldoende fatsoenlijke uplinks om dit soort dingen niet te lijden 🙂
Ten tweede zijn we aangesloten op verschillende in Moskou, en het verkeer naar mail.ru gaat precies via hen - en zij hebben noch verplichtingen, noch enige motivatie om verkeer te filteren.
De volgende halve dag werd besteed aan wat meestal sjamanisme wordt genoemd - samen met de leverancier van de apparatuur, waarvoor dank, hebben ze ons niet in de steek gelaten 🙂
- de filtering werd volledig uitgeschakeld
- NAT werd volgens een nieuw schema uitgeschakeld
- de test-PC werd in een aparte geïsoleerde pool geplaatst
- het IP-adres veranderde
In de tweede helft van de dag werd er een virtuele machine toegewezen die het netwerk op de gebruikelijke gebruikerswijze betreedt, en zowel zij als de apparatuur kregen toegang voor de vertegenwoordigers van de leverancier. Het sjamanisme ging door 🙂
Uiteindelijk verklaarde de vertegenwoordiger van de leverancier met zekerheid dat de apparatuur helemaal niet betrokken was: rst's komen van ergens hoger.
OpmerkingOp dit punt kan iemand zeggen: maar het zou veel eenvoudiger zijn geweest om een dump te nemen van de test-PC, en niet van de hoofdverbinding boven het DPI?
Helaas is het nemen van een dump (en zelfs gewoon mirroren) van 40+ gbps helemaal niet triviaal.
Daarna, al in de avond - bleef er niets anders over dan terug te keren naar de veronderstelling van vreemde filtering ergens hoger.
Ik keek naar welke IX het verkeer naar de MRG-netwerken momenteel passeert en heb simpelweg de bgp-sessies ermee uitgeschakeld. En - oh wonder! - alles normaliseerde onmiddellijk 🙁
Aan de ene kant is het heel triest dat er een hele dag is besteed aan het zoeken naar het probleem, terwijl het in vijf minuten opgelost werd.
Aan de andere kant:
- naar mijn weten is dit een zonder precedent geval. Zoals ik hierboven al schreef - IX'en inderdaad heeft helemaal geen zin om transitverkeer te filteren. Gewoonlijk hebben ze honderden gigabits / terabits per seconde. Ik kon gewoon tot het laatst niet serieus vermoeden dat dit het geval was.
- een ongelooflijk gelukkig toeval: nieuwe complexe apparatuur, waarvoor er bijzonder weinig vertrouwen is en waarvan het onduidelijk is wat te verwachten - ontworpen precies voor de blokkering van bronnen, inclusief TCP RST's.
Momenteel zoekt het NOC van deze internet exchange naar een probleem. Volgens hun verklaring (en ik geloof hen) hebben ze geen speciaal opgezette filteringssystemen. Maar gelukkig is de volgende zoektocht al niet meer ons probleem 🙂
Dit was een kleine poging tot verontschuldiging, we vragen om begrip en vergeving 🙂
P.S.: Ik noem bewust geen fabrikant van DPI/NAT, noch IX (ik heb eigenlijk geen bijzondere klachten over hen, het belangrijkste is om te begrijpen wat er gebeurde)
De realiteit van vandaag (evenals van gisteren en eergisteren) vanuit het perspectief van een internetprovider
De afgelopen weken heb ik doorgebracht met het ingrijpend herstructureren van de kern van ons netwerk, terwijl ik veel handelingen "live" uitvoerde, met het risico om significante impact op het gebruikersverkeer te hebben. Gezien de doelen, resultaten en gevolgen van dit alles — is het moreel behoorlijk zwaar. Vooral als ik opnieuw mooie toespraken hoor over het beschermen van de stabiliteit van het Runet, soevereiniteit, enzovoort.
In deze sectie zal ik proberen de "evolutie" van de kern van het netwerk van een typische internetprovider in het afgelopen decennium te beschrijven.
Een decennium geleden.
In die gezegende tijden kon de kern van het provider netwerk zo eenvoudig en betrouwbaar zijn als een kurk:
Op deze zeer vereenvoudigde afbeelding ontbreken snelwegen, ringen, ip/mpls-routering.
De essentie is dat het gebruikersverkeer uiteindelijk bij de kernswitching kwam — van waaruit het doorging naar , van waaruit het meestal terugging naar de kernswitching, en daarna "naar buiten" — via een of meerdere border gateways naar het internet.
Een dergelijke opzet kan heel eenvoudig worden gereserveerd, zowel op L3 (dynamische routering) als op L2 (MPLS).
Je kunt N+1 van wat dan ook plaatsen: toegangservers, switches, borders — en ze zo of anders voor automatische failover reserveren.
Na een paar jaar begon iedereen in Rusland te begrijpen dat zo verder leven niet mogelijk was: kinderen moesten dringend worden beschermd tegen de schadelijke invloeden van het netwerk.
Er ontstond de noodzaak om dringend manieren te vinden om het gebruikersverkeer te filteren.
Hier zijn verschillende benaderingen.
In het niet zo goede geval wordt er iets "in het midden" geplaatst: tussen het gebruikersverkeer en het internet. Het verkeer dat door dit "iets" gaat, wordt geanalyseerd en bijvoorbeeld gaat er een inactief pakket met een redirect naar de abonnee.
In een iets betere situatie — als de verkeersvolumes het toelaten — kan men een kleine truc toepassen: alleen het verkeer dat van gebruikers afkomstig is, filteren naar die adressen die gefilterd moeten worden (hiervoor kan men ofwel de opgegeven IP-adressen uit het register gebruiken, of aanvullend de in het register aanwezige domeinen resolveren).
Destijds schreef ik hiervoor een eenvoudige — hoewel zelfs de taal niet zover gaat om het zo te noemen. Het is erg eenvoudig en niet bijzonder efficiënt — maar zowel voor ons als voor tientallen (zo niet honderden) andere aanbieders stelde het ons in staat om niet in één keer miljoenen uit te geven aan industriële DPI-systemen, en gaf het ons enkele extra jaren tijd.
Trouwens, over de toenmalige en huidige DPIOm te zeggen, veel mensen die de ter beschikking staande DPI-systemen kochten — hebben ze al weggegooid. Ze zijn simpelweg niet geschikt voor dit doel: honderden duizenden adressen, tienduizenden URL's.
En tegelijkertijd hebben binnenlandse producenten zich sterk in deze markt ontwikkeld. Ik zeg niet veel over de hardware — dat spreekt voor zich, maar de software — het belangrijkste dat er in DPI is — is mogelijk, als het niet de meest geavanceerde ter wereld is, dan is het in ieder geval a) zich razendsnel aan het ontwikkelen, en b) qua prijs voor de doos — gewoon onvergelijkbaar met buitenlandse concurrenten.
Ik zou graag trots willen zijn, maar het is een beetje droevig =)
Nu zag alles eruit als volgt:
Enkele jaren later hadden iedereen al revisors; de bronnen in het register werden steeds meer. Voor sommige oude apparatuur (zoals Cisco 7600) werd het schema met 'filtering aan de zijlijn' gewoonweg onbruikbaar: het aantal routes op de 76 platformen is beperkt tot iets van ongeveer negenhonderdduizend, terwijl het aantal IPv4-routes vandaag al bijna 800.000 bedraagt. En als we ook ipv6... en nog... hoeveel zijn er? 900.000 afzonderlijke adressen in de ban van de RKN? =)
Sommigen stapten over op een schema waarbij al het hoofdverkeer naar een filterserver werd gespiegeld, die de hele stroom moest analyseren en bij het vinden van iets ongewensts, RST in beide richtingen (van zender naar ontvanger) moest versturen.
Echter, hoe meer verkeer, hoe minder toepasbaar zo'n schema is. Bij de kleinste vertraging in de verwerking — vliegt het gespiegeld verkeer gewoon onopgemerkt nergens heen, terwijl de provider een boete-protocol ontvangt.
Steeds meer providers worden gedwongen om DPI-systemen van verschillende betrouwbaarheid op de hoofdverbindingen te installeren.
Een jaar of twee geleden werd er gerucht dat de FSB van praktisch iedereen de daadwerkelijke installatie van apparatuur vereiste (vroeger konden de meeste providers zich met goedkeuring van de autoriteiten redden SORM-plan — een plan voor operationele activiteiten voor het geval dat men ergens iets moet vinden)
Naast geld (niet dat het astronomische bedragen zijn, maar ongeveer miljoenen) vereiste SORM van velen opnieuw manipulaties met het netwerk.
- SORM moet de 'grijze' adressen van gebruikers zien, vóór de NAT-translatie.
- SORM heeft een beperkt aantal netwerkinterfaces.
Daarom moesten we, onder andere, een groot deel van de kernel opnieuw opzetten - gewoon om het verkeer van gebruikers naar de toegangservers op één plek te verzamelen. Om het met enkele links naar SORM te mirroren.
Dus, heel vereenvoudigd, was (links) versus werd (rechts):
Nu vereisen de meeste providers ook de implementatie van SORM-3 - dat houdt ook in dat logging van NAT-translatie vereist is.
Voor deze doeleinden moesten we in het bovenstaande schema ook apart apparatuur voor NAT toevoegen (precies datgene waar het in het eerste deel over gaat). En dat in een bepaalde volgorde toevoegen: aangezien SORM het verkeer vóór het translateren van adressen moet 'zien' - het verkeer moet strikt als volgt gaan: gebruikers -> switching, kernel -> toegangservers -> SORM -> NAT -> switching, kernel -> internet. Hiervoor moesten we letterlijk de verkeersstromen aan de andere kant omkeren, wat ook vrij ingewikkeld was.
Kortom: in het afgelopen decennium is het schema van de kernel van een gemiddelde provider slechts ingewikkelder geworden, en het aantal mogelijke falingspunten (zowel in de vorm van apparatuur als in de vorm van enkele switchinglijnen) is aanzienlijk toegenomen. Het vereiste om 'alles' te zien, impliceert in wezen dat dit 'alles' op één punt moet worden samengebracht.
Ik denk dat dit heel transparant kan worden geëxtrapoleerd naar de huidige initiatieven voor de soevereiniteit van het Russische internet, de bescherming, stabilisatie en verbetering 🙂
En voor ons ligt nog Yarovaya.
Bron: habr.com
