Më inspiroi të shkruaj këtë postim .
Po e sjell këtu:
sot në 18:53
Sot mĂ« gĂ«zoi ofruesi. BashkĂ« me pĂ«rditĂ«simin e sistemit pĂ«r bllokimin e faqeve, u bllokua edhe posta mail.ru. QĂ« nga mĂ«ngjesi po e tĂ«rheq mbĂ«shtetje teknike, nuk mund tĂ« bĂ«jnĂ« asgjĂ«. Ofruesi Ă«shtĂ« i vogĂ«l, dhe duket se bllokohen nga ofruesit mĂ« tĂ« lartĂ«. VĂ«rejta gjithashtu ngadalĂ«simin e hapjes sĂ« tĂ« gjitha faqeve, ndoshta kanĂ« vendosur ndonjĂ« DLP tĂ« keqe? MĂ« parĂ« nuk kishte probleme me aksesin. ShkatĂ«rrimi i Runet po ndodh pĂ«rpara syve tĂ« miâŠ
ĂĂ«shtja Ă«shtĂ« se, duket, ne jemi ai ofruesi đ
Dhe në të vërtetë, pothuajse e zgjedha saktë arsyen e problemeve me mail.ru (me gjithë se ne e refuzuam për një kohë të gjatë një gjë të tillë).
Të ardhmen do ta ndaj në dy pjesë:
- arsyet e problemeve tona të sotme me mail.ru dhe një aventurë emocionuese për t'i gjetur ato
- ekzistenca e ISP-ve në realitetet e sotme, stabiliteti i Runetit sovran.
Problemet me aksesin në mail.ru
Oh, kjo është një histori e gjatë.
ĂĂ«shtja Ă«shtĂ« se pĂ«r tĂ« realizuar kĂ«rkesat e shtetit (mĂ« shumĂ« nĂ« pjesĂ«n e dytĂ«) ne kemi blerĂ«, konfiguruar dhe instaluar disa pajisje â si pĂ«r filtrimin e burimeve tĂ« ndaluara, ashtu edhe pĂ«r realizimin e tĂ« abonentĂ«ve.
Disa kohë më parë, ne përfundojmë ndërtimin e qendrës së rrjetit në një mënyrë që të gjitha trafiku i abonentëve kalonte përmes kësaj pajisje plotësisht në drejtimin e nevojshëm.
Disa ditĂ« mĂ« parĂ« e aktivizuam filtrimin e ndaluar (duke lĂ«nĂ« tĂ« funksionojĂ« edhe sistemin e vjetĂ«r) â çdo gjĂ« dukej se kaloi mirĂ«.
MĂ« pas â gradualisht filluam tĂ« aktivizojmĂ« NAT pĂ«r pjesĂ« tĂ« ndryshme tĂ« abonentĂ«ve nĂ« kĂ«tĂ« pajisje. PĂ«r dukjen â gjithashtu, duket se gjithçka shkoi mirĂ«.
Por sot, duke aktivizuar NAT-nĂ« pĂ«r njĂ« pjesĂ« tjetĂ«r tĂ« abonentĂ«ve â qĂ« nga mĂ«ngjesi u pĂ«rballĂ«m me njĂ« numĂ«r tĂ« konsiderueshĂ«m ankesash pĂ«r mosaksesimin ose aksesin e pjesshĂ«m dhe burimeve tĂ« tjera tĂ« Mail Ru Group.
Filluam tĂ« kontrollojmĂ«: diçka diku ndonjĂ«herĂ«, rrallĂ« dĂ«rgon si pĂ«rgjigje ndaj kĂ«rkesave pĂ«r rrjetet mail.ru. MĂ« shumĂ« se kaq â dĂ«rgon njĂ« TCP RST tĂ« gjeneruar gabimisht (pa ACK), qartazi artificial. Diku kĂ«shtu dukej:
Natyrisht, mendimet e para ishin pĂ«r pajisjet e reja: DPI i frikshĂ«m, nuk kishte besim ndaj tij, kush e di se çfarĂ« mund tĂ« ndodhte â sepse TCP RST Ă«shtĂ« njĂ« gjĂ« mjaft e zakonshme midis mjeteve tĂ« bllokimit.
Supozimi se dikush 'lart' po filtrohet, ne gjithashtu e kemi hedhur atĂ« â por menjĂ«herĂ« e hedhĂ«m poshtĂ«.
SĂ« pari, kemi lidhje tĂ« mjaftueshme pĂ«r tĂ« mos vuajtur nga kjo đ
SĂ« dyti, jemi tĂ« lidhur me disa nĂ« MoskĂ«, dhe trafikimi deri te mail.ru kalon pikĂ«risht pĂ«rmes tyre â dhe ata nuk kanĂ« as obligime, as ndonjĂ« motiv tjetĂ«r pĂ«r tĂ« filtruar trafik.
Pjesa tjetĂ«r e ditĂ«s u shpenzua nĂ« atĂ« qĂ« zakonisht quhet shamanizĂ«m â sĂ« bashku me furnizuesin e pajisjeve, pĂ«r tĂ« cilin ju falĂ«nderojmĂ«, nuk e lanĂ« đ
- filtrimi u çaktivizua plotësisht
- NAT u çaktivizua me një skemë të re
- PC-ja testuese u tërhoq në një grup të izoluar
- u ndryshua adresimi IP
NĂ« pjesĂ«n e dytĂ« tĂ« ditĂ«s u caktua njĂ« virtualke, e cila dalĂ« nĂ« rrjet me skemĂ«n e pĂ«rdoruesit standard, dhe edhe asaj dhe pajisjes iu dha akses pĂ«rfaqĂ«suesĂ«ve tĂ« furnizuesit. Shamanizmi vazhdoi đ
Në fund të fundit, përfaqësuesi i furnizuesit deklaroi me siguri se pajisja nuk ka asnjë lidhje: rst'të po vijnë nga ndonjë vend më sipër.
ShënimNë këtë pikë, dikush mund të deklarojë: por ishte më e lehtë të merrje dumpin jo nga PC-ja testuese, por nga magistralja më lart se DPI?
Jo, pĂ«r fat tĂ« keq, tĂ« marrĂ«sh dump (dhe madje thjesht ta mirrorosh) mbi 40+ gbps â nuk Ă«shtĂ« ndonjĂ« gjĂ« e thjeshtĂ«.
Pas kĂ«saj, tashmĂ« mbrĂ«mjen â nuk kishte asnjĂ« opsion tjetĂ«r pĂ«rveçse tĂ« kthehesh nĂ« supozimin e filtrimit tĂ« çuditshĂ«m diku lart.
Shikova pĂ«rmes cilit IX tani kalon trafiku deri nĂ« rrjetet e MRG dhe thjesht fikja seancat bgp pĂ«r tĂ«. Dhe â oh mrekulli! â gjithçka u normalizua menjĂ«herĂ« đ
Nga njĂ«ra anĂ« â Ă«shtĂ« shumĂ« pĂ«r tĂ« ardhur keq qĂ« u shpenzua njĂ« ditĂ« pĂ«r tĂ« gjetur problemin, megjithatĂ«, zgjidhja e tij zgjati vetĂ«m pesĂ« minuta.
Nga ana tjetër:
â nĂ« memorien time, ky Ă«shtĂ« njĂ« rast paprecedent. Siç thashĂ« mĂ« lart â IX'ave vĂ«rtetĂ« nuk ka asnjĂ« kuptim pĂ«r tĂ« filtruar trafikun transit. Ata zakonisht kanĂ« qindra gigabit / terabite nĂ« sekondĂ«. UnĂ« thjesht deri nĂ« fund nuk mund ta imagjinoja diçka tĂ« tillĂ« seriozisht.
â njĂ« rast jashtĂ«zakonisht i suksesshĂ«m: njĂ« pajisje e re komplekse, tĂ« cilĂ«s nuk i besohej shumĂ« dhe nga e cila nuk dihet çfarĂ« mund tĂ« pritet â e cila Ă«shtĂ« e dizajnuar saktĂ«sisht pĂ«r bllokimin e burimeve, duke pĂ«rfshirĂ« TCP RST-tĂ«.
Aktualisht, NOC i kĂ«tij internet exchange Ă«shtĂ« duke kĂ«rkuar pĂ«r problemin. Sipas tyre (dhe unĂ« i besoj), nuk ka ndonjĂ« sistem filtrimi tĂ« veçantĂ« tĂ« instaluar. Por, falĂ« Zotit, aventura e ardhshme â tani nuk Ă«shtĂ« mĂ« problemi ynĂ« đ
Ishte njĂ« pĂ«rpjekje e vogĂ«l pĂ«r t'u justifikuar, lutem kuptoni dhe falni đ
P.S.: qëllimisht nuk po e përmend as prodhuesin e DPI/NAT, as IX (në të vërtetë, nuk kam ndonjë ankesë të veçantë për ta, e rëndësishme është të kuptojmë se çfarë ndodhi)
Realiteti i sotëm (si dhe ai i djeshëm dhe i ante-djeshëm) nga perspektiva e ofruesit të internetit
Java e fundit e kalova duke transformuar ndjeshĂ«m kernelin e rrjetit, duke kryer shumĂ« manipulime "nĂ« jet" me rrezik tĂ« rĂ«ndĂ«sishĂ«m pĂ«r trafik tĂ« gjallĂ« tĂ« pĂ«rdoruesve. Duke marrĂ« parasysh qĂ«llimet, rezultatet dhe pasojat e tĂ« gjithave kĂ«tyre â emocionalisht, gjithçka Ă«shtĂ« mjaft e vĂ«shtirĂ«. Sidomos â duke dĂ«gjuar pĂ«rsĂ«ri fjalime tĂ« bukura rreth mbrojtjes sĂ« stabilitetit tĂ« runet, sovranitetit, etj.
Në këtë seksion do të përpiqem të flas për "evolucionin" e kernelit të rrjetit të një ofruesi tipik të internetit për një dekadë të fundit.
Dhe një dekadë më parë.
Në ato kohë të bekuara, kernel i rrjetit të ofruesit mund të ishte i thjeshtë dhe i besueshëm, si një kork.
Në këtë imazh shumë të thjeshtuar mungojnë magjistrale, unaza, routing ip/mpls.
Thelbi i saj Ă«shtĂ« se trafiku i pĂ«rdoruesve nĂ« fund arrinte nĂ« kthimin e nivelit tĂ« kernelit â prej nga shonte nĂ« , prej nga, zakonisht â prap nĂ« kthimin e kernelit, dhe mĂ« pas "nĂ« dalje" â pĂ«rmes njĂ« ose mĂ« shumĂ« border gateway nĂ« internet.
Një skemë e tillë është shumë-e lehtë për t'u rezervuar si në L3 (nga routing dinamik), ashtu edhe në L2 (MPLS).
Mund tĂ« vendosni N+1 çfarĂ«do: servera aksesit, switch, border â dhe qĂ« si do tĂ« ishte, t'i rezervoni ato pĂ«r failover automatike.
Pas disa vjetësh të gjithëve në Rusi iu bë e qartë se nuk mund të jetojë më kështu: ishte e nevojshme të shpëtoheshin urgent fëmijët nga ndikimi i dëmshëm i rrjetit.
Kishte nevojë urgjente për të kërkuar mënyra për të filtruar trafikun e përdoruesve.
Këtu ka qasje të ndryshme.
NĂ« njĂ« rast jo shumĂ« tĂ« mirĂ« â diçka vendoset "nĂ« thyerje": midis trafikut tĂ« pĂ«rdoruesve dhe internetit. Trafiku qĂ« kalon pĂ«rmes kĂ«tij "diçkaje" i nĂ«nshtrohet analizĂ«s dhe, pĂ«r shembull, dĂ«rgohet njĂ« paketĂ« e rreme me redirekt nĂ« drejtim tĂ« abonentit.
NĂ« njĂ« rast pak mĂ« tĂ« mirĂ« â nĂ«se volumi i trafikut lejon â mund tĂ« bĂ«jmĂ« njĂ« truk tĂ« vogĂ«l: dĂ«rgo vetĂ«m trafikun e dĂ«rguar nga pĂ«rdoruesit pĂ«r filtrim vetĂ«m drejt atyre adresave qĂ« duhen filtruar (pĂ«r kĂ«tĂ«, mund tĂ« marrim adresat IP tĂ« dhĂ«na nga regjistri, ose tĂ« rezolvojmĂ« domene ekzistuese nĂ« regjistĂ«r).
NĂ« kohĂ«n e saj, pĂ«r kĂ«to qĂ«llime unĂ« kam shkruar njĂ« â megjithĂ«se asnjĂ«herĂ« nuk do ta quaja ashtu. Ai Ă«shtĂ« shumĂ« i thjeshtĂ« dhe jo shumĂ« efikas â megjithatĂ«, edhe ne, edhe dhjetĂ«ra (nĂ«se jo qindra) ofrues tĂ« tjerĂ« na lanĂ« pa investuar menjĂ«herĂ« milionat nĂ« sisteme industriale DPI, dhe na dhanĂ« disa vite shtesĂ«.
Dhe pĂ«r t'i pĂ«rmendur, pĂ«r DPI-tĂ« e asaj kohe dhe tĂ« tanishmeDuhet thĂ«nĂ« se shumĂ« nga ata qĂ« blenĂ« sistemet DPI qĂ« ishin nĂ« treg nĂ« atĂ« kohĂ« â tashmĂ« i kanĂ« hequr ato. Ato nuk janĂ« tĂ« dizajnuara pĂ«r diçka tĂ« tillĂ«: qindra mijĂ«ra adresa, dhjetĂ«ra mijĂ«ra URL.
NĂ« tĂ« njĂ«jtĂ«n kohĂ«, prodhuesit vendas u rritĂ«n shumĂ« pĂ«r kĂ«tĂ« treg. Nuk po flas pĂ«r pĂ«rbĂ«rjen harduerike â kĂ«tu gjithçka Ă«shtĂ« e qartĂ«, por softi â gjĂ«ja kryesore qĂ« ka DPI â ndoshta sot Ă«shtĂ«, nĂ«se jo mĂ« e avancuar nĂ« botĂ«, patjetĂ«r a) po zhvillohet me hapa tĂ« mĂ«dhenj dhe b) me çmimin e kutisĂ« â thjesht pa krahasim me konkurrentĂ«t e huaj.
Dëshiroja të krenohesha, por ndiej pak trishtim =)
Tani gjithçka dukej kështu:
Edhe pas disa vjetësh të gjithë kishin revizorë; resurset në regjistër po rriteshin gjithnjë e më shumë. Për disa pajisje të vjetra (p.sh., cisco 7600) skema me "filtrimin nga ana" bëhej thjesht e papërshtatshme: numri i rrugëve në platformat 76 është i kufizuar në rreth nëntëqind mijë, ndërkohë që numri i vetëm IPv4-rugëve sot është afër 800 mijë. Dhe nëse flasim edhe për ipv6⊠E sa janë ajo? 900000 adresa të veçanta në bllokimin e rkn? =)
Disa kaluan në skemën e pasqyrimit të gjithë trafikut të autostradës në një server filtrues, i cili duhet të analizojë të gjithë fluksin dhe, në rast se gjen diçka të keqe, të dërgojë në të dyja anët (dërguesit dhe marrësit) RST.
MegjithatĂ«, sa mĂ« shumĂ« trafik, aq mĂ« pak e pĂ«rshtatshme bĂ«het njĂ« skemĂ« e tillĂ«. NĂ«se ka vonesa tĂ« vogla nĂ« pĂ«rpunim â trafiku i pasqyruar ndoshta do t'i shpĂ«tojĂ« pa u vĂ«nĂ« re, dhe ofruesi do tĂ« marrĂ« njĂ« protokoll pĂ«r njĂ« gjobĂ«.
Një numër gjithnjë e më i madh i ofruesve të shërbimeve është i detyruar të vendosë sisteme DPI me nivele të ndryshme besueshmërie në boshtet e komunikimit.
NjĂ« ose dy vjet mĂ« parĂ« sipas thashethemeve, praktikisht tĂ« gjithĂ« FSB-nĂ« filluan tĂ« kĂ«rkojnĂ« instalimin real tĂ« pajisjeve (mĂ« parĂ« shumica e ofruesve tĂ« shĂ«rbimeve shkonte me miratimin e organeve plani SORM â njĂ« plan veprimi nĂ« rast nevojĂ«s pĂ«r tĂ« gjetur diçka diku)
PĂ«rveç parave (jo se janĂ« krejtĂ«sisht astronomike, por megjithatĂ« â miliona), SORM-i kĂ«rkoi nga shumĂ« njerĂ«z edhe disa manipulime nĂ« rrjet.
- SORM-i duhet të shohë adresat "gri" të përdoruesve, para NAT-imit
- SORM-i ka një numër të kufizuar të ndërfaqeve të rrjetit
Prandaj, nĂ« veçanti, na duhej tĂ« ristrukturojmĂ« njĂ« pjesĂ« tĂ« thelbit â thjesht pĂ«r tĂ« mbledhur diku nĂ« njĂ« vend trafik pĂ«r pĂ«rdoruesit nĂ« serverat e aksesit. NĂ« mĂ«nyrĂ« qĂ« ta pasqyronim atĂ« me disa lidhje nĂ« SORM.
Kështu që, shumë thjesht, ishte (majtas) vs është bërë (djathtas):
Tani te shumica e ofruesve tĂ« shĂ«rbimeve kĂ«rkohet gjithashtu implementimi i SORM-3 â i cili pĂ«rfshin, pĂ«rfshirĂ«, regjistrimin e NAT-imit.
PĂ«r kĂ«to qĂ«llime, nĂ« skemĂ«n e mĂ«sipĂ«rme na duhej tĂ« shtonim gjithashtu pajisje tĂ« veçanta pĂ«r NAT-in (aq sa Ă«shtĂ« çështja qĂ« diskutohet nĂ« pjesĂ«n e parĂ«). Gjithashtu, pĂ«r tĂ« shtuar nĂ« njĂ« rend tĂ« caktuar: sepse SORM-i duhet tĂ« "shohĂ«" trafikun para adresĂ«s sĂ« translacionit â trafiku duhet tĂ« kalojĂ« nĂ« mĂ«nyrĂ« strikte siç pason: pĂ«rdoruesit -> komutimi, thelbi -> serverat e aksesit -> SORM -> NAT -> komutimi, thelbi -> interneti. PĂ«r kĂ«tĂ«, na duhej, nĂ« tĂ« vĂ«rtetĂ«, tĂ« "kthejmĂ«" rrjedhat e trafikut nĂ« anĂ«n tjetĂ«r nĂ« kohĂ« reale, qĂ« gjithashtu ishte mjaft e vĂ«shtirĂ«.
Pra, në përmbledhje: për një dekadë, skema e thelbit të një ofruesi mesatar të shërbimeve është komplikuar shumë, dhe pikat e tjera të dështimit (si përmes pajisjeve, ashtu edhe përmes linjave të komutimit të vetme) janë rritur ndjeshëm. Me të vërtetë, kërkesa për të "parë gjithçka" nënkupton që ky "gjithçka" të përqendrohet në një pikë.
Mendoj se kjo mund tĂ« ekstrapolohet nĂ« iniciativat aktuale pĂ«r sovranizimin e Runet-it, mbrojtjen e tij, stabilizimin dhe pĂ«rmirĂ«simin đ
Dhe përpara është akoma Yarovaya.
Burimi: habr.com
