Instigis min al ĉi tiu afiŝo .
Mi citas ĝin ĉi tie:
hodiaŭ je 18:53
Mi estis kontenta pri la provizanto hodiaŭ. Kune kun la ĝisdatigo de la reteja bloksistemo, lia poŝtilo mail.ru estis malpermesita.Mi vokas teknikan subtenon ekde la mateno, sed ili nenion povas fari. La provizanto estas malgranda, kaj ŝajne pli altaj provizantoj blokas ĝin. Mi ankaŭ rimarkis malrapidiĝon en la malfermo de ĉiuj retejoj, eble ili instalis ian malrektan DLP? Antaŭe ne estis problemoj pri aliro. La detruo de RuNet okazas ĝuste antaŭ miaj okuloj...
Fakte, ŝajnas, ke ni estas tiu sama provizanto :)
Kaj efektive, Mi preskaŭ divenis la kaŭzon de la problemoj kun mail.ru (kvankam ni longe rifuzis kredi je tia afero).
Kio sekvas estos dividita en du partojn:
- la kialoj de niaj nunaj problemoj kun mail.ru kaj la ekscita serĉo trovi ilin
- la ekzisto de ISP en la hodiaŭaj realaĵoj, la stabileco de la suverena RuNet.
Problemoj de alirebleco kun mail.ru
Ho, ĝi estas sufiĉe longa rakonto.
La fakto estas, ke por efektivigi la postulojn de la ŝtato (pli da detaloj en la dua parto), ni aĉetis, agordis kaj instalis iujn ekipaĵojn - kaj por filtri malpermesitajn rimedojn kaj por efektivigi abonantoj.
Antaŭ iom da tempo, ni finfine rekonstruis la retan kernon tiel, ke la tuta trafiko de abonantoj trapasis ĉi tiun ekipaĵon strikte en la ĝusta direkto.
Antaŭ kelkaj tagoj ni ŝaltis malpermesitan filtradon sur ĝi (dum lasante la malnovan sistemon funkcianta) - ĉio ŝajnis iri bone.
Poste, ili iom post iom komencis ebligi NAT sur ĉi tiu ekipaĵo por malsamaj partoj de abonantoj. Laŭ la aspekto de ĝi, ĉio ankaŭ ŝajnis iri bone.
Sed hodiaŭ, ebligis NAT en la ekipaĵo por la sekva parto de abonantoj, ekde la mateno mem ni alfrontis decan nombron da plendoj pri nehavebleco aŭ parta havebleco. kaj aliaj rimedoj de Mail Ru Group.
Ili komencis kontroli: ion ie kelkfoje, foje sendas responde al petoj ekskluzive al mail.ru-retoj. Plie, ĝi sendas malĝuste generitan (sen ACK), evidente artefaritan TCP RST. Jen kiel ĝi aspektis:
Kompreneble, la unuaj pensoj temis pri la nova ekipaĵo: terura DPI, neniu fido al ĝi, vi neniam scias, kion ĝi povas fari - post ĉio, TCP RST estas sufiĉe ofta afero inter blokaj iloj.
Supozo Ni ankaŭ prezentis la ideon, ke iu "supera" filtras, sed tuj forĵetis ĝin.
Unue, ni havas sufiĉe prudentajn suprenligilojn por ke ni ne devas suferi tiel :)
Due, ni estas konektitaj al pluraj en Moskvo, kaj trafiko al mail.ru trairas ilin - kaj ili havas nek respondecojn nek alian motivon por filtri trafikon.
La sekva duono de la tago estis pasigita por tio, kio estas kutime nomata ŝamanismo - kune kun la ekipaĵvendisto, pro kio ni dankas ilin, ili ne rezignis :)
- filtrado estis tute malŝaltita
- NAT estis malŝaltita uzante la novan skemon
- la testa komputilo estis metita en apartan izolitan naĝejon
- IP-adreso ŝanĝiĝis
Posttagmeze, virtuala maŝino estis asignita, kiu konektis al la reto laŭ la skemo de kutima uzanto, kaj reprezentantoj de la vendisto ricevis aliron al ĝi kaj la ekipaĵo. La ŝamanismo daŭris :)
Fine, la reprezentanto de la vendisto memfide deklaris, ke la aparataro tute ne rilatas al ĝi: la unuaj venas de ie pli alta.
ПримечаниеJe ĉi tiu punkto, iu povas diri: sed estis multe pli facile preni rubejon ne de la testa komputilo, sed de la aŭtovojo super la DPI?
Ne, bedaŭrinde, preni rubejon (kaj eĉ nur speguli) 40+gbps tute ne estas bagatela.
Post tio, vespere, restis nenio farenda ol reveni al la supozo de stranga filtrado ie supre.
Mi rigardis tra kiu IX la trafiko al la MRG-retoj nun pasas kaj simple nuligis la bgp-sesiojn al ĝi. Kaj — jen! - ĉio tuj revenis al normalo 🙁
Unuflanke, estas domaĝe, ke la tuta tago estis pasigita serĉante la problemon, kvankam ĝi estis solvita en kvin minutoj.
Aliflanke:
— en mia memoro tio estas senprecedenca afero. Kiel mi jam skribis supre - IX vere ne utilas filtri transitan trafikon. Ili kutime havas centojn da gigabitoj/terabitoj je sekundo. Mi simple ne povis serioze imagi ion tian ĝis antaŭ nelonge.
— nekredeble bonŝanca koincido de cirkonstancoj: nova kompleksa aparataro, kiu ne estas precipe fidinda kaj de kiu ne klaras, kio povas esti atendita — adaptita specife por blokado de rimedoj, inkluzive de TCP RST-oj
La NOC de ĉi tiu interreta interŝanĝo nuntempe serĉas problemon. Laŭ ili (kaj mi kredas ilin), ili ne havas iun speciale deplojitan filtran sistemon. Sed, dank' al la ĉielo, la plua serĉado ne plu estas nia problemo :)
Ĉi tio estis eta provo pravigi min, bonvolu kompreni kaj pardoni :)
PS: Mi intence ne nomas la fabrikiston de DPI/NAT aŭ IX (fakte, mi eĉ ne havas specialajn plendojn pri ili, la ĉefa afero estas kompreni kio ĝi estis)
La hodiaŭa (same kiel la hieraŭa kaj antaŭhieraŭ) realaĵo el la vidpunkto de interreta provizanto
Mi pasigis la lastajn semajnojn signife rekonstruante la kernon de la reto, farante amason da manipuladoj "por profito", kun la risko signife influi vivan uzanttrafikon. Konsiderante la celojn, rezultojn kaj konsekvencojn de ĉio ĉi, morale ĉio estas sufiĉe malfacila. Precipe - denove aŭskultante belajn paroladojn pri protektado de stabileco de Runet, suvereneco ktp. kaj tiel plu.
En ĉi tiu sekcio, mi provos priskribi la "evoluadon" de la reto-kerno de tipa ISP dum la lastaj dek jaroj.
Antaŭ dek jaroj.
En tiuj benitaj tempoj, la kerno de provizanta reto povus esti tiel simpla kaj fidinda kiel trafikŝtopiĝo:
En ĉi tiu tre, tre simpligita bildo, ne estas trunkoj, ringoj, ip/mpls-vojigo.
Ĝia esenco estas, ke uzanttrafiko finfine venis al la kernnivela ŝanĝado - de kie ĝi iris , de kie, kiel regulo, reen al la kerna ŝanĝado, kaj tiam "eksteren" - tra unu aŭ pluraj landlimaj enirejoj al Interreto.
Tia skemo estas tre, tre facile rezervebla kaj sur L3 (dinamika enrutado) kaj sur L2 (MPLS).
Vi povas instali N+1 de io ajn: aliri servilojn, ŝaltilojn, randojn - kaj iel aŭ alian rezervu ilin por aŭtomata malsukceso.
Post kelkaj jaroj Evidentiĝis al ĉiuj en Rusio, ke estas neeble vivi tiel plu: urĝis protekti infanojn kontraŭ la malutila influo de Interreto.
Urĝa bezono trovi manierojn filtri uzanttrafikon.
Estas malsamaj aliroj ĉi tie.
En ne tre bona kazo, io estas metita "en la breĉon": inter uzanttrafiko kaj Interreto. La trafiko pasanta tra ĉi tiu "io" estas analizita kaj, ekzemple, falsa pako kun alidirektilo estas sendita al la abonanto.
En iom pli bona kazo - se trafikvolumoj permesas - vi povas fari malgrandan lertaĵon per viaj oreloj: sendu por filtrado nur trafikon devenanta de uzantoj nur al tiuj adresoj, kiuj devas esti filtritaj (por fari tion, vi povas aŭ preni la IP-adresojn). specifita tie de la registro, aŭ aldone solvi ekzistantajn domajnojn en la registro).
Iam, por ĉi tiuj celoj, mi skribis simplan - kvankam mi eĉ ne kuraĝas nomi lin tiel. Ĝi estas tre simpla kaj ne tre produktiva - tamen ĝi permesis al ni kaj al dekoj (se ne centoj) da aliaj provizantoj ne tuj elspezi milionojn por industriaj DPI-sistemoj, sed donis plurajn pliajn jarojn da tempo.
Cetere, pri la tiama kaj nuna DPICetere, multaj, kiuj aĉetis la DPI-sistemojn disponeblajn en la merkato tiutempe, jam forĵetis ilin. Nu, ili ne estas destinitaj por ĉi tio: centoj da miloj da adresoj, dekoj da miloj da URL-oj.
Kaj samtempe enlandaj produktantoj tre forte altiĝis al ĉi tiu merkato. Mi ne parolas pri la aparataro - ĉio estas klara por ĉiuj ĉi tie, sed la programaro - la ĉefa afero, kiun havas DPI - eble hodiaŭ, se ne la plej progresinta en la mondo, tiam certe a) evoluas laŭpaŝe, kaj b) je la prezo de skatolita produkto - simple nekomparebla kun eksterlandaj konkurantoj.
Mi ŝatus esti fiera, sed iom malĝoja =)
Nun ĉio aspektis jene:
Post kelkaj pliaj jaroj ĉiuj jam havis revizorojn; Estis pli kaj pli da rimedoj en la registro. Por iuj pli malnovaj ekipaĵoj (ekzemple, Cisco 7600), la "flanka filtrado" skemo simple iĝis neaplikebla: la nombro da itineroj sur 76 platformoj estas limigita al io kiel naŭcent mil, dum la nombro de IPv4-vojoj sole hodiaŭ alproksimiĝas al 800. mil. Kaj se ĝi ankaŭ estas ipv6... Kaj ankaŭ... kiom estas? 900000 individuaj adresoj en la malpermeso de RKN? =)
Iu ŝanĝis al skemo kun spegulado de la tuta spina trafiko al filtra servilo, kiu devus analizi la tutan fluon kaj, se io malbona estas trovita, sendu RST ambaŭdirekte (sendanto kaj ricevanto).
Tamen, ju pli da trafiko, des malpli aplikeblas ĉi tiu skemo. Se estas la plej eta prokrasto en la prilaborado, la spegula trafiko simple flugos nerimarkite, kaj la provizanto ricevos bonan raporton.
Pli kaj pli da provizantoj estas devigitaj instali DPI-sistemojn de diversaj gradoj de fidindeco tra aŭtovojoj.
Antaŭ unu aŭ du jaroj laŭ onidiroj, preskaŭ ĉiuj FSB komencis postuli la realan instaladon de ekipaĵo (antaŭe, la plej multaj provizantoj administris kun aprobo de la aŭtoritatoj SORM-plano - plano de operaciaj rimedoj en kazo de bezono trovi ion ie)
Krom mono (ne ĝuste troa, sed ankoraŭ milionoj), SORM postulis multajn pliajn manipuladojn kun la reto.
- SORM bezonas vidi "grizajn" uzant-adresojn antaŭ nat-traduko
- SORM havas limigitan nombron da retaj interfacoj
Tial, precipe, ni devis multe rekonstrui pecon de la kerno - simple por kolekti uzanttrafikon al la alirserviloj ie en unu loko. Por speguli ĝin en SORM kun pluraj ligiloj.
Tio estas, tre simpligita, ĝi estis (maldekstre) vs iĝis (dekstre):
Nun Plej multaj provizantoj ankaŭ postulas la efektivigon de SORM-3 - kiu inkluzivas, interalie, protokolon de nat-elsendoj.
Por ĉi tiuj celoj, ni ankaŭ devis aldoni apartajn ekipaĵojn por NAT al la supra diagramo (ĝuste tion, kio estas diskutita en la unua parto). Krome, aldonu en certa ordo: ĉar SORM devas "vidi" la trafikon antaŭ traduki adresojn, la trafiko devas iri strikte jene: uzantoj -> ŝanĝado, kerno -> alirserviloj -> SORM -> NAT -> ŝanĝado, kerno - > Interreto. Por fari tion, ni devis laŭvorte "turni" trafikfluojn en la alia direkto por profito, kio ankaŭ estis sufiĉe malfacila.
En resumo: dum la lastaj dek jaroj, la kerndezajno de averaĝa provizanto multfoje pli kompleksa, kaj pliaj punktoj de fiasko (kaj en formo de ekipaĵo kaj en formo de unuopaj ŝanĝlinioj) signife pliiĝis. Efektive, la postulo mem "vidi ĉion" implicas redukti ĉi tiun "ĉion" al unu punkto.
Mi pensas, ke tio povas esti sufiĉe travideble eksterpolita al nunaj iniciatoj por suverenigi la Runet, protekti ĝin, stabiligi ĝin kaj plibonigi ĝin :)
Kaj Jarovaja ankoraŭ antaŭeniras.
fonto: www.habr.com