Më nxiti për këtë postim .
Unë e citoj këtu:
sot në orën 18:53
Unë isha i kënaqur me ofruesin sot. Së bashku me përditësimin e sistemit të bllokimit të faqes, mail.ru i tij u ndalua. Unë kam telefonuar mbështetje teknike që në mëngjes, por ata nuk mund të bëjnë asgjë. Ofruesi është i vogël dhe me sa duket ofruesit e rangut më të lartë e bllokojnë atë. Vura re gjithashtu një ngadalësim në hapjen e të gjitha faqeve, mbase ata instaluan një lloj DLP të shtrembër? Më parë nuk kishte probleme me aksesin. Shkatërrimi i RuNet po ndodh para syve të mi...
Fakti është se duket se ne jemi i njëjti ofrues :)
Dhe vërtet, Unë pothuajse hamendësova shkakun e problemeve me mail.ru (megjithëse ne refuzuam të besojmë në një gjë të tillë për një kohë të gjatë).
Ajo që vijon do të ndahet në dy pjesë:
- arsyet e problemeve tona aktuale me mail.ru dhe kërkimi emocionues për t'i gjetur ato
- ekzistenca e ISP në realitetet e sotme, stabiliteti i RuNet sovran.
Probleme të aksesueshmërisë me mail.ru
Oh, është një histori mjaft e gjatë.
Fakti është se për të zbatuar kërkesat e shtetit (më shumë detaje në pjesën e dytë), ne blemë, konfiguruam dhe instaluam disa pajisje - si për filtrimin e burimeve të ndaluara ashtu edhe për zbatimin abonentë.
Disa kohë më parë, më në fund rindërtuam bërthamën e rrjetit në atë mënyrë që i gjithë trafiku i pajtimtarëve të kalonte përmes kësaj pajisjeje në mënyrë rigoroze në drejtimin e duhur.
Disa ditë më parë aktivizuam filtrimin e ndaluar në të (ndërsa e lamë sistemin e vjetër të funksiononte) - gjithçka dukej se po shkonte mirë.
Më pas, ata gradualisht filluan të aktivizojnë NAT në këtë pajisje për pjesë të ndryshme të pajtimtarëve. Nga pamja e saj, gjithçka dukej se po shkonte mirë.
Por sot, pasi kemi aktivizuar NAT në pajisjet për pjesën tjetër të abonentëve, që në mëngjes u përballëm me një numër të mirë ankesash për mosdisponueshmëri ose disponueshmëri të pjesshme. dhe burime të tjera të Grupit Mail Ru.
Filluan të kontrollonin: diçka diku иногда, herë pas here dërgon në përgjigje të kërkesave ekskluzivisht për rrjetet mail.ru. Për më tepër, ai dërgon një TCP RST të krijuar gabimisht (pa ACK), padyshim artificial. Kështu dukej:
Natyrisht, mendimet e para ishin për pajisjet e reja: DPI e tmerrshme, pa besim në të, nuk e dini kurrë se çfarë mund të bëjë - në fund të fundit, TCP RST është një gjë mjaft e zakonshme midis mjeteve bllokuese.
Supozimi Ne gjithashtu shtruam idenë se dikush "superior" po filtron, por e hodhëm menjëherë.
Së pari, ne kemi lidhje mjaft të arsyeshme në mënyrë që të mos vuajmë kështu :)
Së dyti, ne jemi të lidhur me disa në Moskë, dhe trafiku në mail.ru kalon përmes tyre - dhe ata nuk kanë as përgjegjësi dhe as ndonjë motiv tjetër për të filtruar trafikun.
Gjysma tjetër e ditës u shpenzua në atë që zakonisht quhet shamanizëm - së bashku me shitësin e pajisjeve, për të cilën i falënderojmë, ata nuk u dorëzuan :)
- filtrimi u çaktivizua plotësisht
- NAT u çaktivizua duke përdorur skemën e re
- PC-ja e testimit u vendos në një pishinë të veçantë të izoluar
- Adresimi IP ndryshoi
Pasdite u nda një makinë virtuale që lidhej me rrjetin sipas skemës së një përdoruesi të rregullt dhe përfaqësuesve të shitësit iu dha akses në të dhe në pajisje. Shamanizmi vazhdoi :)
Në fund, përfaqësuesi i shitësit deklaroi me besim se pajisja nuk kishte të bënte absolutisht me të: të parët vijnë nga diku më i lartë.
ShënimNë këtë pikë, dikush mund të thotë: por ishte shumë më e lehtë për të marrë një hale jo nga kompjuteri testues, por nga autostrada mbi DPI?
Jo, për fat të keq, të marrësh një hale (dhe madje thjesht të pasqyrosh) 40+gbps nuk është aspak e parëndësishme.
Pas kësaj, në mbrëmje, nuk mbetej gjë tjetër veçse të ktheheshim në supozimin e filtrimit të çuditshëm diku më lart.
Shikova përmes cilës IX trafiku drejt rrjeteve MRG tani po kalon dhe thjesht anulova seancat bgp për të. Dhe - ja dhe ja! - gjithçka u kthye menjëherë në normalitet 🙁
Nga njëra anë, është turp që e gjithë dita kaloi në kërkim të problemit, megjithëse u zgjidh në pesë minuta.
Nga ana tjetër:
- në kujtesën time kjo është një gjë e paprecedentë. Siç kam shkruar tashmë më lart - IX vërtet nuk ka asnjë pikë në filtrimin e trafikut transit. Zakonisht kanë qindra gigabit/terabit për sekondë. Unë thjesht nuk mund ta imagjinoja seriozisht diçka të tillë deri vonë.
— një rastësi tepër fatlume e rrethanave: një harduer i ri kompleks që nuk besohet veçanërisht dhe nga i cili nuk është e qartë se çfarë mund të pritet — i përshtatur posaçërisht për bllokimin e burimeve, duke përfshirë TCP RST
KOK i këtij shkëmbimi interneti është aktualisht në kërkim të një problemi. Sipas tyre (dhe unë i besoj), ata nuk kanë ndonjë sistem filtrimi të vendosur posaçërisht. Por, faleminderit qiell, kërkimi i mëtejshëm nuk është më problemi ynë :)
Kjo ishte një përpjekje e vogël për të justifikuar veten, ju lutem kuptoni dhe falni :)
PS: Unë qëllimisht nuk e përmend prodhuesin e DPI/NAT ose IX (në fakt, nuk kam as ndonjë ankesë të veçantë për to, gjëja kryesore është të kuptojmë se çfarë ishte)
Realiteti i sotëm (si dhe i djeshëm dhe i pardjeshëm) nga këndvështrimi i një ofruesi të internetit
I kam kaluar javët e fundit duke rindërtuar ndjeshëm thelbin e rrjetit, duke kryer një sërë manipulimesh “për fitim”, me rrezikun që të ndikojë ndjeshëm në trafikun e përdoruesve të drejtpërdrejtë. Duke marrë parasysh qëllimet, rezultatet dhe pasojat e gjithë kësaj, moralisht gjithçka është mjaft e vështirë. Sidomos - duke dëgjuar edhe një herë fjalime të bukura për mbrojtjen e stabilitetit të Runetit, sovranitetit, etj. e kështu me radhë.
Në këtë seksion, unë do të përpiqem të përshkruaj "evolucionin" e bërthamës së rrjetit të një ISP tipike gjatë dhjetë viteve të fundit.
Dhjetë vjet më parë.
Në ato kohë të bekuara, thelbi i një rrjeti ofruesi mund të jetë po aq i thjeshtë dhe i besueshëm sa një bllokim trafiku:
Në këtë foto shumë, shumë të thjeshtuar, nuk ka trunk, unaza, rrugëzim ip/mpls.
Thelbi i tij është që trafiku i përdoruesve përfundimisht erdhi në ndërrimin e nivelit të kernelit - nga ku shkoi në , nga ku, si rregull, kthehet në kalimin bazë, dhe më pas "jashtë" - përmes një ose më shumë portave kufitare në internet.
Një skemë e tillë është shumë, shumë e lehtë për t'u rezervuar si në L3 (drejtim dinamik) ashtu edhe në L2 (MPLS).
Ju mund të instaloni N+1 të çdo gjëje: aksesoni serverët, çelësat, kufijtë - dhe në një mënyrë ose në një tjetër t'i rezervoni ato për dështim automatik.
Pas disa vitesh U bë e qartë për të gjithë në Rusi se ishte e pamundur të jetosh më kështu: ishte urgjente të mbroheshin fëmijët nga ndikimi shkatërrues i Internetit.
Kishte një nevojë urgjente për të gjetur 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 vihet "në hendek": midis trafikut të përdoruesve dhe internetit. Trafiku që kalon përmes kësaj "diçkaje" analizohet dhe, për shembull, një paketë e rreme me një ridrejtim dërgohet drejt pajtimtarit.
Në një rast pak më të mirë - nëse vëllimet e trafikut ju lejojnë - mund të bëni një mashtrim të vogël me veshët tuaj: dërgoni për filtrim vetëm trafikun me origjinë nga përdoruesit vetëm në ato adresa që duhen filtruar (për ta bërë këtë, mund të merrni ose adresat IP të specifikuara atje nga regjistri, ose zgjidhin gjithashtu domenet ekzistuese në regjistër).
Në një kohë, për këto qëllime, kam shkruar një të thjeshtë - edhe pse as që guxoj ta quaj kështu. Është shumë e thjeshtë dhe jo shumë produktive - megjithatë, na lejoi ne dhe dhjetëra (nëse jo qindra) ofrues të tjerë të mos shpenzonim menjëherë miliona në sistemet industriale DPI, por na dha disa vite shtesë kohë.
Nga rruga, në lidhje me DPI-në e atëhershme dhe aktualeNga rruga, shumë që blenë sistemet DPI të disponueshme në treg në atë kohë, i kishin hedhur tashmë ato. Epo, ato nuk janë krijuar për këtë: qindra mijëra adresa, dhjetëra mijëra URL.
Dhe në të njëjtën kohë, prodhuesit vendas janë ngritur shumë fuqishëm në këtë treg. Nuk po flas për komponentin e harduerit - gjithçka është e qartë për të gjithë këtu, por softueri - gjëja kryesore që ka DPI - është ndoshta sot, nëse jo më i avancuari në botë, atëherë sigurisht a) zhvillohet me hapa të mëdhenj, dhe b) me çmimin e një produkti në kuti - thjesht i pakrahasueshëm me konkurrentët e huaj.
Do të doja të jem krenare, por pak e trishtuar =)
Tani gjithçka dukej kështu:
Në disa vite të tjera të gjithë kishin tashmë auditorë; Në regjistër kishte gjithnjë e më shumë burime. Për disa pajisje më të vjetra (për shembull, Cisco 7600), skema e "filtrimit anësor" thjesht u bë e pazbatueshme: numri i rrugëve në 76 platforma është i kufizuar në rreth nëntëqind mijë, ndërsa numri i rrugëve IPv4 vetëm sot po i afrohet 800. mijë. Dhe nëse është gjithashtu ipv6... Dhe gjithashtu... sa ka? 900000 adresa individuale në ndalimin e RKN-së? =)
Dikush kaloi në një skemë me pasqyrimin e të gjithë trafikut të shtyllës kurrizore në një server filtrues, i cili duhet të analizojë të gjithë rrjedhën dhe, nëse gjendet diçka e keqe, të dërgojë RST në të dy drejtimet (dërguesi dhe marrësi).
Megjithatë, sa më shumë trafik, aq më pak e zbatueshme është kjo skemë. Nëse ka vonesën më të vogël në përpunim, trafiku i pasqyruar thjesht do të fluturojë pa u vënë re dhe ofruesi do të marrë një raport të mirë.
Gjithnjë e më shumë ofrues detyrohen të instalojnë sisteme DPI të shkallëve të ndryshme të besueshmërisë nëpër autostrada.
Një apo dy vjet më parë sipas thashethemeve, pothuajse e gjithë FSB filloi të kërkojë instalimin aktual të pajisjeve (më parë, shumica e ofruesve menaxhoheshin me miratim nga autoritetet plani SORM - një plan masash operacionale në rast nevoje për të gjetur diçka diku)
Përveç parave (jo saktësisht të tepruara, por ende miliona), SORM kërkonte shumë më tepër manipulime me rrjetin.
- SORM duhet të shohë adresat e përdoruesve "gri" përpara përkthimit nat
- SORM ka një numër të kufizuar ndërfaqesh rrjeti
Prandaj, në veçanti, ne duhej të rindërtonim shumë një pjesë të kernelit - thjesht për të mbledhur trafikun e përdoruesve në serverët e aksesit diku në një vend. Për ta pasqyruar atë në SORM me disa lidhje.
Kjo do të thotë, shumë e thjeshtuar, ishte (majtas) vs u bë (djathtas):
Tani Shumica e ofruesve kërkojnë gjithashtu zbatimin e SORM-3 - i cili përfshin, ndër të tjera, regjistrimin e transmetimeve nat.
Për këto qëllime, ne gjithashtu duhej të shtonim pajisje të veçanta për NAT në diagramin e mësipërm (pikërisht ajo që diskutohet në pjesën e parë). Për më tepër, shtoni në një rend të caktuar: meqenëse SORM duhet të "shohë" trafikun përpara se të përkthejë adresat, trafiku duhet të shkojë rreptësisht si më poshtë: përdoruesit -> ndërrimi, kerneli -> aksesi serverët -> SORM -> NAT -> ndërrimi, kernel - > Internet. Për ta bërë këtë, ne duhet të "kthejmë" fjalë për fjalë flukset e trafikut në drejtimin tjetër për fitim, gjë që ishte gjithashtu mjaft e vështirë.
Si përmbledhje: gjatë dhjetë viteve të fundit, dizajni bazë i një ofruesi mesatar është bërë shumë herë më i ndërlikuar dhe pikat shtesë të dështimit (si në formën e pajisjeve ashtu edhe në formën e linjave të vetme komutuese) janë rritur ndjeshëm. Në fakt, vetë kërkesa për të "shikuar gjithçka" nënkupton reduktimin e kësaj "gjithçkaje" në një pikë.
Unë mendoj se kjo mund të ekstrapolohet në mënyrë transparente ndaj iniciativave aktuale për të sovranizuar Runetin, për ta mbrojtur atë, për ta stabilizuar dhe për ta përmirësuar :)
Dhe Yarovaya është ende përpara.
Burimi: www.habr.com