پاسخ مفصل به نظر و همچنین کمی در مورد زندگی ارائه دهندگان در فدراسیون روسیه

مرا به این پست ترغیب کرد این نظر است.

اینجا نقل می کنم:

کلمن امروز ساعت 18:53

امروز از ارائه دهنده راضی بودم. همراه با آپدیت سیستم انسداد سایت، میلرش mail.ru ممنوع شد از صبح با پشتیبانی فنی تماس گرفتم کاری از دستشون برنمیاد. ارائه دهنده کوچک است و ظاهراً ارائه دهندگان رتبه بالاتر آن را مسدود می کنند. من هم متوجه کاهش سرعت باز شدن همه سایت ها شدم، شاید یک جور DLP کج نصب کرده اند؟ قبلا هیچ مشکلی برای دسترسی وجود نداشت. نابودی RuNet درست جلوی چشمان من اتفاق می افتد ...

واقعیت این است که به نظر می رسد ما همان ارائه دهنده هستیم :)

و در واقع، کلمن من تقریباً علت مشکلات mail.ru را حدس زدم (اگرچه ما برای مدت طولانی از اعتقاد به چنین چیزی خودداری می کردیم).

آنچه در ادامه می آید به دو بخش تقسیم می شود:

1. دلایل مشکلات فعلی ما با mail.ru و تلاش هیجان انگیز برای یافتن آنها
2. وجود ISP در واقعیت های امروزی، ثبات RuNet مستقل.

مشکلات دسترسی با mail.ru

اوه، داستان بسیار طولانی است.

واقعیت این است که برای اجرای الزامات دولت (جزئیات بیشتر در قسمت دوم)، تجهیزاتی را خریداری، پیکربندی و نصب کردیم - هم برای فیلتر کردن منابع ممنوعه و هم برای پیاده سازی ترجمه های NAT مشترکین

چند وقت پیش بالاخره هسته شبکه را به گونه ای بازسازی کردیم که تمام ترافیک مشترکین از طریق این تجهیزات کاملاً در جهت درست عبور کند.

چند روز پیش فیلتر ممنوعه را روی آن روشن کردیم (در حالی که سیستم قدیمی کار می کند) - به نظر می رسید همه چیز خوب پیش می رود.

در مرحله بعد، آنها به تدریج شروع به فعال کردن NAT روی این تجهیزات برای بخش های مختلف مشترکان کردند. از ظاهرش هم به نظر می رسید همه چیز خوب پیش می رفت.

اما امروز با فعال کردن NAT روی تجهیزات برای قسمت بعدی مشترکان، از همان صبح با تعداد قابل توجهی از شکایات در مورد در دسترس نبودن یا در دسترس بودن جزئی مواجه شدیم. mail.ru و سایر منابع Mail Ru Group.

آنها شروع به بررسی کردند: چیزی در جایی گاهی, گاهی اوقات می فرستد TCP RST در پاسخ به درخواست های منحصرا به شبکه های mail.ru. علاوه بر این، یک TCP RST بدیهی مصنوعی تولید شده (بدون ACK) را ارسال می کند. این چیزی بود که به نظر می رسید:

طبیعتاً، اولین افکار در مورد تجهیزات جدید بود: DPI وحشتناک، بدون اعتماد به آن، شما هرگز نمی دانید چه کاری می تواند انجام دهد - بالاخره TCP RST یک چیز نسبتاً رایج در میان ابزارهای مسدود کننده است.

فرض کلمن ما همچنین این ایده را مطرح کردیم که فردی «برتر» در حال فیلتر کردن است، اما بلافاصله آن را کنار گذاشتیم.

اولا، ما به اندازه کافی لینک های آپلود منطقی داریم که مجبور نباشیم اینگونه رنج ببریم :)

ثانیاً ما به چندین وصل هستیم IX در مسکو، و ترافیک به mail.ru از طریق آنها انجام می شود - و آنها نه مسئولیتی دارند و نه انگیزه دیگری برای فیلتر کردن ترافیک.

نیمه بعدی روز صرف چیزی شد که معمولاً شمنیسم نامیده می شود - همراه با فروشنده تجهیزات ، که از آنها تشکر می کنیم ، آنها تسلیم نشدند :)

• فیلترینگ کاملا غیرفعال شد
• NAT با استفاده از طرح جدید غیرفعال شد
• کامپیوتر آزمایشی در یک استخر مجزا قرار داده شد
• آدرس IP تغییر کرد

بعد از ظهر یک ماشین مجازی اختصاص داده شد که طبق طرح یک کاربر معمولی به شبکه متصل شد و نمایندگان فروشنده به آن و تجهیزات دسترسی پیدا کردند. شمنیسم ادامه داشت :)

در پایان، نماینده فروشنده با اطمینان گفت که سخت افزار مطلقاً هیچ ربطی به آن ندارد: rs ها از جایی بالاتر می آیند.

یادداشتدر این مرحله، ممکن است کسی بگوید: اما خیلی راحت‌تر بود که از رایانه آزمایشی، بلکه از بزرگراه بالای DPI تخلیه کنید؟

نه، متأسفانه، گرفتن Dump (و حتی فقط Mirroring) 40 + گیگابیت در ثانیه اصلاً بی اهمیت نیست.

بعد از این، در غروب، چیزی برای انجام دادن باقی نمانده بود جز بازگشت به فرض فیلتراسیون عجیب در جایی بالاتر.

من نگاه کردم که اکنون ترافیک شبکه های MRG از کدام IX عبور می کند و به سادگی جلسات bgp به آن را لغو کردم. و - ببین و ببین! - همه چیز بلافاصله به حالت عادی بازگشت 🙁

از یک طرف، مایه شرمساری است که تمام روز به جستجوی مشکل سپری شد، اگرچه در پنج دقیقه حل شد.

از سوی دیگر:

- در حافظه من این یک چیز بی سابقه است. همانطور که قبلاً در بالا نوشتم - IX واقعا فیلتر کردن ترافیک حمل و نقل فایده ای ندارد. آنها معمولاً صدها گیگابیت/ترابیت در ثانیه دارند. تا همین اواخر نمی توانستم چنین چیزی را به طور جدی تصور کنم.

- تصادف فوق العاده خوش شانسی از شرایط: یک سخت افزار پیچیده جدید که به طور خاص قابل اعتماد نیست و مشخص نیست چه چیزی می توان از آن انتظار داشت - به طور خاص برای مسدود کردن منابع، از جمله TCP RST ها طراحی شده است.

NOC این صرافی اینترنتی در حال حاضر به دنبال مشکل است. به گفته آنها (و من معتقدم) آنها هیچ سیستم فیلتراسیون ویژه ای ندارند. اما، خدا را شکر، تلاش بیشتر دیگر مشکل ما نیست :)

این یک تلاش کوچک برای توجیه خودم بود، لطفا درک کنید و ببخشید :)

PS: من عمداً از سازنده DPI / NAT یا IX نام نمی برم (در واقع ، من حتی شکایت خاصی از آنها ندارم ، نکته اصلی این است که بفهمیم چه چیزی بوده است)

واقعیت امروز (و همچنین دیروز و پریروز) از دیدگاه یک ارائه دهنده اینترنت

من هفته‌های گذشته را به طور قابل‌توجهی صرف بازسازی هسته‌ی شبکه کرده‌ام، و دسته‌ای از دستکاری‌ها را «برای سود» انجام داده‌ام، با این خطر که بر ترافیک کاربر زنده تأثیر قابل‌توجهی بگذارد. با توجه به اهداف، نتایج و پیامدهای همه اینها، از نظر اخلاقی همه چیز بسیار دشوار است. به خصوص - یک بار دیگر گوش دادن به سخنرانی های زیبا در مورد حفاظت از ثبات Runet، حاکمیت و غیره. و غیره

در این بخش، من سعی خواهم کرد "تکامل" هسته شبکه یک ISP معمولی را در ده سال گذشته شرح دهم.

ده سال قبل.

در آن زمان‌های مبارک، هسته یک شبکه ارائه‌دهنده می‌تواند به سادگی و قابل اعتماد بودن یک ترافیک باشد:

در این تصویر بسیار بسیار ساده، هیچ ترانک، حلقه، مسیریابی ip/mpls وجود ندارد.

ماهیت آن این است که ترافیک کاربر در نهایت به سوئیچینگ سطح هسته رسید - از جایی که به آن رفت. BNG، از آنجا، به عنوان یک قاعده، به سوئیچینگ هسته باز می گردد، و سپس "خارج" - از طریق یک یا چند دروازه مرزی به اینترنت.

رزرو چنین طرحی هم در L3 (مسیریابی پویا) و هم در L2 (MPLS) بسیار بسیار آسان است.

می‌توانید N+1 هر چیزی را نصب کنید: به سرورها، سوئیچ‌ها، مرزها دسترسی داشته باشید - و به هر طریقی آنها را برای failover خودکار رزرو کنید.

بعد از چند سال برای همه در روسیه روشن شد که دیگر نمی توان به این شکل زندگی کرد: محافظت از کودکان در برابر نفوذ مخرب اینترنت ضروری است.

نیاز فوری به یافتن راه هایی برای فیلتر کردن ترافیک کاربران وجود داشت.

در اینجا رویکردهای مختلفی وجود دارد.

در یک مورد نه چندان خوب، چیزی "در شکاف" قرار می گیرد: بین ترافیک کاربر و اینترنت. ترافیک عبوری از این "چیزی" تجزیه و تحلیل می شود و به عنوان مثال، یک بسته جعلی با تغییر مسیر به سمت مشترک ارسال می شود.

در حالت کمی بهتر - اگر حجم ترافیک اجازه می دهد - می توانید یک ترفند کوچک با گوش خود انجام دهید: فقط ترافیکی را که از کاربران منشأ می گیرد فقط به آن آدرس هایی که باید فیلتر شوند برای فیلتر کردن بفرستید (برای انجام این کار، می توانید آدرس های IP را انتخاب کنید. در آنجا از رجیستری مشخص شده است، یا دامنه های موجود در رجیستری را نیز حل کنید).

زمانی برای این اهداف ساده نوشتم dpi کوچک - اگرچه من حتی جرات ندارم او را اینطور صدا کنم. این بسیار ساده است و خیلی مولد نیست - با این حال، به ما و ده ها (اگر نه صدها) ارائه دهنده دیگر اجازه داد که فوراً میلیون ها دلار را روی سیستم های DPI صنعتی خرج نکنیم، اما چندین سال دیگر زمان گذاشت.

به هر حال، در مورد DPI آن زمان و فعلیبه هر حال، بسیاری از کسانی که سیستم های DPI موجود در بازار را در آن زمان خریداری کردند، قبلاً آنها را دور انداخته بودند. خوب، آنها برای این طراحی نشده اند: صدها هزار آدرس، ده ها هزار URL.

و در عین حال، تولیدکنندگان داخلی به شدت به این بازار صعود کرده اند. من در مورد مولفه سخت افزاری صحبت نمی کنم - اینجا همه چیز برای همه روشن است، اما نرم افزار - اصلی ترین چیزی که DPI دارد - شاید امروز، اگر پیشرفته ترین در جهان نباشد، مطمئنا الف) با جهش و مرز توسعه می یابد. و ب) به قیمت یک محصول جعبه ای - به سادگی غیر قابل مقایسه با رقبای خارجی.

دوست دارم افتخار کنم اما کمی غمگین =)

حالا همه چیز به این شکل بود:

یکی دو سال دیگر همه قبلاً حسابرسان داشتند. منابع بیشتر و بیشتری در رجیستری وجود داشت. برای برخی تجهیزات قدیمی تر (مثلاً سیسکو 7600)، طرح «فیلتر جانبی» به سادگی غیرقابل اجرا شد: تعداد مسیرها در 76 پلتفرم به چیزی حدود نهصد هزار محدود شده است، در حالی که تعداد مسیرهای IPv4 به تنهایی امروز به 800 رسیده است. هزار و اگر ipv6 هم باشه... و همچنین... چقدر هست؟ 900000 آدرس فردی در ممنوعیت RKN؟ =)

شخصی به طرحی با انعکاس تمام ترافیک ستون فقرات به یک سرور فیلترینگ سوئیچ کرد، که باید کل جریان را تجزیه و تحلیل کند و اگر مورد بدی پیدا شد، RST را در هر دو جهت (فرستنده و گیرنده) ارسال کند.

با این حال، هرچه ترافیک بیشتر باشد، این طرح کمتر قابل اجرا است. اگر کوچکترین تاخیری در پردازش وجود داشته باشد، ترافیک آینه ای به سادگی بدون توجه به پرواز در می آید و ارائه دهنده گزارش خوبی دریافت می کند.

ارائه دهندگان بیشتر و بیشتری مجبور به نصب سیستم های DPI با درجات مختلف اطمینان در سراسر بزرگراه ها می شوند.

یکی دو سال پیش طبق شایعات ، تقریباً تمام FSB شروع به درخواست نصب واقعی تجهیزات کردند SORM (پیش از این، اکثر ارائه دهندگان با تأیید مقامات اداره می شدند طرح SORM - طرح اقدامات عملیاتی در صورت نیاز به یافتن چیزی در جایی)

علاوه بر پول (نه دقیقاً گزاف، اما هنوز میلیون ها)، SORM به دستکاری های بیشتری در شبکه نیاز داشت.

• SORM باید قبل از ترجمه nat آدرس های کاربر "خاکستری" را ببیند
• SORM تعداد محدودی رابط شبکه دارد

بنابراین، به طور خاص، ما مجبور شدیم تا حد زیادی یک قطعه از هسته را بازسازی کنیم - به سادگی به منظور جمع آوری ترافیک کاربر به سرورهای دسترسی در جایی در یک مکان. به منظور منعکس کردن آن در SORM با چندین پیوند.

یعنی بسیار ساده شده بود (چپ) در مقابل تبدیل (راست):

اکنون اکثر ارائه دهندگان همچنین به پیاده سازی SORM-3 نیاز دارند - که شامل موارد دیگر، ثبت گزارش های پخش nat است.

برای این منظور، ما همچنین مجبور شدیم تجهیزات جداگانه ای را برای NAT به نمودار بالا اضافه کنیم (دقیقاً همان چیزی که در قسمت اول بحث شده است). علاوه بر این، به ترتیب خاصی اضافه کنید: از آنجایی که SORM باید قبل از ترجمه آدرس ها، ترافیک را ببیند، ترافیک باید دقیقاً به شرح زیر باشد: کاربران -> سوئیچینگ، هسته -> سرورهای دسترسی -> SORM -> NAT -> سوئیچینگ، هسته - > اینترنت برای انجام این کار، ما مجبور بودیم به معنای واقعی کلمه جریان های ترافیک را برای سود به سمت دیگر "برگردانیم" که این نیز بسیار دشوار بود.

به طور خلاصه: در طول ده سال گذشته، طراحی هسته یک ارائه دهنده متوسط ​​چندین برابر پیچیده تر شده است و نقاط خرابی اضافی (هم در قالب تجهیزات و هم به صورت خطوط سوئیچینگ منفرد) به طور قابل توجهی افزایش یافته است. در واقع، همین الزام برای «دیدن همه چیز» به معنای کاهش این «همه چیز» به یک نقطه است.

من فکر می کنم که این می تواند کاملاً شفاف به ابتکارات فعلی برای حاکمیت Runet، محافظت از آن، تثبیت آن و بهبود آن تعمیم داده شود :)

و یارووایا هنوز جلوتر است.

منبع: www.habr.com