Jibu la kina kwa maoni, na pia kidogo juu ya maisha ya watoa huduma katika Shirikisho la Urusi

Alinihimiza kwa chapisho hili hii ndio maoni.

Ninanukuu hapa:

kaleman leo saa 18:53

Nimefurahishwa na mtoa huduma leo. Pamoja na sasisho la mfumo wa kuzuia tovuti, barua pepe yake ilipigwa marufuku. Nimekuwa nikiita usaidizi wa kiufundi tangu asubuhi, lakini hawawezi kufanya chochote. Mtoa huduma ni mdogo, na inaonekana watoa huduma wa ngazi ya juu huzuia. Pia niliona kushuka kwa ufunguzi wa tovuti zote, labda waliweka aina fulani ya DLP iliyopotoka? Hapo awali hakukuwa na matatizo na upatikanaji. Uharibifu wa RuNet unatokea mbele ya macho yangu ...

Ukweli ni kwamba inaonekana sisi ni mtoaji sawa :)

Na kweli, kaleman Karibu nilikisia sababu ya shida na mail.ru (ingawa tulikataa kuamini kitu kama hicho kwa muda mrefu).

Ifuatayo itagawanywa katika sehemu mbili:

1. sababu za matatizo yetu ya sasa na mail.ru na jitihada ya kusisimua ya kuzipata
2. uwepo wa ISP katika hali halisi ya leo, utulivu wa RuNet huru.

Shida za ufikiaji na mail.ru

Lo, ni hadithi ndefu sana.

Ukweli ni kwamba ili kutekeleza mahitaji ya serikali (maelezo zaidi katika sehemu ya pili), tulinunua, kusanidi, na kusanikisha vifaa vingine - kwa kuchuja rasilimali zilizokatazwa na kutekeleza. Tafsiri za NAT waliojisajili.

Wakati fulani uliopita, hatimaye tulijenga upya msingi wa mtandao kwa njia ambayo trafiki yote ya mteja ilipitia kifaa hiki madhubuti katika mwelekeo sahihi.

Siku chache zilizopita tuliwasha kuchuja marufuku juu yake (wakati wa kuacha mfumo wa zamani ukifanya kazi) - kila kitu kilionekana kuwa sawa.

Ifuatayo, polepole walianza kuwezesha NAT kwenye vifaa hivi kwa sehemu tofauti za waliojiandikisha. Kwa mwonekano wake, kila kitu pia kilionekana kwenda sawa.

Lakini leo, baada ya kuwezesha NAT kwenye vifaa kwa sehemu inayofuata ya waliojiandikisha, tangu asubuhi tulikuwa tunakabiliwa na idadi nzuri ya malalamiko juu ya kutopatikana au kupatikana kwa sehemu. mail.ru na rasilimali nyingine za Mail Ru Group.

Walianza kuangalia: kitu mahali fulani wakati mwingine, mara kwa mara hutuma TCP RST kwa kujibu maombi kwa mitandao ya mail.ru pekee. Zaidi ya hayo, hutuma iliyozalishwa kimakosa (bila ACK), ni wazi TCP RST ya bandia. Hivi ndivyo ilionekana:

Kwa kawaida, mawazo ya kwanza yalikuwa juu ya vifaa vipya: DPI ya kutisha, hakuna imani ndani yake, huwezi kujua nini inaweza kufanya - baada ya yote, TCP RST ni jambo la kawaida kati ya zana za kuzuia.

Dhana kaleman Pia tunatoa wazo kwamba mtu "mkuu" anachuja, lakini akaitupa mara moja.

Kwanza, tunayo viunganishi vya kutosha ili tusiteseke hivi :)

Pili, tumeunganishwa na kadhaa IX huko Moscow, na trafiki kwa mail.ru inawapitia - na hawana majukumu wala nia nyingine yoyote ya kuchuja trafiki.

Nusu iliyofuata ya siku ilitumika kwa kile kinachojulikana kama shamanism - pamoja na muuzaji wa vifaa, ambayo tunawashukuru, hawakukata tamaa :)

• uchujaji umezimwa kabisa
• NAT ilizimwa kwa kutumia mpango mpya
• PC ya mtihani iliwekwa kwenye bwawa tofauti la pekee
• Anwani ya IP imebadilishwa

Wakati wa mchana, mashine ya kawaida ilitengwa ambayo iliunganishwa kwenye mtandao kulingana na mpango wa mtumiaji wa kawaida, na wawakilishi wa muuzaji walipewa upatikanaji wake na vifaa. Shamanism iliendelea :)

Mwishowe, mwakilishi wa muuzaji alisema kwa ujasiri kwamba vifaa havikuwa na uhusiano wowote nayo: rsts hutoka mahali fulani juu.

KumbukaKatika hatua hii, mtu anaweza kusema: lakini ilikuwa rahisi zaidi kuchukua dampo si kutoka kwa PC ya mtihani, lakini kutoka kwenye barabara kuu juu ya DPI?

Hapana, kwa bahati mbaya, kuchukua dampo (na hata kuakisi tu) 40+gbps sio ndogo kabisa.

Baada ya hayo, jioni, hakukuwa na chochote cha kufanya lakini kurudi kwenye dhana ya filtration ya ajabu mahali fulani hapo juu.

Niliangalia ambayo IX trafiki kwa mitandao ya MRG sasa inapita na nikaghairi tu vipindi vya bgp kwake. Na - tazama! - kila kitu kilirudi kawaida 🙁

Kwa upande mmoja, ni aibu kwamba siku nzima ilitumika kutafuta shida, ingawa ilitatuliwa kwa dakika tano.

Kwa upande mwingine:

- katika kumbukumbu yangu hii ni jambo ambalo halijawahi kutokea. Kama nilivyoandika hapo juu - IX kweli hakuna maana katika kuchuja trafiki ya usafiri. Kawaida huwa na mamia ya gigabiti/terabiti kwa sekunde. Sikuweza kufikiria kwa umakini kitu kama hiki hadi hivi majuzi.

- matukio ya bahati mbaya sana ya hali: vifaa vipya ngumu ambavyo haviaminiki hasa na ambayo haijulikani wazi kile kinachoweza kutarajiwa - iliyoundwa mahsusi kwa kuzuia rasilimali, pamoja na TCP RSTs.

NOC ya ubadilishanaji huu wa mtandao inatafuta tatizo kwa sasa. Kulingana na wao (na ninawaamini), hawana mfumo wowote wa kuchuja uliowekwa maalum. Lakini, asante mbingu, hamu zaidi sio shida yetu tena :)

Hili lilikuwa jaribio dogo la kujitetea, tafadhali elewa na usamehe :)

PS: Sijataja kwa makusudi mtengenezaji wa DPI/NAT au IX (kwa kweli, sina hata malalamiko yoyote maalum juu yao, jambo kuu ni kuelewa ni nini)

Ukweli wa leo (na vile vile wa jana na siku moja kabla ya jana) kutoka kwa mtazamo wa mtoa huduma wa mtandao.

Nimetumia wiki zilizopita kwa kiasi kikubwa kujenga upya msingi wa mtandao, nikifanya rundo la udanganyifu "kwa faida", na hatari ya kuathiri kwa kiasi kikubwa trafiki ya watumiaji wa moja kwa moja. Kuzingatia malengo, matokeo na matokeo ya haya yote, kwa maadili yote ni ngumu sana. Hasa - kwa mara nyingine tena kusikiliza hotuba nzuri kuhusu kulinda utulivu wa Runet, uhuru, nk. Nakadhalika.

Katika sehemu hii, nitajaribu kuelezea "mageuzi" ya msingi wa mtandao wa ISP ya kawaida katika kipindi cha miaka kumi iliyopita.

Miaka kumi iliyopita.

Katika nyakati hizo zilizobarikiwa, msingi wa mtandao wa watoa huduma unaweza kuwa rahisi na wa kuaminika kama msongamano wa magari:

Katika picha hii sana, iliyorahisishwa sana, hakuna vigogo, pete, uelekezaji wa ip/mpls.

Kiini chake ni kwamba trafiki ya watumiaji hatimaye ilifika kwa ubadilishaji wa kiwango cha kernel - kutoka mahali ilipoenda BNG, kutoka ambapo, kama sheria, kurudi kwenye ubadilishaji wa msingi, na kisha "nje" - kupitia lango moja au zaidi la mpaka kwenye Mtandao.

Mpango kama huo ni rahisi sana kuhifadhi kwenye L3 (uelekezaji wa nguvu) na L2 (MPLS).

Unaweza kusakinisha N+1 ya kitu chochote: seva za ufikiaji, swichi, mipaka - na kwa njia moja au nyingine zihifadhi kwa kushindwa kiotomatiki.

Baada ya miaka michache Ikawa wazi kwa kila mtu nchini Urusi kuwa haiwezekani kuishi kama hii tena: ilikuwa ni haraka kuwalinda watoto kutokana na ushawishi mbaya wa mtandao.

Kulikuwa na haja ya haraka ya kutafuta njia za kuchuja trafiki ya watumiaji.

Kuna mbinu tofauti hapa.

Katika hali si nzuri sana, kitu kinawekwa "katika pengo": kati ya trafiki ya mtumiaji na mtandao. Trafiki inayopitia "kitu" hiki inachambuliwa na, kwa mfano, pakiti bandia iliyo na uelekezaji upya inatumwa kwa mteja.

Katika hali bora zaidi - ikiwa idadi ya trafiki inaruhusu - unaweza kufanya hila ndogo kwa masikio yako: tuma kwa kuchuja trafiki tu inayotoka kwa watumiaji tu kwa anwani zile zinazohitaji kuchujwa (ili kufanya hivyo, unaweza kuchukua anwani za IP. iliyoainishwa hapo kutoka kwa sajili, au suluhisha vikoa vilivyopo kwenye sajili).

Wakati mmoja, kwa madhumuni haya, niliandika rahisi dpi ndogo - ingawa sithubutu hata kumwita hivyo. Ni rahisi sana na haizai sana - hata hivyo, ilituruhusu sisi na kadhaa (ikiwa sio mamia) ya watoa huduma wengine kutotoa mamilioni mara moja kwenye mifumo ya DPI ya viwanda, lakini ilitoa miaka kadhaa ya ziada ya muda.

Kwa njia, kuhusu DPI ya wakati huo na ya sasaKwa njia, wengi ambao walinunua mifumo ya DPI inayopatikana kwenye soko wakati huo tayari walikuwa wameitupa. Kweli, hazijaundwa kwa hili: mamia ya maelfu ya anwani, makumi ya maelfu ya URL.

Na wakati huo huo, wazalishaji wa ndani wameongezeka sana kwa soko hili. Sizungumzii juu ya sehemu ya vifaa - kila kitu ni wazi kwa kila mtu hapa, lakini programu - jambo kuu ambalo DPI ina - labda leo, ikiwa sio ya juu zaidi duniani, basi hakika a) kuendeleza kwa kiwango kikubwa na mipaka, na b) kwa bei ya bidhaa iliyo na sanduku - isiyoweza kulinganishwa na washindani wa kigeni.

Ningependa kujivunia, lakini huzuni kidogo =)

Sasa kila kitu kilionekana kama hii:

Katika miaka michache zaidi kila mtu tayari alikuwa na wakaguzi; Kulikuwa na rasilimali zaidi na zaidi katika Usajili. Kwa vifaa vingine vya zamani (kwa mfano, Cisco 7600), mpango wa "kuchuja kando" haukuweza kutumika: idadi ya njia kwenye majukwaa 76 ni mdogo kwa kitu kama laki tisa, wakati idadi ya njia za IPv4 pekee leo inakaribia 800. elfu. Na ikiwa pia ni ipv6 ... Na pia ... ni kiasi gani? Anwani 900000 za mtu binafsi katika marufuku ya RKN? =)

Mtu amebadilisha hadi mpango unaoakisi wa trafiki yote ya mgongo hadi seva ya kuchuja, ambayo inapaswa kuchanganua mtiririko mzima na, ikiwa kuna kitu kibaya, tuma RST pande zote mbili (mtumaji na mpokeaji).

Walakini, kadiri trafiki inavyozidi, ndivyo mpango huu unavyotumika kidogo. Ikiwa kuna ucheleweshaji mdogo zaidi wa usindikaji, trafiki inayoakisiwa itaruka tu bila kutambuliwa, na mtoa huduma atapokea ripoti nzuri.

Watoa huduma zaidi na zaidi wanalazimika kusakinisha mifumo ya DPI ya viwango tofauti vya kutegemewa katika barabara kuu.

Mwaka mmoja au miwili iliyopita kulingana na uvumi, karibu FSB wote walianza kudai ufungaji halisi wa vifaa SORM (hapo awali, watoa huduma wengi walisimamia kwa idhini kutoka kwa mamlaka Mpango wa SORM - mpango wa hatua za uendeshaji katika kesi ya haja ya kupata kitu mahali fulani)

Mbali na pesa (sio kubwa sana, lakini bado mamilioni), SORM ilihitaji udanganyifu mwingi zaidi na mtandao.

• SORM inahitaji kuona anwani za mtumiaji "kijivu" kabla ya tafsiri ya nat
• SORM ina idadi ndogo ya violesura vya mtandao

Kwa hivyo, haswa, ilibidi tujenge tena kipande cha kernel - ili tu kukusanya trafiki ya watumiaji kwenye seva za ufikiaji mahali fulani katika sehemu moja. Ili kuionyesha katika SORM na viungo kadhaa.

Hiyo ni, iliyorahisishwa sana, ilikuwa (kushoto) vs ikawa (kulia):

Sasa Watoa huduma wengi pia wanahitaji utekelezaji wa SORM-3 - ambayo inajumuisha, kati ya mambo mengine, kukata matangazo ya nat.

Kwa madhumuni haya, tulilazimika pia kuongeza vifaa tofauti vya NAT kwenye mchoro hapo juu (haswa kile kinachojadiliwa katika sehemu ya kwanza). Zaidi ya hayo, ongeza kwa mpangilio fulani: kwa kuwa SORM lazima "ione" trafiki kabla ya kutafsiri anwani, trafiki lazima iende madhubuti kama ifuatavyo: watumiaji -> kubadili, kernel -> seva za kufikia -> SORM -> NAT -> kubadili, kernel - > Mtandao. Ili kufanya hivyo, tulilazimika "kugeuza" mtiririko wa trafiki kwa upande mwingine kwa faida, ambayo pia ilikuwa ngumu sana.

Kwa muhtasari: zaidi ya miaka kumi iliyopita, muundo wa msingi wa mtoa huduma wa wastani umekuwa ngumu zaidi mara nyingi, na pointi za ziada za kushindwa (zote kwa namna ya vifaa na kwa njia ya mistari ya kubadili moja) zimeongezeka kwa kiasi kikubwa. Kwa kweli, hitaji la "kuona kila kitu" linamaanisha kupunguza "kila kitu" hadi hatua moja.

Nadhani hii inaweza kutolewa kwa uwazi kwa mipango ya sasa ya kuifanya Runet kuwa huru, kuilinda, kuiimarisha na kuiboresha :)

Na Yarovaya bado iko mbele.

Chanzo: mapenzi.com