مجھے اس پوسٹ کی طرف اشارہ کیا۔ .
میں اسے یہاں نقل کرتا ہوں:
آج 18:53 پر
میں آج فراہم کنندہ سے خوش تھا۔ سائٹ بلاکنگ سسٹم کو اپ ڈیٹ کرنے کے ساتھ ساتھ اس کے میلر mail.ru پر پابندی لگا دی گئی۔میں صبح سے ٹیکنیکل سپورٹ کو کال کر رہا ہوں، لیکن وہ کچھ نہیں کر سکتے۔ فراہم کنندہ چھوٹا ہے، اور بظاہر اعلیٰ درجہ کے فراہم کنندگان اسے روکتے ہیں۔ میں نے تمام سائٹس کے کھلنے میں سست روی بھی دیکھی، شاید انہوں نے کسی قسم کی ٹیڑھی ڈی ایل پی انسٹال کی ہو؟ پہلے رسائی میں کوئی مسئلہ نہیں تھا۔ RuNet کی تباہی میری آنکھوں کے سامنے ہو رہی ہے...
حقیقت یہ ہے کہ ایسا لگتا ہے کہ ہم وہی فراہم کنندہ ہیں :)
اور واقعی، میں نے تقریبا mail.ru کے ساتھ مسائل کی وجہ کا اندازہ لگایا تھا (حالانکہ ہم نے ایک طویل عرصے سے ایسی چیز پر یقین کرنے سے انکار کر دیا تھا)۔
مندرجہ ذیل کو دو حصوں میں تقسیم کیا جائے گا:
- mail.ru کے ساتھ ہمارے موجودہ مسائل کی وجوہات اور انہیں تلاش کرنے کی دلچسپ جستجو
- آج کی حقیقتوں میں ISP کا وجود، خودمختار RuNet کا استحکام۔
mail.ru کے ساتھ رسائی کے مسائل
اوہ، یہ کافی لمبی کہانی ہے۔
حقیقت یہ ہے کہ ریاست کی ضروریات کو لاگو کرنے کے لیے (مزید تفصیلات دوسرے حصے میں)، ہم نے ممنوعہ وسائل کو فلٹر کرنے اور لاگو کرنے کے لیے کچھ آلات خریدے، ترتیب دی اور انسٹال کیے۔ سبسکرائبرز
کچھ عرصہ پہلے، ہم نے بالآخر نیٹ ورک کور کو اس طرح سے دوبارہ بنایا کہ تمام صارفین کی ٹریفک اس آلات سے درست سمت میں سختی سے گزرے۔
کچھ دن پہلے ہم نے اس پر ممنوعہ فلٹرنگ کو آن کیا (پرانے سسٹم کو کام کرنے کے دوران) - سب کچھ ٹھیک چل رہا تھا۔
اس کے بعد، انہوں نے آہستہ آہستہ صارفین کے مختلف حصوں کے لیے اس آلات پر NAT کو فعال کرنا شروع کیا۔ اس کی نظر سے بھی سب کچھ ٹھیک لگ رہا تھا۔
لیکن آج، سبسکرائبرز کے اگلے حصے کے لیے آلات پر NAT کو فعال کرنے کے بعد، صبح سے ہی ہمیں عدم دستیابی یا جزوی دستیابی کے بارے میں کافی شکایات کا سامنا کرنا پڑا۔ اور میل آر یو گروپ کے دیگر وسائل۔
وہ چیک کرنے لگے: کہیں کچھ کبھی کبھی, کبھی کبھار بھیجتا ہے خصوصی طور پر mail.ru نیٹ ورکس کی درخواستوں کے جواب میں۔ مزید یہ کہ، یہ غلط طریقے سے تیار کردہ (ACK کے بغیر) بھیجتا ہے، ظاہر ہے مصنوعی TCP RST۔ یہ ایسا ہی نظر آتا تھا:
قدرتی طور پر، پہلے خیالات نئے آلات کے بارے میں تھے: خوفناک DPI، اس پر کوئی بھروسہ نہیں، آپ کبھی نہیں جانتے کہ یہ کیا کر سکتا ہے - سب کے بعد، TCP RST بلاک کرنے والے ٹولز میں کافی عام چیز ہے۔
مفروضہ ہم نے یہ خیال بھی پیش کیا کہ کوئی "برتر" فلٹر کر رہا ہے، لیکن اسے فوراً رد کر دیا۔
سب سے پہلے، ہمارے پاس کافی سمجھدار اپ لنکس ہیں تاکہ ہمیں اس طرح کا نقصان نہ اٹھانا پڑے :)
دوم، ہم متعدد سے جڑے ہوئے ہیں۔ ماسکو میں، اور mail.ru پر ٹریفک ان سے گزرتی ہے - اور ان کے پاس ٹریفک کو فلٹر کرنے کی نہ تو ذمہ داریاں ہیں اور نہ ہی کوئی دوسرا مقصد۔
دن کا اگلا آدھا حصہ اس پر صرف کیا گیا جسے عام طور پر شمنزم کہا جاتا ہے - سامان فروش کے ساتھ، جس کے لیے ہم ان کا شکریہ ادا کرتے ہیں، انہوں نے ہمت نہیں ہاری :)
- فلٹرنگ مکمل طور پر غیر فعال تھی۔
- نئی سکیم کا استعمال کرتے ہوئے NAT کو غیر فعال کر دیا گیا تھا۔
- ٹیسٹ پی سی کو الگ الگ الگ پول میں رکھا گیا تھا۔
- IP ایڈریسنگ تبدیل کر دی گئی۔
دوپہر میں، ایک ورچوئل مشین مختص کی گئی تھی جو ایک باقاعدہ صارف کی اسکیم کے مطابق نیٹ ورک سے جڑی ہوئی تھی، اور وینڈر کے نمائندوں کو اس تک اور آلات تک رسائی دی گئی تھی۔ شمن پرستی جاری رہی :)
آخر میں، وینڈر کے نمائندے نے اعتماد کے ساتھ بتایا کہ ہارڈ ویئر کا اس سے قطعاً کوئی تعلق نہیں ہے: rsts کہیں اونچی جگہ سے آتے ہیں۔
نوٹاس مقام پر، کوئی کہہ سکتا ہے: لیکن ٹیسٹ پی سی سے نہیں بلکہ ڈی پی آئی کے اوپر کی شاہراہ سے ڈمپ لینا بہت آسان تھا؟
نہیں۔
اس کے بعد شام کو کچھ نہیں بچا سوائے اوپر کے عجیب فلٹریشن کے گمان میں واپسی کے۔
میں نے دیکھا کہ ایم آر جی نیٹ ورکس کی ٹریفک اب کس IX سے گزر رہی ہے اور بس اس پر ہونے والے bgp سیشنز کو منسوخ کر دیا ہے۔ اور - دیکھو اور دیکھو! - سب کچھ فوری طور پر معمول پر آگیا 🙁
ایک طرف، یہ شرم کی بات ہے کہ سارا دن مسئلہ کی تلاش میں صرف کیا گیا، حالانکہ یہ پانچ منٹ میں حل ہو گیا تھا۔
دوسری جانب:
- میری یاد میں یہ ایک بے مثال چیز ہے۔ جیسا کہ میں نے اوپر لکھا ہے - IX واقعی ٹرانزٹ ٹریفک کو فلٹر کرنے کا کوئی فائدہ نہیں ہے۔ ان کے پاس عام طور پر سینکڑوں گیگا بٹس/ٹیرابائٹس فی سیکنڈ ہوتے ہیں۔ میں ابھی تک سنجیدگی سے اس طرح کی کسی چیز کا تصور بھی نہیں کرسکتا تھا۔
- حالات کا ایک ناقابل یقین حد تک خوش قسمتی کا اتفاق: ایک نیا پیچیدہ ہارڈ ویئر جس پر خاص طور پر بھروسہ نہیں ہے اور جس سے یہ واضح نہیں ہے کہ کیا توقع کی جا سکتی ہے — خاص طور پر TCP RSTs سمیت وسائل کو روکنے کے لیے تیار کیا گیا ہے۔
اس انٹرنیٹ ایکسچینج کا NOC فی الحال ایک مسئلہ تلاش کر رہا ہے۔ ان کے مطابق (اور میں ان پر یقین کرتا ہوں)، ان کے پاس فلٹریشن کا کوئی خاص نظام نہیں ہے۔ لیکن، آسمان کا شکریہ، مزید تلاش اب ہمارا مسئلہ نہیں ہے :)
یہ اپنے آپ کو درست ثابت کرنے کی ایک چھوٹی سی کوشش تھی، برائے مہربانی سمجھ کر معاف کر دیں :)
PS: میں جان بوجھ کر DPI/NAT یا IX بنانے والے کا نام نہیں لیتا (حقیقت میں، مجھے ان کے بارے میں کوئی خاص شکایت بھی نہیں ہے، اصل بات یہ سمجھنا ہے کہ یہ کیا تھا)
انٹرنیٹ فراہم کرنے والے کے نقطہ نظر سے آج کی (نیز کل کی اور پرسوں کی) حقیقت
میں نے پچھلے ہفتے نیٹ ورک کے بنیادی حصے کو دوبارہ تعمیر کرنے میں صرف کیے ہیں، "منافع کے لیے" بہت ساری ہیرا پھیری کرتے ہوئے، لائیو صارف ٹریفک کو نمایاں طور پر متاثر کرنے کے خطرے کے ساتھ۔ اس سب کے مقاصد، نتائج اور نتائج کو مدنظر رکھتے ہوئے اخلاقی طور پر یہ سب کافی مشکل ہے۔ خاص طور پر - ایک بار پھر رنیٹ کے استحکام، خودمختاری، وغیرہ کے تحفظ کے بارے میں خوبصورت تقریریں سننا۔ اور اسی طرح.
اس حصے میں، میں پچھلے دس سالوں میں ایک عام ISP کے نیٹ ورک کور کے "ارتقاء" کو بیان کرنے کی کوشش کروں گا۔
دس سال پہلے۔
ان بابرکت اوقات میں، فراہم کنندہ نیٹ ورک کا بنیادی حصہ ٹریفک جام کی طرح سادہ اور قابل اعتماد ہو سکتا ہے:
اس بہت، بہت آسان تصویر میں، کوئی تنوں، حلقے، ip/mpls روٹنگ نہیں ہیں۔
اس کا خلاصہ یہ ہے کہ صارف ٹریفک بالآخر کرنل لیول سوئچنگ پر آیا - جہاں سے یہ گیا ، جہاں سے، ایک اصول کے طور پر، واپس کور سوئچنگ پر، اور پھر "آؤٹ" - انٹرنیٹ کے ایک یا زیادہ بارڈر گیٹ ویز کے ذریعے۔
اس طرح کی اسکیم L3 (متحرک روٹنگ) اور L2 (MPLS) دونوں پر محفوظ کرنا بہت آسان ہے۔
آپ کسی بھی چیز کا N+1 انسٹال کر سکتے ہیں: رسائی سرورز، سوئچز، بارڈرز - اور کسی نہ کسی طریقے سے انہیں خودکار فیل اوور کے لیے محفوظ رکھیں۔
چند سالوں کے بعد یہ بات روس میں ہر کسی پر واضح ہو گئی کہ اب اس طرح رہنا ناممکن ہے: بچوں کو انٹرنیٹ کے مضر اثرات سے بچانا ضروری ہے۔
صارف ٹریفک کو فلٹر کرنے کے طریقے تلاش کرنے کی فوری ضرورت تھی۔
یہاں مختلف طریقے ہیں۔
ایک بہت اچھی صورت میں، کچھ "خلا میں" ڈال دیا جاتا ہے: صارف ٹریفک اور انٹرنیٹ کے درمیان. اس "کچھ" سے گزرنے والی ٹریفک کا تجزیہ کیا جاتا ہے اور، مثال کے طور پر، ری ڈائریکٹ کے ساتھ ایک جعلی پیکٹ سبسکرائبر کی طرف بھیجا جاتا ہے۔
قدرے بہتر صورت میں - اگر ٹریفک کا حجم اجازت دیتا ہے تو - آپ اپنے کانوں سے ایک چھوٹی سی چال کر سکتے ہیں: صرف صارفین سے آنے والی ٹریفک کو فلٹر کرنے کے لیے صرف ان پتوں پر بھیجیں جن کو فلٹر کرنے کی ضرورت ہے (ایسا کرنے کے لیے، آپ یا تو IP ایڈریس لے سکتے ہیں۔ وہاں رجسٹری سے مخصوص کیا گیا ہے، یا اس کے علاوہ رجسٹری میں موجود ڈومینز کو حل کریں)۔
ایک زمانے میں، ان مقاصد کے لیے، میں نے ایک سادہ سا لکھا - حالانکہ میں اسے فون کرنے کی ہمت بھی نہیں کرتا۔ یہ بہت آسان ہے اور بہت زیادہ نتیجہ خیز نہیں ہے - تاہم، اس نے ہمیں اور درجنوں (اگر سینکڑوں نہیں) دوسرے فراہم کنندگان کو صنعتی DPI سسٹمز پر فوری طور پر لاکھوں کا استعمال نہ کرنے کی اجازت دی، لیکن کئی اضافی سال کا وقت دیا۔
ویسے اس وقت اور موجودہ ڈی پی آئی کے بارے میںویسے، بہت سے جنہوں نے اس وقت مارکیٹ میں دستیاب DPI سسٹم خریدے تھے، انہیں پہلے ہی پھینک چکے تھے۔ ٹھیک ہے، وہ اس کے لیے ڈیزائن نہیں کیے گئے ہیں: سیکڑوں ہزاروں پتے، دسیوں ہزار یو آر ایل۔
اور اسی وقت، گھریلو پروڈیوسرز اس مارکیٹ میں بہت مضبوطی سے بڑھے ہیں۔ میں ہارڈ ویئر کے اجزاء کے بارے میں بات نہیں کر رہا ہوں - یہاں سب کے لئے سب کچھ واضح ہے، لیکن سافٹ ویئر - اہم چیز جو DPI کے پاس ہے - شاید آج، اگر دنیا میں سب سے زیادہ ترقی یافتہ نہیں ہے، تو یقینا a) چھلانگ لگا کر ترقی کرنا، اور ب) ایک باکسڈ پروڈکٹ کی قیمت پر - غیر ملکی حریفوں کے ساتھ بے مثال۔
میں فخر کرنا چاہوں گا، لیکن تھوڑا سا اداس =)
اب سب کچھ اس طرح نظر آیا:
مزید ایک دو سالوں میں ہر ایک کے پاس پہلے سے ہی آڈیٹر تھے۔ رجسٹری میں زیادہ سے زیادہ وسائل تھے۔ کچھ پرانے آلات (مثال کے طور پر، Cisco 7600) کے لیے، "سائیڈ فلٹرنگ" اسکیم صرف ناقابل اطلاق ہو گئی: 76 پلیٹ فارمز پر راستوں کی تعداد نو لاکھ تک محدود ہے، جب کہ آج صرف IPv4 روٹس کی تعداد 800 کے قریب پہنچ رہی ہے۔ ہزار اور اگر یہ ipv6 بھی ہے... اور یہ بھی... کتنا ہے؟ RKN پابندی میں 900000 انفرادی پتے؟ =)
کسی نے فلٹرنگ سرور پر تمام ریڑھ کی ہڈی کی ٹریفک کی عکس بندی والی اسکیم کو تبدیل کیا، جس میں پورے بہاؤ کا تجزیہ کرنا چاہیے اور، اگر کچھ خراب پایا جاتا ہے، تو دونوں سمتوں (بھیجنے والے اور وصول کنندہ) میں RST بھیجیں۔
تاہم، جتنا زیادہ ٹریفک، اس اسکیم کا اطلاق اتنا ہی کم ہوگا۔ اگر پروسیسنگ میں ذرا سی بھی تاخیر ہوتی ہے تو، عکس والی ٹریفک کسی کا دھیان نہ دینے سے اڑ جائے گی، اور فراہم کنندہ کو اچھی رپورٹ موصول ہوگی۔
زیادہ سے زیادہ فراہم کنندگان کو ہائی ویز پر مختلف درجوں کے DPI سسٹمز انسٹال کرنے پر مجبور کیا جاتا ہے۔
ایک یا دو سال پہلے افواہوں کے مطابق، تقریبا تمام FSB سامان کی اصل تنصیب کا مطالبہ کرنے لگے (پہلے، زیادہ تر فراہم کنندگان حکام کی منظوری سے انتظام کرتے تھے۔ SORM منصوبہ - کہیں کچھ تلاش کرنے کی ضرورت کی صورت میں آپریشنل اقدامات کا منصوبہ)
پیسوں کے علاوہ (بالکل حد سے زیادہ نہیں، لیکن پھر بھی لاکھوں)، SORM کو نیٹ ورک کے ساتھ بہت زیادہ ہیرا پھیری کی ضرورت ہے۔
- SORM کو نیٹ ترجمہ سے پہلے "گرے" صارف کے پتے دیکھنے کی ضرورت ہے۔
- SORM میں نیٹ ورک انٹرفیس کی ایک محدود تعداد ہے۔
اس لیے، خاص طور پر، ہمیں دانا کے ایک ٹکڑے کو بہت زیادہ دوبارہ بنانا پڑا - بس صارف کی ٹریفک کو ایک ہی جگہ پر رسائی سرورز تک جمع کرنے کے لیے۔ کئی لنکس کے ساتھ SORM میں اس کی عکس بندی کرنے کے لیے۔
یعنی، بہت آسان، یہ تھا (بائیں) بمقابلہ بن گیا (دائیں):
اب زیادہ تر فراہم کنندگان کو SORM-3 کے نفاذ کی بھی ضرورت ہوتی ہے - جس میں، دیگر چیزوں کے علاوہ، نیٹ براڈکاسٹس کی لاگنگ بھی شامل ہے۔
ان مقاصد کے لیے، ہمیں اوپر دیے گئے خاکے میں NAT کے لیے علیحدہ سامان بھی شامل کرنا پڑا (بالکل وہی جو پہلے حصے میں زیر بحث آیا ہے)۔ مزید برآں، ایک خاص ترتیب میں شامل کریں: چونکہ SORM کو پتوں کا ترجمہ کرنے سے پہلے ٹریفک کو "دیکھنا" چاہیے، اس لیے ٹریفک کو سختی سے اس طرح جانا چاہیے: صارفین -> سوئچنگ، کرنل -> رسائی سرورز -> SORM -> NAT -> سوئچنگ، کرنل - > انٹرنیٹ۔ ایسا کرنے کے لیے، ہمیں منافع کے لیے ٹریفک کے بہاؤ کو لفظی طور پر دوسری سمت میں "مڑنا" پڑا، جو کافی مشکل بھی تھا۔
خلاصہ یہ کہ پچھلے دس سالوں میں، اوسط فراہم کنندہ کا بنیادی ڈیزائن کئی گنا زیادہ پیچیدہ ہو گیا ہے، اور ناکامی کے اضافی پوائنٹس (دونوں آلات کی شکل میں اور سنگل سوئچنگ لائنوں کی صورت میں) میں نمایاں اضافہ ہوا ہے۔ درحقیقت، "ہر چیز کو دیکھنے" کی ضرورت کا مطلب اس "ہر چیز" کو ایک نقطہ پر کم کرنا ہے۔
میرے خیال میں یہ رونٹ کو خود مختار بنانے، اس کی حفاظت، اسے مستحکم کرنے اور اسے بہتر بنانے کے لیے موجودہ اقدامات کے لیے کافی شفاف طریقے سے بڑھایا جا سکتا ہے :)
اور یارووایا اب بھی آگے ہے۔
ماخذ: www.habr.com