Het my aangespoor na hierdie pos .
Ek haal dit hier aan:
vandag om 18:53
Ek was vandag tevrede met die verskaffer. Saam met die opdatering van die werfblokkeringstelsel is sy mailer mail.ru verban.Ek het vanoggend tegniese ondersteuning gebel, maar hulle kan niks doen nie. Die verskaffer is klein, en blykbaar blokkeer verskaffers met 'n hoër posisie dit. Ek het ook 'n verlangsaming in die opening van alle werwe opgemerk, miskien het hulle 'n soort krom DLP geïnstalleer? Voorheen was daar geen probleme met toegang nie. Die vernietiging van RuNet gebeur reg voor my oë...
Die feit is dat dit lyk asof ons dieselfde verskaffer is :)
En inderdaad, Ek het amper die oorsaak van die probleme met mail.ru geraai (alhoewel ons lank geweier het om in so iets te glo).
Wat volg sal in twee dele verdeel word:
- die redes vir ons huidige probleme met mail.ru en die opwindende soeke om dit te vind
- die bestaan van ISP in vandag se realiteite, die stabiliteit van die soewereine RuNet.
Toeganklikheidsprobleme met mail.ru
O, dis nogal 'n lang storie.
Die feit is dat om die vereistes van die staat te implementeer (meer besonderhede in die tweede deel), ons 'n paar toerusting gekoop, gekonfigureer en geïnstalleer - beide vir die filter van verbode hulpbronne en vir die implementering intekenare.
'n Tyd gelede het ons uiteindelik die netwerkkern so herbou dat alle intekenaarverkeer streng in die regte rigting deur hierdie toerusting gegaan het.
'n Paar dae gelede het ons verbode filtering daarop aangeskakel (terwyl ons die ou stelsel laat werk het) - dit het gelyk of alles goed verloop.
Vervolgens het hulle geleidelik begin om NAT op hierdie toerusting vir verskillende dele van intekenare te aktiveer. Uit die voorkoms daarvan het alles ook gelyk of dit goed verloop.
Maar vandag, nadat ons NAT op die toerusting vir die volgende deel van intekenare geaktiveer het, het ons van die oggend af gekonfronteer met 'n ordentlike aantal klagtes oor onbeskikbaarheid of gedeeltelike beskikbaarheid en ander Mail Ru Group hulpbronne.
Hulle het begin kyk: iewers iets soms, af en toe stuur in reaksie op versoeke uitsluitlik aan mail.ru-netwerke. Boonop stuur dit 'n verkeerd gegenereerde (sonder ACK), natuurlik kunsmatige TCP RST. Dit is hoe dit gelyk het:
Natuurlik was die eerste gedagtes oor die nuwe toerusting: verskriklike DPI, geen vertroue daarin nie, jy weet nooit wat dit kan doen nie - TCP RST is immers 'n redelik algemene ding onder blokkeergereedskap.
aanname Ons het ook die idee na vore gebring dat iemand “meerderwaardige” filter, maar het dit dadelik weggegooi.
Eerstens, ons het voldoende gesonde opskakels sodat ons nie so hoef te ly nie :)
Tweedens is ons met verskeie verbind in Moskou, en verkeer na mail.ru gaan deur hulle - en hulle het geen verantwoordelikhede of enige ander motief om verkeer te filter nie.
Die volgende helfte van die dag is spandeer aan wat gewoonlik sjamanisme genoem word - saam met die toerustingverkoper, waarvoor ons hulle bedank, het hulle nie moed opgegee nie :)
- filtering is heeltemal gedeaktiveer
- NAT is gedeaktiveer met die nuwe skema
- die toetsrekenaar is in 'n aparte geïsoleerde swembad geplaas
- IP-adres verander
In die middag is 'n virtuele masjien toegeken wat volgens die skema van 'n gereelde gebruiker aan die netwerk gekoppel is, en verteenwoordigers van die verkoper is toegang daartoe en die toerusting gegee. Die sjamanisme het voortgeduur :)
Op die ou end het die verkoper se verteenwoordiger met selfvertroue gesê dat die hardeware absoluut niks daarmee te doen het nie: die eerstes kom van iewers hoër.
Let daaropOp hierdie stadium kan iemand sê: maar dit was baie makliker om 'n storting nie van die toetsrekenaar af te neem nie, maar vanaf die snelweg bokant die DPI?
Nee, ongelukkig is om 'n storting (en selfs net weerspieël) 40+gbps glad nie triviaal nie.
Hierna, in die aand, was daar niks meer om te doen as om terug te keer na die aanname van vreemde filtrasie iewers hierbo nie.
Ek het gekyk deur watter IX die verkeer na die MRG-netwerke nou deurgaan en eenvoudig die bgp-sessies daarheen gekanselleer. En - siedaar! - alles het dadelik teruggekeer na normaal 🙁
Aan die een kant is dit jammer dat die hele dag na die probleem gesoek is, hoewel dit in vyf minute opgelos is.
Aan die ander kant:
— in my geheue is dit 'n ongekende ding. Soos ek reeds hierbo geskryf het - IX werklik daar is geen sin daarin om transitoverkeer te filter nie. Hulle het gewoonlik honderde gigabit/terabit per sekonde. Ek kon my net nie ernstig so iets voorstel tot onlangs nie.
- 'n ongelooflike gelukkige toeval van omstandighede: 'n nuwe komplekse hardeware wat nie besonder vertrou word nie en waarvan dit nie duidelik is wat verwag kan word nie - spesifiek aangepas om hulpbronne te blokkeer, insluitend TCP RST's
Die NOC van hierdie internetbeurs soek tans 'n probleem. Volgens hulle (en ek glo hulle) het hulle geen spesiaal ontplooide filtrasiestelsel nie. Maar, dank die hemel, die verdere soeke is nie meer ons probleem nie :)
Hierdie was 'n klein poging om myself te regverdig, verstaan asseblief en vergewe :)
NS: Ek noem doelbewus nie die vervaardiger van DPI/NAT of IX nie (trouens, ek het nie eens spesiale klagtes oor hulle nie, die belangrikste ding is om te verstaan wat dit was)
Vandag (sowel as gister en eergister s'n) se werklikheid vanuit die oogpunt van 'n internetverskaffer
Ek het die afgelope weke aansienlik spandeer om die kern van die netwerk te herbou, 'n klomp manipulasies "vir wins" uit te voer, met die risiko om lewendige gebruikersverkeer aansienlik te beïnvloed. As die doelwitte, resultate en gevolge van dit alles in ag geneem word, is dit moreel nogal moeilik. Veral - weereens luister na pragtige toesprake oor die beskerming van die stabiliteit van die Runet, soewereiniteit, ens. en so aan.
In hierdie afdeling sal ek probeer om die "evolusie" van die netwerkkern van 'n tipiese ISP oor die afgelope tien jaar te beskryf.
Tien jaar gelede.
In daardie geseënde tye kan die kern van 'n verskaffernetwerk so eenvoudig en betroubaar soos 'n verkeersknoop wees:
In hierdie baie, baie vereenvoudigde prentjie is daar geen stamme, ringe, ip/mpls-roetering nie.
Die essensie daarvan is dat gebruikersverkeer uiteindelik tot die kernvlakwisseling gekom het - van waar dit heen gegaan het , van waar, as 'n reël, terug na die kernskakeling, en dan "uit" - deur een of meer grenspoorte na die internet.
So 'n skema is baie, baie maklik om te bespreek beide op L3 (dinamiese roetering) en op L2 (MPLS).
Jy kan N+1 van enigiets installeer: toegang tot bedieners, skakelaars, grense - en op een of ander manier reserveer dit vir outomatiese failover.
Na 'n paar jaar Dit het vir almal in Rusland duidelik geword dat dit onmoontlik was om langer so te lewe: dit was dringend om kinders teen die verderflike invloed van die internet te beskerm.
Daar was 'n dringende behoefte om maniere te vind om gebruikersverkeer te filter.
Hier is verskillende benaderings.
In 'n nie baie goeie geval nie, word iets "in die gaping" geplaas: tussen gebruikersverkeer en die internet. Die verkeer wat deur hierdie "iets" gaan, word ontleed en byvoorbeeld 'n vals pakkie met 'n herleiding word na die intekenaar gestuur.
In 'n effens beter geval - as verkeersvolumes dit toelaat - kan jy 'n klein truuk met jou ore doen: stuur vir filter net verkeer wat slegs van gebruikers afkomstig is na daardie adresse wat gefiltreer moet word (om dit te doen, kan jy óf die IP-adresse neem daar uit die register gespesifiseer, of los ook bestaande domeine in die register op).
Op 'n tyd, vir hierdie doeleindes, het ek 'n eenvoudige - alhoewel ek hom nie eers so durf noem nie. Dit is baie eenvoudig en nie baie produktief nie - dit het ons en dosyne (indien nie honderde nie) ander verskaffers egter toegelaat om nie onmiddellik miljoene op industriële DPI-stelsels uit te haal nie, maar het 'n paar ekstra jare van tyd gegee.
Terloops, oor die destydse en huidige DPITerloops, baie wat die DPI-stelsels wat destyds op die mark beskikbaar was gekoop het, het dit reeds weggegooi. Wel, hulle is nie hiervoor ontwerp nie: honderdduisende adresse, tienduisende URL's.
En terselfdertyd het binnelandse produsente baie sterk na hierdie mark gestyg. Ek praat nie van die hardeware komponent nie - alles is duidelik vir almal hier, maar sagteware - die belangrikste ding wat DPI het - is miskien vandag, indien nie die mees gevorderde in die wêreld nie, dan beslis a) ontwikkel met rasse skrede, en b) teen die prys van 'n boksproduk - eenvoudig onvergelykbaar met buitelandse mededingers.
Ek wil graag trots wees, maar bietjie hartseer =)
Nou het alles so gelyk:
Oor nog 'n paar jaar almal het reeds ouditeure gehad; Daar was meer en meer hulpbronne in die register. Vir sommige ouer toerusting (byvoorbeeld Cisco 7600), het die "kantfiltering"-skema eenvoudig ontoepasbaar geword: die aantal roetes op 76 platforms is beperk tot iets soos negehonderdduisend, terwyl die aantal IPv4-roetes alleen vandag 800 nader. duisend. En as dit ook ipv6 is ... En ook ... hoeveel is daar? 900000 XNUMX individuele adresse in die RKN-verbod? =)
Iemand het oorgeskakel na 'n skema met weerspieëling van alle ruggraatverkeer na 'n filterbediener, wat die hele vloei moet ontleed en, as iets sleg gevind word, RST in beide rigtings (sender en ontvanger) stuur.
Hoe meer verkeer, hoe minder toepaslik is hierdie skema egter. As daar die geringste vertraging in verwerking is, sal die spieëlverkeer eenvoudig ongemerk verbyvlieg, en die verskaffer sal 'n boeteverslag ontvang.
Al hoe meer verskaffers word gedwing om DPI-stelsels van verskillende grade van betroubaarheid oor snelweë te installeer.
'n Jaar of twee gelede volgens gerugte het byna al die RFD die werklike installering van toerusting begin eis (Voorheen het die meeste verskaffers met goedkeuring van die owerhede bestuur SORM plan - 'n plan van operasionele maatreëls in geval van behoefte om iewers iets te vind)
Benewens geld (nie juis buitensporig nie, maar steeds miljoene), het SORM baie meer manipulasies met die netwerk vereis.
- SORM moet "grys" gebruikersadresse sien voor nat vertaling
- SORM het 'n beperkte aantal netwerkkoppelvlakke
Daarom moes ons veral 'n stuk van die kern grootliks herbou - bloot om gebruikersverkeer na die toegangsbedieners iewers op een plek te versamel. Om dit in SORM met verskeie skakels te weerspieël.
Dit wil sê, baie vereenvoudig, dit was (links) vs geword (regs):
Nou Die meeste verskaffers vereis ook die implementering van SORM-3 – wat onder andere die aanteken van nat-uitsendings insluit.
Vir hierdie doeleindes moes ons ook aparte toerusting vir NAT by die diagram hierbo voeg (presies wat in die eerste deel bespreek word). Voeg boonop in 'n sekere volgorde by: aangesien SORM die verkeer moet "sien" voordat adresse vertaal word, moet die verkeer streng soos volg verloop: gebruikers -> skakeling, kern -> toegang tot bedieners -> SORM -> NAT -> skakeling, kern - > Internet. Om dit te doen, moes ons verkeersvloeie letterlik in die ander rigting “draai” vir wins, wat ook nogal moeilik was.
Samevattend: oor die afgelope tien jaar het die kernontwerp van 'n gemiddelde verskaffer baie keer meer kompleks geword, en bykomende punte van mislukking (beide in die vorm van toerusting en in die vorm van enkele skakellyne) het aansienlik toegeneem. Eintlik impliseer die einste vereiste om “alles te sien” dat hierdie “alles” tot een punt gereduseer word.
Ek dink dit kan redelik deursigtig geëkstrapoleer word na huidige inisiatiewe om die Runet te soewereiniseer, dit te beskerm, dit te stabiliseer en te verbeter :)
En Yarovaya is steeds voor.
Bron: will.com