Më nxiti të shkruaj këtë postim .
Po e citoj këtu:
sot në 18:53
Sot më gëzoi ofruesi. Bashkë me përditësimin e sistemit të bllokimit të faqeve, ra nën bllokim edhe posta mail.ru. Që nga mëngjesi po kontaktoj mbështetje teknike, nuk mundin të bëjnë asgjë. Ofruesi është i vogël dhe duket se bllokojnë nga ofruesit më të lartë. Pashë gjithashtu ngadalësim në hapjen e të gjitha faqeve, ndoshta kanë vendosur ndonjë DLP të çrregullt? Nuk kishte probleme me qasjen më parë. Shkatërrimi i runetit po ndodh përpara syve të mi...
E vërteta është se, duket se ne jemi ai ofrues 🙁
Dhe në të vërtetë, gati e kam gjetur shkakun e problemeve me mail.ru (megjithatë ne nuk e besonim këtë për një kohë të gjatë).
Të ardhmen do ta ndaj në dy pjesë:
- shkaqet e problemeve tona të sotme me mail.ru dhe një aventurë tërheqëse për t'i gjetur ato
- ekzistenca e ISP-ve në realitetet e sotme, stabiliteti i runetit sovran.
Problemet me aksesueshmërinë e mail.ru
Oh, kjo është një histori e gjatë.
Çështja është se për realizimin e kërkesave të shtetit (më shumë në pjesën e dytë) kemi blerë, konfiguruar dhe instaluar disa pajisje — si për filtrimin e resurseve të ndaluara, ashtu edhe për realizimin të abonentëve.
Disa kohë më parë, ne përfundimisht ndryshuam thelbin e rrjetit në një mënyrë që gjithë trafiku i abonentëve kalonte përmes kësaj pajisjeje vetëm në drejtimin e duhur.
Para disa ditësh, aktivizuam filtrimin e ndaloar (në të njëjtën kohë duke mbajtur në funksion edhe sistemin e vjetër) — dukshëm gjithçka shkoi mirë.
Më pas — gradualisht filluam të aktivizojmë NAT për pjesë të ndryshme të abonentëve në këtë pajisje. Duket — gjithashtu, gjithçka, siç duket, shkoi mirë.
Por sot, duke aktivizuar NAT 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 papërfshirje ose për një përfshirje të pjesshme dhe burime të tjera nga Mail Ru Group.
Filluam të kontrollonim: diçka diku ndonjëherë, herë pas here dërgon në përgjigje ndaj kërkesave ekskluzivisht për rrjetet mail.ru. Më shumë se kaq — dërgon një TCP RST të gjeneruar gabimisht (pa ACK), qartë të krijuar në mënyrë artificiale. Kështu dukeshin situatat:
Natyrisht, mendimet e para ishin për pajisjet e reja: DPI i frikshëm, asnjë besim ndaj tij, kush e di se çfarë mund të bëjë — sepse TCP RST është një gjë mjaft e zakonshme mes mjeteve të bllokimit.
Supozimi se dikush "në nivel më të lartë" po filtron, e kemi hedhur po ashtu — por e këtë e kemi hedhur menjëherë poshtë.
Së pari, ne kemi lidhje të mjaftueshme për të mos vuajtur nga këto probleme 🙂
Së dyti, jemi lidhur me disa në Moskë, dhe trafiku deri te mail.ru kalon përmes tyre — dhe ata nuk kanë as detyrime, as ndonjë motiv tjetër për të filtruar trafikun.
Pjesa tjetër e ditës u kalua duke bërë atë që zakonisht quhet shamanizëm — së bashku me furnizuesin e pajisjeve, për të cilën i falenderojmë, nuk u braktisëm 🙂
- filtrimi u çaktivizua plotësisht
- NAT u çaktivizua sipas një skeme të re
- PC testues u nxor në një pool të veçantë të izoluar
- IP-adresimi u ndryshua
Në pjesën e dytë të ditës, u ndan një virtual që dilte në rrjet sipas skemës së përdoruesit të zakonshëm, dhe asaj dhe pajisjeve iu dha akses përfaqësuesve të furnizuesit. Shamanizmi vazhdoi 🙂
Në fund të fundit, përfaqësuesi i furnizuesit shpesh deklaroi me besim se pajisja nuk kishte asnjë lidhje: rst`ët vijnë nga diku lart.
ShënimNë këtë pikë dikush mund të tha: por ishte shumë më e lehtë të merrje një dump jo nga kompjuteri testues, por nga magjistralja lart DPI?
Jo, për fat të keq, marrja e një dump-i (dhe madje edhe thjesht mirore) 40+gbps nuk është aspak e thjeshtë.
Pas kësaj, në mbrëmje — nuk kishte asgjë tjetër përveçse të kthehesha në supozimin për një filtrimin të çuditshëm diku lart.
Shihja se përmes cilit IX kalonte tani trafiku deri në rrjetet e MRG dhe thjesht ndalova sesionet bgp ndaj tij. Dhe — o mrekulli! — gjithçka u normalizua menjëherë 🙁
Në njërën anë — është shumë e trishtueshme se gjithë dita u shpenzua për të gjetur problemin, ndonëse u zgjidh për pesë minuta.
Në anën tjetër:
— në kujtimin tim kjo është një gjë pa precedenta. Siç kam shkruar më sipër — IX`at vërtet nuk ka asnjë kuptim të filtrojnë trafikun transit. Ata zakonisht kanë qindra gigabit / terabit në sekondë. Thjesht deri në fund nuk mund të mendoja diçka të tillë seriozisht.
— një rast tejet të mirë: harduer i ri dhe kompleks, për të cilin nuk ka një besim të veçantë dhe është e paqartë se çfarë mund të presim — i projektuar pikërisht për bllokimin e burimeve, duke përfshirë TCP RST.
Aktualisht NOC-i i këtij internet exchange po kërkon për problemin. Sipas deklaratave të tyre (dhe unë i besoj), nuk kanë ndonjë sistem filtrimi të veçantë të vendosur. Por, falë Zotit, misioni i mëtejshëm — nuk është më problemi ynë 🙂
Ishte një përpjekje e vogël për t'u justifikuar, ju lutemi kuptoni dhe falni 🙂
P.S.: Unë qëllimisht nuk e përmend as prodhuesin e DPI/NAT, as IX (nuk kam as ndonjë pretendim të veçantë ndaj tyre, e rëndësishme është të kuptohet se çfarë ndodhi).
Realiteti i sotëm (si dhe ai i djeshëm dhe para djeshëm) nga pikëpamja e ofruesit të internetit.
Java e fundit e kam kaluar duke e ristrukturuar ndjeshëm infrastrukturën e rrjetit, duke bërë shumë manipulime 'në jet' me rrezik për t'u prekur shumë nga trafiku i përdoruesve aktiv. Duke marrë parasysh qëllimet, rezultatet dhe pasojat e gjithë kësaj — moralish është mjaft e vështirë. Sidomos — duke dëgjuar përsëri fjalime të bukura mbi mbrojtjen e stabilitetit të Runet-it, sovranitetin, etj.
Në këtë seksion do të përpiqem të tregoj "evolucionin" e kernelit të rrjetit të një ofruesi tipik të internetit gjatë dekadës së fundit.
Dekadën e kaluar.
Në ato kohë të bekuara, kernel i rrjetit të ofruesit mund të ishte i thjeshtë dhe i besueshëm, si një qepë:
Në këtë pamje shumë të thjeshtuar mungojnë autostradat, unazat, dhe rrugëtimi ip/MPLS.
Thelbi i tij është se trafiku i përdoruesve përfundimisht arrinte në kalimin e nivelit të kernelit — nga ku shkonte në , nga ku, zakonisht — prapa në kalimin e kernelit, dhe më pas "në dalje" — përmes një ose disa gateway-eve kufitare në internet.
Një skemë e tillë është shumë e lehtë për t'u rezervuar si në L3 (rrugëtim dinamik), ashtu edhe në L2 (MPLS).
Mund të vendosni N+1 çfarëdo: serverash akses, switch-e, kufij — dhe kështu ose ndryshe t'i rezervoni ato për një dështim automatik.
Pas disa viteve të gjithë në Rusi kuptuan se kështu nuk mund të jetonin më: ishte e nevojshme të mbronte menjëherë fëmijët nga ndikimi përbindësh të rrjetit.
Doli nevoja për të gjetur urgjentisht mënyra për të filtruar trafikun e përdoruesve.
Këtu janë disa qasje të ndryshme.
Në një rast jo shumë të mirë - diçka vendoset "në të kundërt": midis trafikut të përdoruesve dhe internetit. Trafiku që kalon përmes këtij "diçkaje" analizohet dhe, për shembull, një paketë e rreme me të drejtim dërgohet drejt abonentit.
Në një rast më të mirë - nëse volumi i trafikut e lejon - mund të bëhet një truk i vogël: të dërgohet në filtrimin vetëm trafiku që vjen nga përdoruesit në ato adresa që duhet të filtroren (për këtë mund të përdoren ose IP-të e specifikuara në regjistër, ose mund të bëhet një rezolvim shtesë i domain-eve që janë në regjistër).
Në atë kohë për këto qëllime kam shkruar një – megjithëse as nuk e kam fjalën për ta quajtur kështu. Ai është shumë i thjeshtë dhe jo shumë produktiv – megjithatë, ka lejuar dhe neve, dhe dhjetra (nëse jo qindra) ofrues të tjerë të mos harxhojmë menjëherë miliona për sisteme DPI industriale, dhe na dha disa vite shtesë.
Për të folur për DPI-në e asaj kohe dhe të sotmeDuke e thënë, shumë prej atyre që blejnë sistemet DPI që ishin në treg atëherë, tashmë i kanë hedhur ato. Ato nuk janë përshtatur për diçka të tillë: qindra mijëra adresa, dhjetëra mijëra URL.
Në të njëjtën kohë, prodhuesit vendas u ngritën shumë për këtë treg. Nuk po flas për komponentin harduerik — këtu e kuptojmë të gjithë, por softi — gjëja më e rëndësishme në DPI — ndoshta, sot nëse nuk është më i avancuar në botë, atëherë sigurisht a) po zhvillohet me hapa të mëdha, dhe b) çmimi i kutisë — është thjesht i pa krahasueshëm me konkurrentët e huaj.
Do të doja të krenohem, por është pak e trishtueshme =)
Tani gjithçka dukej kështu:
Edhe pas disa viteve të tjera të gjithë kishin tashmë revizorë; burimet në regjistër po rriteshin gjithnjë e më shumë. Për disa pajisje të vjetra (për shembull, cisco 7600) skema me "filtrimin nga ana" bëhej thjesht e papranueshme: numri i rrugëve në 76 platforma është i kufizuar në rreth nëntëqind mijë, ndërsa numri i rrugëve IPv4 sot po afron në 800 mijë. Dhe nëse shtojmë edhe ipv6... Dhe sa janë ato? 900000 adresa të veçanta në bllokimin RKN? =)
Dikush ka kaluar në një skemë për pasqyrimin e gjithë trafikut të kordonit drejt një serveri filtrues, i cili duhet të analizojë të gjithë fluxin dhe, në rast se ndonjë gjë e keqe gjendet, të dërgojë në të dyja drejtimet (dërguesit dhe marrësit) RST.
Megjithatë, sa më shumë trafik të ketë, aq më pak e aplikueshme është një skemë e tillë. Në rast të vonesës më të vogël në përpunim — trafiku i pasqyruar thjesht do të kalojë pa u vënë re, ndërsa ofruesit do të marrin një protokoll për ndëshkimin.
Gjëra më shumë e më shumë ofruesve janë të detyruar të vendosin sisteme DPI të gradave të ndryshme mbi kordonin.
Dy vite më parë sipas thashethemeve, pothuajse të gjithë FSB-ka kërkuan instalimin real të pajisjeve (më parë shumica e ofruesve e kalonin me miratimin e organeve plani SORM — plani i aktiviteteve operacionale në rast nevoje për të gjetur diçka diku)
Përveç parave (nuk ishin aq shumë, por megjithatë — miliona), SORM për shumë kërkoi manipulime të reja me rrjetin.
- SORMe duhet të shohë adresat "gri" të përdoruesve, para nat-translacionit
- SORMe ka një numër të kufizuar të ndërfaqeve rrjetësore
Prandaj, na duhej të riorganizojmë pjesë të bërthamës — thjesht për të grumbulluar ndonjëherë në një vend trafikun e përdoruesve drejt serverëve të aksesit. Kjo për të pasqyruar atë në SORM me disa lidhje.
Pra, shumë thjesht, ishte (majtas) vs tani është (djathtas):
Tani tek shumica e ofruesve kërkohet gjithashtu implementimi i SORM-3 — i cili përfshin, përveç kësaj, edhe regjistrimin e NAT-translacioneve.
Për këto qëllime, në skemën e mësipërme duhej të shtonim gjithashtu një pajisje të veçantë për NAT-in (pikërisht ajo që po flitet në pjesën e parë). Dhe duhej të shtohet në një rend të caktuar: pasi SORM duhet të "shohë" trafikun para translacioneve të adresave — trafiku duhet të kalojë pikërisht në këtë mënyrë: përdoruesit -> komutimi, bërthama -> serverët e aksesit -> SORM -> NAT -> komutimi, bërthama -> interneti. Për këtë na duhej, në fakt, të "kthenim" rrjedhat e trafikut në anën tjetër në kohë reale, gjë që ishte gjithashtu mjaft e vështirë.
Si gjithçka është përkeqësuar, ndërlikimi i skemës së bërthamës së ofruesve të mesëm është rritur shumë gjatë një dekade të fundit, dhe pikat e dështimit (si në formën e materialeve ashtu edhe në atë të linjave të vetme të rrjeteve) janë rritur ndjeshëm. Në vetvete, kërkesa për "të parë gjithçka" nënkupton konsolidimin e këtij "gjithçka" në një pikë.
Mendoj se kjo mund të ekstrapolohet në iniciativat aktuale për sovranizimin e Runet, mbrojtjen, stabilizimin dhe përmirësimin e tij 🙂
Dhe përpara është edhe Yarovaya.
Burimi: habr.com
