Намайг энэ нийтлэлд өдөөсөн .
Би эндээс иш татлаа:
Өнөөдөр 18:53 цагт
Өнөөдөр би үйлчилгээ үзүүлэгчдээ сэтгэл хангалуун байсан. Сайтыг хаах системийг шинэчлэхтэй зэрэгцэн түүний mail.ru хаягийг хориглосон байна.Би өглөөнөөс хойш техникийн дэмжлэг рүү залгасан боловч тэд юу ч хийж чадахгүй. Үйлчилгээ үзүүлэгч нь жижиг бөгөөд өндөр зэрэглэлийн үйлчилгээ үзүүлэгчид үүнийг блоклодог бололтой. Би бас бүх сайтуудын нээлт удааширч байгааг анзаарсан, магадгүй тэд ямар нэгэн муруй DLP суулгасан байх? Өмнө нь нэвтрэхэд асуудал гардаггүй байсан. RuNet-ийн сүйрэл миний нүдний өмнө болж байна ...
Үнэн хэрэгтээ бид ижил үйлчилгээ үзүүлэгч юм шиг санагдаж байна :)
Тэгээд үнэхээр, Би mail.ru-тай холбоотой асуудлын шалтгааныг бараг л таамаглаж байсан (хэдийгээр бид ийм зүйлд удаан хугацаагаар итгэхээс татгалзсан).
Дараахь зүйлийг хоёр хэсэгт хуваана.
- mail.ru-тай холбоотой бидний одоогийн асуудлын шалтгаан, тэдгээрийг олох сонирхолтой эрэл хайгуул
- Өнөөгийн бодит байдалд ISP оршин тогтнох, тусгаар тогтносон RuNet-ийн тогтвортой байдал.
Mail.ru-д хандах хандалтын асуудал
Өө, энэ их урт түүх юм.
Баримт нь улсын шаардлагыг хэрэгжүүлэхийн тулд (хоёр дахь хэсэгт илүү дэлгэрэнгүй) бид хориотой нөөцийг шүүх, хэрэгжүүлэхийн тулд зарим тоног төхөөрөмжийг худалдаж авсан, тохируулж, суурилуулсан. захиалагчид.
Хэсэг хугацааны өмнө бид сүлжээний цөмийг дахин бүтээж, бүх захиалагчийн урсгал энэ төхөөрөмжөөр яг зөв чиглэлд дамждаг.
Хэдэн өдрийн өмнө бид үүн дээр хориглосон шүүлтүүрийг асаасан (хуучин системийг ажиллуулах явцад) - бүх зүйл сайхан болсон юм шиг санагдлаа.
Дараа нь тэд аажмаар захиалагчдын янз бүрийн хэсэгт энэ төхөөрөмж дээр NAT-г идэвхжүүлж эхлэв. Гаднаас нь харахад бүх зүйл сайхан болсон юм шиг санагдсан.
Гэвч өнөөдөр захиалагчдын дараагийн хэсэгт төхөөрөмжид NAT-ыг идэвхжүүлснээр өглөөнөөс эхлэн бид ашиглах боломжгүй эсвэл хэсэгчлэн ашиглах боломжтой гэсэн хангалттай тооны гомдолтой тулгарсан. болон бусад Mail Ru группын нөөц.
Тэд шалгаж эхлэв: хаа нэгтээ юм заримдаа, үе үе илгээдэг зөвхөн mail.ru сүлжээнд илгээсэн хүсэлтийн хариуд. Түүнээс гадна, энэ нь буруу үүсгэсэн (ACK-гүй) хиймэл TCP RST илгээдэг. Энэ нь иймэрхүү харагдаж байв:
Мэдээжийн хэрэг, анхны бодлууд нь шинэ тоног төхөөрөмжийн тухай байсан: аймшигтай DPI, үүнд итгэхгүй байна, энэ нь юу хийж чадахыг та хэзээ ч мэдэхгүй - эцэст нь TCP RST нь хаах хэрэгслүүдийн дунд нэлээд түгээмэл зүйл юм.
Таамаглал Бид ч бас хэн нэгэн “дээд” шүүж байна гэсэн санааг дэвшүүлж байсан ч шууд хаясан.
Нэгдүгээрт, бид ийм зовлон зүдгүүрт орохгүйн тулд хангалттай эрүүл саруул холболттой :)
Хоёрдугаарт, бид хэд хэдэн хүмүүстэй холбогдсон Москвад байдаг бөгөөд mail.ru руу чиглэсэн траффик нь тэднээр дамждаг бөгөөд тэд траффикийг шүүх үүрэг хариуцлага эсвэл өөр шалтгаангүй байдаг.
Өдрийн дараагийн хагасыг ихэвчлэн бөө мөргөл гэж нэрлэдэг зүйлд зарцуулсан - тоног төхөөрөмж борлуулагчийн хамт бид тэдэнд баярлалаа, тэд бууж өгөөгүй :)
- шүүлтүүрийг бүрэн идэвхгүй болгосон
- Шинэ схемийг ашиглан NAT-г идэвхгүй болгосон
- туршилтын компьютерийг тусдаа тусгаарлагдсан усан санд байрлуулсан
- IP хаяг өөрчлөгдсөн
Үдээс хойш байнгын хэрэглэгчийн схемийн дагуу сүлжээнд холбогдсон виртуал машиныг хуваарилж, борлуулагчийн төлөөлөгчдөд түүнд болон тоног төхөөрөмжид хандах эрхийг олгосон. Бөө мөргөл үргэлжилсээр :)
Эцэст нь худалдагчийн төлөөлөгч техник хангамж нь үүнтэй ямар ч холбоогүй гэж итгэлтэйгээр мэдэгдэв: эхнийх нь хаа нэгтээ өндөр газраас ирдэг.
тайлбарЭнэ үед хэн нэгэн ингэж хэлж магадгүй юм: гэхдээ туршилтын компьютерээс биш, харин DPI дээрх хурдны замаас хогийн цэг авах нь илүү хялбар байсан уу?
Үгүй ээ, харамсалтай нь 40+gbps хурдыг авах нь тийм ч энгийн зүйл биш юм.
Үүний дараа оройн цагаар хаа нэгтээ хачин шүүлтүүрийн таамаглал руу буцахаас өөр хийх зүйл үлдсэнгүй.
Би MRG сүлжээнүүдийн траффик аль IX-ээр дамжин өнгөрч байгааг харж, түүн рүү хийх bgp сессийг зүгээр л цуцалсан. Тэгээд - харагтун! - тэр даруй бүх зүйл хэвийн болсон 🙁
Нэг талаас, таван минутын дотор шийдэгдсэн ч бүтэн өдөржин асуудлыг хайж өнгөрөөсөн нь харамсалтай.
Нөгөө талаас:
- Миний санах ойд энэ бол урьд өмнө байгаагүй зүйл юм. Би дээр бичсэнчлэн - IX Үнэхээр дамжин өнгөрөх урсгалыг шүүх ямар ч утгагүй. Тэд ихэвчлэн секундэд хэдэн зуун гигабит/терабиттэй байдаг. Би саяхныг хүртэл ийм зүйлийг төсөөлж ч чадахгүй байсан.
- Нөхцөл байдлын гайхалтай азтай давхцал: тийм ч их итгэдэггүй, юу хүлээж болох нь тодорхойгүй шинэ цогц техник хангамж - TCP RST гэх мэт нөөцийг блоклоход тусгайлан зориулсан.
Энэ интернэт биржийн ҮОХ одоогоор асуудал хайж байна. Тэдний хэлснээр (би тэдэнд итгэж байна) тэдэнд тусгайлан байрлуулсан шүүлтүүрийн систем байдаггүй. Гэхдээ, тэнгэрт баярлалаа, цаашдын эрэл хайгуул нь бидний асуудал байхаа больсон :)
Энэ бол өөрийгөө зөвтгөх гэсэн өчүүхэн оролдлого байсан тул ойлгож уучлаарай :)
P.S.: Би DPI/NAT эсвэл IX үйлдвэрлэгчийг зориудаар нэрлэхгүй байна (үнэндээ би тэдний талаар ямар нэгэн онцгой гомдол байдаггүй, гол зүйл бол энэ нь юу болохыг ойлгох явдал юм)
Интернет үйлчилгээ үзүүлэгчийн үүднээс өнөөдрийн (мөн өчигдрийн болон өмнөх өдрийн) бодит байдал
Би сүүлийн долоо хоногуудыг сүлжээний гол цөмийг дахин бүтээхэд зарцуулж, хэрэглэгчийн шууд урсгалд ихээхэн нөлөөлөх эрсдэлтэй "ашгийн төлөө" олон тооны заль мэх хийсэн. Энэ бүхний зорилго, үр дүн, үр дагаврыг авч үзвэл ёс суртахууны хувьд бүх зүйл нэлээд хэцүү байдаг. Ялангуяа - Рунетийн тогтвортой байдал, тусгаар тогтнол гэх мэтийг хамгаалах тухай сайхан яриаг дахин сонсох. гэх мэт.
Энэ хэсэгт би сүүлийн 10 жилийн хугацаанд ердийн ISP-ийн сүлжээний үндсэн "хувьслыг" тайлбарлахыг хичээх болно.
Арван жилийн өмнө.
Тэрхүү адислагдсан цаг үед үйлчилгээ үзүүлэгчийн сүлжээний цөм нь түгжрэл шиг энгийн бөгөөд найдвартай байж болох юм.
Энэ маш хялбаршуулсан зураг дээр цахилгаан шатны хонгил, цагираг, ip/mpls чиглүүлэлт байхгүй.
Үүний мөн чанар нь хэрэглэгчийн траффик нь эцсийн дүндээ цөмийн түвшний сэлгэн залгахад хүрч ирсэн явдал юм. , хаанаас, дүрмээр бол энэ нь үндсэн шилжүүлэлт рүү буцаж, дараа нь "гарц руу" - нэг буюу хэд хэдэн хилийн гарцаар интернетэд ордог.
Ийм схемийг L3 (динамик чиглүүлэлт) болон L2 (MPLS) дээр хоёуланг нь нөөцлөхөд маш хялбар байдаг.
Та N+1-ийг суулгаж болно: сервер, унтраалга, хил хязгаар, мөн автоматаар шилжүүлэлт хийх зорилгоор тэдгээрийг нөөцлөх боломжтой.
Хэдэн жилийн дараа Цаашид ингэж амьдрах боломжгүй гэдэг нь Орост бүх хүмүүст тодорхой болсон: хүүхдүүдийг интернетийн хор хөнөөлтэй нөлөөллөөс хамгаалах нь яаралтай байв.
Хэрэглэгчийн урсгалыг шүүх арга замыг яаралтай хайх шаардлагатай байсан.
Энд янз бүрийн арга барилууд байдаг.
Тийм ч сайн биш тохиолдолд хэрэглэгчийн траффик ба интернетийн хооронд ямар нэг зүйл "зоорхойд" тавигддаг. Энэ "ямар нэгэн зүйл" -ээр дамжин өнгөрөх урсгалыг шинжилж, жишээлбэл, дахин чиглүүлэлт бүхий хуурамч пакетыг захиалагч руу илгээдэг.
Бага зэрэг илүү сайн тохиолдолд - хэрэв замын хөдөлгөөний хэмжээ зөвшөөрвөл та чихээрээ жижиг заль мэхийг хийж болно: зөвхөн хэрэглэгчээс ирж буй траффикийг шүүх шаардлагатай хаягууд руу илгээнэ үү (үүнийг хийхийн тулд та IP хаягуудыг авч болно. Бүртгэлээс тэнд зааж өгсөн, эсвэл бүртгэлд байгаа домэйнүүдийг нэмж шийдвэрлэх).
Нэгэн цагт эдгээр зорилгоор би энгийн бичсэн - Хэдийгээр би түүнийг ингэж дуудаж зүрхлэхгүй байна. Энэ нь маш энгийн бөгөөд тийм ч бүтээмжтэй биш боловч энэ нь бидэнд болон бусад олон арван (хэдэн зуун биш бол) үйлчилгээ үзүүлэгчдэд үйлдвэрлэлийн DPI системүүд дээр сая саяыг нэн даруй гаргахгүй байх боломжийг олгосон боловч нэмэлт хэдэн жилийн хугацаа өгсөн.
Дашрамд хэлэхэд, тухайн үеийн болон одоогийн DPI-ийн тухайДашрамд хэлэхэд, тэр үед зах зээл дээр байсан DPI системийг худалдаж авсан олон хүмүүс тэдгээрийг аль хэдийн хаясан байв. За, тэд үүнд зориулагдаагүй: хэдэн зуун мянган хаяг, хэдэн арван мянган URL.
Үүний зэрэгцээ дотоодын үйлдвэрлэгчид энэ зах зээлд маш хүчтэй өссөн. Би техник хангамжийн бүрэлдэхүүн хэсгийн талаар яриагүй байна - энд бүх зүйл ойлгомжтой, гэхдээ програм хангамж - DPI-д байгаа гол зүйл бол өнөөдөр магадгүй дэлхийн хамгийн дэвшилтэт биш юм аа, мэдээжийн хэрэг a) үсрэлт, хязгаараар хөгжиж байна, б) хайрцагласан бүтээгдэхүүний үнээр - гадаадын өрсөлдөгчидтэй зүйрлэшгүй.
Би бахархмаар байна, гэхдээ жаахан гунигтай =)
Одоо бүх зүйл иймэрхүү харагдаж байв:
Дахиад хэдэн жилийн дараа хүн бүр аудиторуудтай байсан; Бүртгэлд илүү олон нөөц байсан. Зарим хуучин тоног төхөөрөмжийн хувьд (жишээлбэл, Cisco 7600) "хажуугийн шүүлтүүр" схемийг ашиглах боломжгүй болсон: 76 платформ дээрх маршрутын тоо есөн зуун мянгаар хязгаарлагддаг бол өнөөдөр IPv4 чиглүүлэлтийн тоо 800-д хүрч байна. мянга. Хэрэв энэ нь бас ipv6 бол ... Мөн түүнчлэн ... хэд байгаа вэ? RKN хоригт 900000 хувь хүний хаяг? =)
Хэн нэгэн бүх урсгалыг бүхэлд нь задлан шинжилж, хэрэв ямар нэг муу зүйл олдвол RST-ийг хоёр чиглэлд (илгээгч ба хүлээн авагч) илгээх ёстой шүүлтүүрийн сервер рүү бүх үндсэн урсгалыг тусгах схемд шилжсэн.
Гэхдээ замын хөдөлгөөн их байх тусам энэ схемийг ашиглах боломжгүй болно. Боловсруулалтад бага зэрэг саатал гарсан тохиолдолд толин тусгалтай урсгал зүгээр л анзаарагдахгүй өнгөрөх бөгөөд үйлчилгээ үзүүлэгч торгуулийн тайлан хүлээн авах болно.
Илүү олон үйлчилгээ үзүүлэгчид хурдны замд янз бүрийн түвшний найдвартай DPI системийг суурилуулахаас өөр аргагүй болж байна.
Нэг, хоёр жилийн өмнө цуу ярианы дагуу бараг бүх FSB тоног төхөөрөмж суурилуулахыг шаардаж эхэлсэн (өмнө нь ихэнх үйлчилгээ үзүүлэгчид эрх баригчдын зөвшөөрлөөр удирддаг байсан SORM төлөвлөгөө - хаа нэгтээ ямар нэг зүйл хайх шаардлагатай тохиолдолд авах арга хэмжээний төлөвлөгөө)
Мөнгөөөс гадна (ямар ч их биш, гэхдээ сая сая) SORM нь сүлжээнд илүү олон заль мэхийг шаарддаг.
- SORM нь nat орчуулгын өмнө "саарал" хэрэглэгчийн хаягийг харах шаардлагатай
- SORM нь хязгаарлагдмал тооны сүлжээний интерфейстэй
Тиймээс, ялангуяа бид нэг газраас хаа нэгтээ нэвтрэх серверүүд рүү хэрэглэгчийн урсгалыг цуглуулахын тулд цөмийн нэг хэсгийг их хэмжээгээр дахин бүтээх шаардлагатай болсон. Үүнийг хэд хэдэн холбоосоор SORM-д тусгах зорилгоор.
Энэ нь маш хялбаршуулсан, энэ нь (зүүн) vs болсон (баруун):
Одоо Ихэнх үйлчилгээ үзүүлэгчид SORM-3-ийг хэрэгжүүлэхийг шаарддаг бөгөөд үүнд бусад зүйлсийн дотор nat нэвтрүүлгийг бүртгэх багтдаг.
Эдгээр зорилгын үүднээс бид дээрх диаграммд NAT-д зориулсан тусдаа төхөөрөмжийг нэмж оруулах шаардлагатай болсон (яг эхний хэсэгт дурдсан зүйл). Нэмж хэлэхэд, тодорхой дарааллаар нэмнэ үү: SORM нь хаягийг орчуулахаас өмнө траффикийг "харах" ёстой тул траффик нь дараах байдлаар явах ёстой: хэрэглэгчид -> шилжих, цөм -> хандалтын сервер -> SORM -> NAT -> шилжих, цөм - > Интернет. Үүнийг хийхийн тулд бид ашиг олохын тулд замын хөдөлгөөний урсгалыг нөгөө чиглэлд "эргүүлэх" шаардлагатай болсон бөгөөд энэ нь бас хэцүү байсан.
Дүгнэж хэлэхэд: Сүүлийн арван жилийн хугацаанд дундаж үйлчилгээ үзүүлэгчийн үндсэн загвар нь хэд дахин илүү төвөгтэй болж, эвдрэлийн нэмэлт цэгүүд (тоног төхөөрөмж болон нэг сэлгэн залгах шугам хэлбэрээр) ихээхэн нэмэгдсэн. Үнэндээ "бүх зүйлийг харах" гэсэн шаардлага нь энэ "бүх зүйлийг" нэг цэг болгон багасгахыг хэлдэг.
Үүнийг Рунетийг бүрэн эрхт болгох, хамгаалах, тогтворжуулах, сайжруулах одоогийн санаачилгад нэлээд ил тод тайлбарлаж болно гэж би бодож байна :)
Яровая одоо ч түрүүлж байна.
Эх сурвалж: www.habr.com