Një përgjigje e zgjeruar ndaj komentit, si dhe pak për jetën e ofruesve në RF

Më inspiroi të shkruaj këtë postim ky koment këtu.

Po e sjell këtu:

kaleman 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ë, kaleman 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ë:

1. arsyet e problemeve tona të sotme me mail.ru dhe një aventurë emocionuese për t'i gjetur ato
2. 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 NAT-translacioneve 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 mail.ru dhe burimeve të tjera të Mail Ru Group.

Filluam të kontrollojmë: diçka diku ndonjëherë, rrallë dërgon TCP RST 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 kaleman 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 IX 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ë BNG, 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ë mini-dpi — 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 SORM (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