Heeft mij op dit bericht gewezen .
Ik citeer het hier:
vandaag om 18:53
Ik was vandaag tevreden over de aanbieder. Samen met de update van het siteblokkeringssysteem werd zijn mailer mail.ru verbannen. Ik bel sinds vanochtend de technische ondersteuning, maar ze kunnen niets doen. De aanbieder is klein en kennelijk blokkeren hogere aanbieders deze. Ik merkte ook een vertraging op bij het openen van alle sites, misschien hebben ze een soort kromme DLP geïnstalleerd? Voorheen waren er geen problemen met de toegang. De vernietiging van RuNet gebeurt vlak voor mijn ogen...
Feit is dat het erop lijkt dat wij dezelfde aanbieder zijn :)
En inderdaad, Ik raadde bijna de oorzaak van de problemen met mail.ru (hoewel we lange tijd weigerden in zoiets te geloven).
Wat volgt zal in twee delen worden verdeeld:
- de redenen voor onze huidige problemen met mail.ru en de spannende zoektocht om ze te vinden
- het bestaan van ISP in de hedendaagse realiteit, de stabiliteit van het soevereine RuNet.
Toegankelijkheidsproblemen met mail.ru
O, het is een behoorlijk lang verhaal.
Feit is dat we, om de vereisten van de staat te implementeren (meer details in het tweede deel), bepaalde apparatuur hebben gekocht, geconfigureerd en geïnstalleerd - zowel voor het filteren van verboden bronnen als voor het implementeren van abonnees.
Enige tijd geleden hebben we eindelijk de netwerkkern zo herbouwd dat al het abonneeverkeer strikt in de goede richting door deze apparatuur ging.
Een paar dagen geleden hebben we verboden filters erop ingeschakeld (terwijl we het oude systeem lieten werken) - alles leek goed te gaan.
Vervolgens begonnen ze geleidelijk NAT op deze apparatuur in te schakelen voor verschillende delen van de abonnees. Zo te zien leek alles ook goed te gaan.
Maar vandaag, nadat we NAT hadden ingeschakeld op de apparatuur voor het volgende deel van de abonnees, werden we vanaf de ochtend geconfronteerd met een behoorlijk aantal klachten over niet-beschikbaarheid of gedeeltelijke beschikbaarheid en andere bronnen van Mail Ru Group.
Ze begonnen te controleren: ergens iets soms, af en toe stuurt als reactie op verzoeken uitsluitend aan mail.ru-netwerken. Bovendien verzendt het een verkeerd gegenereerde (zonder ACK), uiteraard kunstmatige TCP RST. Dit is hoe het eruit zag:
Uiteraard gingen de eerste gedachten over de nieuwe apparatuur: vreselijke DPI, geen vertrouwen erin, je weet nooit wat het kan doen - TCP RST is tenslotte een vrij gebruikelijk iets onder blokkeertools.
Veronderstelling We hebben ook het idee naar voren gebracht dat iemand ‘superieur’ aan het filteren is, maar hebben dat meteen terzijde geschoven.
Ten eerste hebben we voldoende gezonde uplinks zodat we niet zo hoeven te lijden :)
Ten tweede zijn we met meerdere verbonden in Moskou, en het verkeer naar mail.ru loopt via hen - en ze hebben geen verantwoordelijkheden of enig ander motief om het verkeer te filteren.
De volgende helft van de dag werd besteed aan wat gewoonlijk sjamanisme wordt genoemd - samen met de leverancier van de apparatuur, waarvoor we hen bedanken, gaven ze niet op :)
- filteren was volledig uitgeschakeld
- NAT is uitgeschakeld met behulp van het nieuwe schema
- de test-pc werd in een afzonderlijke geïsoleerde pool geplaatst
- IP-adres gewijzigd
In de middag werd een virtuele machine toegewezen die volgens het schema van een gewone gebruiker op het netwerk was aangesloten, en kregen vertegenwoordigers van de leverancier toegang tot de machine en de apparatuur. Het sjamanisme ging door :)
Uiteindelijk verklaarde de vertegenwoordiger van de leverancier vol vertrouwen dat de hardware er absoluut niets mee te maken had: de eerste komen ergens hoger vandaan.
NootOp dit punt zou iemand kunnen zeggen: maar het was veel gemakkelijker om een dump te maken, niet van de test-pc, maar van de snelweg boven de DPI?
Nee, helaas is het nemen van een dump (en zelfs alleen maar spiegelen) 40+gbps helemaal niet triviaal.
Hierna zat er 's avonds niets anders op dan terug te keren naar de veronderstelling van een vreemde filtratie ergens daarboven.
Ik heb gekeken via welke IX het verkeer naar de MRG-netwerken nu passeert en heb eenvoudigweg de bgp-sessies ernaar geannuleerd. En – kijk eens! - alles werd onmiddellijk weer normaal 🙁
Aan de ene kant is het jammer dat de hele dag werd besteed aan het zoeken naar het probleem, terwijl het binnen vijf minuten was opgelost.
Aan de andere kant:
– in mijn herinnering is dit iets ongekends. Zoals ik hierboven al schreef - IX echt het heeft geen zin om transitverkeer te filteren. Ze hebben meestal honderden gigabits/terabits per seconde. Ik kon me tot voor kort zoiets serieus niet voorstellen.
– een ongelooflijk gelukkige samenloop van omstandigheden: een nieuwe complexe hardware die niet bijzonder vertrouwd is en waarvan niet duidelijk is wat er kan worden verwacht – specifiek afgestemd op het blokkeren van bronnen, inclusief TCP RST’s
Het NOC van dit internetknooppunt is momenteel op zoek naar een probleem. Volgens hen (en ik geloof ze) beschikken ze niet over een speciaal ingezet filtersysteem. Maar godzijdank is de verdere zoektocht niet langer ons probleem :)
Dit was een kleine poging om mezelf te rechtvaardigen, begrijp het alsjeblieft en vergeef :)
PS: ik noem bewust niet de fabrikant van DPI/NAT of IX (ik heb er zelfs geen speciale klachten over, het belangrijkste is om te begrijpen wat het was)
De realiteit van vandaag (en die van gisteren en eergisteren) vanuit het perspectief van een internetprovider
Ik heb de afgelopen weken de kern van het netwerk aanzienlijk opnieuw opgebouwd, waarbij ik een aantal manipulaties heb uitgevoerd “met winstoogmerk”, met het risico dat het live gebruikersverkeer aanzienlijk zou worden beïnvloed. Als je de doelen, resultaten en gevolgen van dit alles in ogenschouw neemt, is het moreel gezien allemaal behoorlijk moeilijk. Vooral - opnieuw luisteren naar prachtige toespraken over het beschermen van de stabiliteit van de Runet, soevereiniteit, enz. enzovoort.
In dit gedeelte zal ik proberen de ‘evolutie’ van de netwerkkern van een typische ISP in de afgelopen tien jaar te beschrijven.
Tien jaar geleden.
In die gezegende tijden zou de kern van een providernetwerk zo eenvoudig en betrouwbaar kunnen zijn als een file:
In dit zeer vereenvoudigde beeld zijn er geen trunks, ringen en IP/mpls-routering.
De essentie ervan is dat het gebruikersverkeer uiteindelijk op kernelniveau terechtkwam - van waar het naartoe ging , vanwaar, in de regel, terug naar de kernswitching, en dan "uit" - via een of meer grensgateways naar internet.
Een dergelijk schema is heel, heel gemakkelijk te reserveren, zowel op L3 (dynamische routering) als op L2 (MPLS).
U kunt N+1 van alles installeren: toegangsservers, switches, grenzen - en deze op de een of andere manier reserveren voor automatische failover.
Na een paar jaar Het werd voor iedereen in Rusland duidelijk dat het onmogelijk was om nog langer zo te leven: het was dringend nodig om kinderen te beschermen tegen de verderfelijke invloed van internet.
Er was dringend behoefte aan manieren om gebruikersverkeer te filteren.
Er zijn hier verschillende benaderingen.
In een niet zo goed geval wordt er iets “in de kloof” geplaatst: tussen gebruikersverkeer en internet. Het verkeer dat door dit ‘iets’ gaat, wordt geanalyseerd en er wordt bijvoorbeeld een neppakket met een omleiding naar de abonnee gestuurd.
In een iets beter geval (als de verkeersvolumes het toelaten) kunt u een klein trucje met uw oren doen: stuur voor het filteren alleen verkeer dat afkomstig is van gebruikers naar die adressen die moeten worden gefilterd (hiervoor kunt u de IP-adressen gebruiken daar vanuit het register opgegeven, of bovendien bestaande domeinen in het register omzetten).
Ooit schreef ik voor deze doeleinden een eenvoudig – al durf ik hem niet eens zo te noemen. Het is heel eenvoudig en niet erg productief - het stelde ons en tientallen (zo niet honderden) andere aanbieders echter in staat om niet onmiddellijk miljoenen uit te geven aan industriële DPI-systemen, maar het gaf ons enkele jaren extra tijd.
Trouwens, over de toenmalige en huidige DPIVelen die destijds de op de markt verkrijgbare DPI-systemen kochten, hadden deze overigens al weggegooid. Nou, daar zijn ze niet voor ontworpen: honderdduizenden adressen, tienduizenden URL’s.
En tegelijkertijd zijn binnenlandse producenten zeer sterk naar deze markt gestegen. Ik heb het niet over de hardwarecomponent - alles is hier voor iedereen duidelijk, maar software - het belangrijkste dat DPI heeft - is misschien vandaag de dag, zo niet de meest geavanceerde ter wereld, dan zeker a) zich met grote sprongen aan het ontwikkelen, en b) tegen de prijs van een verpakt product - simpelweg onvergelijkbaar met buitenlandse concurrenten.
Ik zou graag trots willen zijn, maar een beetje verdrietig =)
Nu zag alles er zo uit:
Over nog een paar jaar iedereen had al auditors; Er waren steeds meer bronnen in het register. Voor sommige oudere apparatuur (bijvoorbeeld Cisco 7600) werd het ‘side-filtering’-schema eenvoudigweg niet meer van toepassing: het aantal routes op 76 platforms is beperkt tot ongeveer negenhonderdduizend, terwijl het aantal IPv4-routes alleen al vandaag de 800 nadert. duizend. En als het ook ipv6 is... En ook... hoeveel is dat? 900000 individuele adressen in het RKN-verbod? =)
Iemand is overgestapt op een schema waarbij al het backbone-verkeer wordt gespiegeld naar een filterserver, die de hele stroom moet analyseren en, als er iets slechts wordt gevonden, RST in beide richtingen (afzender en ontvanger) moet sturen.
Hoe meer verkeer, hoe minder toepasbaar deze regeling is. Bij de minste vertraging in de verwerking vliegt het gespiegelde verkeer gewoon onopgemerkt voorbij en ontvangt de provider een boeterapport.
Steeds meer aanbieders worden gedwongen om DPI-systemen van verschillende mate van betrouwbaarheid langs snelwegen te installeren.
Een jaar of twee geleden volgens geruchten begon bijna de hele FSB de daadwerkelijke installatie van apparatuur te eisen (voorheen beheerden de meeste aanbieders dit met goedkeuring van de autoriteiten SORM-plan - een plan van operationele maatregelen voor het geval dat er ergens iets gevonden moet worden)
Naast geld (niet bepaald exorbitant, maar nog steeds miljoenen) vereiste SORM nog veel meer manipulaties met het netwerk.
- SORM moet “grijze” gebruikersadressen zien vóór nat-vertaling
- SORM beschikt over een beperkt aantal netwerkinterfaces
Daarom moesten we met name een deel van de kernel grondig opnieuw opbouwen - simpelweg om gebruikersverkeer naar de toegangsservers ergens op één plek te verzamelen. Om het in SORM te spiegelen met verschillende links.
Dat wil zeggen, heel vereenvoudigd, het was (links) versus werd (rechts):
Nu De meeste providers vereisen ook de implementatie van SORM-3 - wat onder meer het loggen van nat-uitzendingen omvat.
Voor deze doeleinden moesten we ook aparte apparatuur voor NAT toevoegen aan het bovenstaande diagram (precies wat in het eerste deel wordt besproken). Voeg bovendien een bepaalde volgorde toe: aangezien SORM het verkeer moet “zien” voordat adressen worden vertaald, moet het verkeer strikt als volgt verlopen: gebruikers -> schakelen, kernel -> toegangsservers -> SORM -> NAT -> schakelen, kernel - > Internet. Om dit te doen, moesten we de verkeersstromen letterlijk de andere kant op ‘draaien’ om winst te maken, wat ook behoorlijk moeilijk was.
Samenvattend: de afgelopen tien jaar is het kernontwerp van een gemiddelde aanbieder vele malen complexer geworden en zijn extra faalpunten (zowel in de vorm van apparatuur als in de vorm van enkele schakellijnen) aanzienlijk toegenomen. Eigenlijk houdt de eis om ‘alles te zien’ in dat dit ‘alles’ tot één punt wordt teruggebracht.
Ik denk dat dit heel transparant geëxtrapoleerd kan worden naar de huidige initiatieven om de Runet te soevereiniseren, te beschermen, te stabiliseren en te verbeteren :)
En Yarovaya loopt nog steeds voorop.
Bron: www.habr.com