DDoS-Guard نیٹ ورک پر جائز ٹریفک حال ہی میں ایک سو گیگا بٹس فی سیکنڈ سے تجاوز کر گئی ہے۔ فی الحال، ہماری تمام ٹریفک کا 50% کلائنٹ ویب سروسز کے ذریعے پیدا ہوتا ہے۔ یہ بہت سے ہزاروں ڈومینز ہیں، بہت مختلف اور زیادہ تر معاملات میں انفرادی نقطہ نظر کی ضرورت ہوتی ہے۔
کٹ کے نیچے یہ ہے کہ ہم کس طرح فرنٹ نوڈس کا نظم کرتے ہیں اور لاکھوں سائٹس کے لیے SSL سرٹیفکیٹ جاری کرتے ہیں۔
ایک سائٹ، یہاں تک کہ ایک بہت بڑی سائٹ کے لیے ایک محاذ قائم کرنا آسان ہے۔ ہم nginx یا haproxy یا lighttpd لیتے ہیں، اسے گائیڈز کے مطابق ترتیب دیتے ہیں اور اسے بھول جاتے ہیں۔ اگر ہمیں کچھ تبدیل کرنے کی ضرورت ہے، تو ہم دوبارہ لوڈ کرتے ہیں اور دوبارہ بھول جاتے ہیں۔
جب آپ پرواز کے دوران بڑی مقدار میں ٹریفک پر کارروائی کرتے ہیں، درخواستوں کی قانونی حیثیت کا جائزہ لیتے ہیں، صارف کے مواد کو کمپریس اور کیش کرتے ہیں، اور اسی وقت فی سیکنڈ میں کئی بار پیرامیٹرز تبدیل کرتے ہیں تو سب کچھ بدل جاتا ہے۔ صارف اپنے ذاتی اکاؤنٹ میں سیٹنگز تبدیل کرنے کے فوراً بعد تمام بیرونی نوڈس پر نتیجہ دیکھنا چاہتا ہے۔ ایک صارف API کے ذریعے انفرادی ٹریفک پروسیسنگ پیرامیٹرز کے ساتھ کئی ہزار (اور بعض اوقات دسیوں ہزار) ڈومینز بھی ڈاؤن لوڈ کر سکتا ہے۔ یہ سب کچھ امریکہ، یورپ اور ایشیاء میں بھی فوری طور پر کام کرنا چاہئے - یہ کام سب سے معمولی نہیں ہے، اس بات پر غور کرتے ہوئے کہ صرف ماسکو میں متعدد جسمانی طور پر الگ الگ فلٹریشن نوڈس ہیں۔
دنیا بھر میں بہت سے بڑے قابل اعتماد نوڈس کیوں ہیں؟
-
کلائنٹ ٹریفک کے لیے سروس کا معیار - USA سے درخواستوں پر USA میں کارروائی کرنے کی ضرورت ہے (بشمول حملوں، پارسنگ اور دیگر بے ضابطگیوں کے لیے)، اور ماسکو یا یورپ کی طرف نہیں کھینچا جانا، غیر متوقع طور پر پروسیسنگ میں تاخیر میں اضافہ ہوتا ہے۔
-
حملے کی ٹریفک کا مقامی ہونا ضروری ہے - ٹرانزٹ آپریٹرز حملوں کے دوران انحطاط کر سکتے ہیں، جس کا حجم اکثر 1Tbps سے زیادہ ہوتا ہے۔ ٹرانس اٹلانٹک یا ٹرانسایشین لنکس پر حملہ آور ٹریفک کو منتقل کرنا اچھا خیال نہیں ہے۔ ہمارے پاس حقیقی معاملات تھے جب ٹائر-1 آپریٹرز نے کہا: "آپ کو ملنے والے حملوں کا حجم ہمارے لیے خطرناک ہے۔" اس لیے ہم آنے والی اسٹریمز کو ان کے ذرائع کے جتنا قریب ہو سکے قبول کرتے ہیں۔
-
سروس کے تسلسل کے لیے سخت تقاضے - صفائی کے مراکز کو ہماری تیزی سے بدلتی ہوئی دنیا میں ایک دوسرے پر یا مقامی واقعات پر انحصار نہیں کرنا چاہیے۔ کیا آپ نے ایک ہفتے کے لیے MMTS-11 کی تمام 9 منزلوں کی بجلی کاٹ دی؟ - کوئی مسئلہ نہیں. ایک بھی کلائنٹ جس کا اس مخصوص مقام پر کوئی جسمانی تعلق نہیں ہے نقصان نہیں اٹھائے گا، اور ویب سروسز کو کسی بھی حالت میں نقصان نہیں پہنچے گا۔
اس سب کا انتظام کیسے کریں؟
سروس کنفیگریشنز کو جلد سے جلد تمام فرنٹ نوڈس میں تقسیم کیا جانا چاہیے (مثالی طور پر فوری طور پر)۔ آپ صرف ٹیکسٹ کنفیگرز کو لے کر دوبارہ نہیں بنا سکتے اور ہر تبدیلی پر ڈیمونز کو دوبارہ بوٹ نہیں کر سکتے ہیں - وہی nginx کچھ اور منٹوں (یا اگر ویب ساکٹ کے طویل سیشنز ہوں تو گھنٹوں) کے لیے عمل کو بند کرتا رہتا ہے۔
nginx کنفیگریشن کو دوبارہ لوڈ کرتے وقت، درج ذیل تصویر بالکل نارمل ہے۔
میموری کے استعمال پر:
پرانے کارکنان میموری کو کھا جاتے ہیں، بشمول میموری جو قطعی طور پر کنکشن کی تعداد پر منحصر نہیں ہوتی ہے - یہ عام بات ہے۔ کلائنٹ کے کنکشن بند ہونے پر، یہ میموری آزاد ہو جائے گی۔
جب nginx ابھی شروع ہو رہا تھا تو یہ مسئلہ کیوں نہیں تھا؟ کوئی HTTP/2، کوئی WebSocket، کوئی بڑے طویل عرصے تک زندہ رہنے والے کنکشن نہیں تھے۔ ہماری ویب ٹریفک کا 70% HTTP/2 ہے، جس کا مطلب ہے بہت طویل رابطے۔
حل آسان ہے - nginx کا استعمال نہ کریں، ٹیکسٹ فائلوں کی بنیاد پر محاذوں کا انتظام نہ کریں، اور یقینی طور پر ٹرانس پیسفک چینلز پر زپ شدہ ٹیکسٹ کنفیگریشن نہ بھیجیں۔ چینلز، یقیناً، ضمانت یافتہ اور محفوظ ہیں، لیکن اس سے وہ کم بین البراعظمی نہیں بنتے۔
ہمارے پاس اپنا فرنٹ سرور بیلنسر ہے، جس کے اندرونی حصے میں اگلے مضامین میں بتاؤں گا۔ اہم چیز جو یہ کر سکتی ہے وہ ہے فلائی پر فی سیکنڈ ہزاروں کنفیگریشن تبدیلیاں، بغیر دوبارہ شروع کیے، دوبارہ لوڈ، میموری کی کھپت میں اچانک اضافہ، اور یہ سب کچھ۔ یہ ہاٹ کوڈ ری لوڈ سے بہت ملتا جلتا ہے، مثال کے طور پر ایرلنگ میں۔ ڈیٹا کو جیو ڈسٹری بیوٹڈ کلیدی ویلیو ڈیٹا بیس میں محفوظ کیا جاتا ہے اور سامنے والے ایکچیوٹرز کے ذریعے اسے فوری طور پر پڑھا جاتا ہے۔ وہ. آپ ماسکو میں ویب انٹرفیس یا API کے ذریعے SSL سرٹیفکیٹ اپ لوڈ کرتے ہیں، اور چند سیکنڈ میں یہ لاس اینجلس میں ہمارے کلیننگ سینٹر جانے کے لیے تیار ہو جاتا ہے۔ اگر اچانک عالمی جنگ ہو جاتی ہے اور پوری دنیا میں انٹرنیٹ غائب ہو جاتا ہے، تو ہمارے نوڈس خودمختار طور پر کام کرتے رہیں گے اور اسپلٹ برین کی مرمت کرتے رہیں گے جیسے ہی سرشار چینل لاس اینجلس-ایمسٹرڈیم-ماسکو، ماسکو-ایمسٹرڈیم-ہانگ کانگ- Los-Los دستیاب ہو جاتا ہے۔ اینجلس یا کم از کم GRE بیک اپ اوورلیز میں سے ایک۔
یہی طریقہ کار ہمیں لیٹس انکرپٹ سرٹیفکیٹس کو فوری طور پر جاری اور تجدید کرنے کی اجازت دیتا ہے۔ بہت آسان یہ اس طرح کام کرتا ہے:
-
جیسے ہی ہم اپنے کلائنٹ کے ڈومین کے لیے کم از کم ایک HTTPS درخواست دیکھتے ہیں بغیر کسی سرٹیفکیٹ (یا میعاد ختم ہونے والے سرٹیفکیٹ کے ساتھ)، درخواست کو قبول کرنے والا بیرونی نوڈ اس کی اطلاع داخلی سرٹیفیکیشن اتھارٹی کو دیتا ہے۔
-
اگر صارف نے Let's Encrypt جاری کرنے سے منع نہیں کیا ہے، تو سرٹیفیکیشن اتھارٹی CSR تیار کرتی ہے، LE سے تصدیقی ٹوکن وصول کرتی ہے اور اسے ایک انکرپٹڈ چینل پر تمام محاذوں پر بھیجتی ہے۔ اب کوئی بھی نوڈ LE سے تصدیق شدہ درخواست کی تصدیق کر سکتا ہے۔
-
چند لمحوں میں ہمیں درست سرٹیفکیٹ اور پرائیویٹ کی مل جائے گی اور اسی طرح مورچوں کو بھیج دی جائے گی۔ ایک بار پھر، ڈیمن کو دوبارہ شروع کیے بغیر
-
میعاد ختم ہونے کی تاریخ سے 7 دن پہلے، سرٹیفکیٹ کو دوبارہ حاصل کرنے کا طریقہ کار شروع کیا جاتا ہے۔
اس وقت ہم صارفین کے لیے مکمل طور پر شفاف، حقیقی وقت میں 350k سرٹیفکیٹس کو گھما رہے ہیں۔
سیریز کے مندرجہ ذیل مضامین میں، میں بڑی ویب ٹریفک کی ریئل ٹائم پروسیسنگ کی دیگر خصوصیات کے بارے میں بات کروں گا - مثال کے طور پر، ٹرانزٹ کلائنٹس کے لیے سروس کے معیار کو بہتر بنانے کے لیے نامکمل ڈیٹا کا استعمال کرتے ہوئے RTT کا تجزیہ کرنے کے بارے میں اور عام طور پر ٹرانزٹ ٹریفک کے تحفظ کے بارے میں terabit حملے، ٹریفک کی معلومات کی ترسیل اور جمع کے بارے میں، WAF کے بارے میں، تقریباً لامحدود CDN اور مواد کی ترسیل کو بہتر بنانے کے لیے بہت سے طریقہ کار۔
سروے میں صرف رجسٹرڈ صارفین ہی حصہ لے سکتے ہیں۔ ، برائے مہربانی.
آپ سب سے پہلے کیا جاننا چاہیں گے؟
-
14,3٪ویب ٹریفک کے معیار کا کلسٹرنگ اور تجزیہ کرنے کے الگورتھم <3
-
33,3٪DDoS-Guard7 بیلنسرز کے اندرونی حصے
-
9,5٪ٹرانزٹ L3/L4 ٹریفک کا تحفظ2
-
0,0٪ٹرانزٹ ٹریفک پر ویب سائٹس کی حفاظت
-
14,3٪ویب ایپلیکیشن فائر وال 3
-
28,6٪تجزیہ اور کلک کرنے کے خلاف تحفظ 6
21 صارفین نے ووٹ دیا۔ 6 صارفین غیر حاضر رہے۔
ماخذ: www.habr.com