کنکشن ٹریکنگ ("conntrack") لینکس کرنل نیٹ ورکنگ اسٹیک کی ایک بنیادی خصوصیت ہے۔ یہ دانا کو تمام منطقی نیٹ ورک کنکشن یا بہاؤ پر نظر رکھنے کی اجازت دیتا ہے اور اس طرح ان تمام پیکٹوں کی شناخت کرتا ہے جو ہر بہاؤ کو بناتے ہیں تاکہ ان پر ترتیب وار عمل کیا جا سکے۔
Conntrack ایک اہم دانا کی خصوصیت ہے جو کچھ بنیادی معاملات میں استعمال ہوتی ہے:
- NAT conntrack کی معلومات پر انحصار کرتا ہے لہذا یہ ایک ہی سلسلے کے تمام پیکٹوں کو یکساں طور پر دیکھ سکتا ہے۔ مثال کے طور پر، جب کوئی پوڈ کبرنیٹس سروس تک رسائی حاصل کرتا ہے، تو kube-proxy لوڈ بیلنسر NAT کا استعمال کرتے ہوئے ٹریفک کو کلسٹر کے اندر ایک مخصوص پوڈ کی طرف لے جاتا ہے۔ Conntrack ریکارڈ کرتا ہے کہ دیئے گئے کنکشن کے لیے، IP سروس کے تمام پیکٹوں کو ایک ہی پوڈ پر بھیجا جانا چاہیے، اور بیک اینڈ پوڈ کے ذریعے واپس کیے گئے پیکٹوں کو اس پوڈ پر واپس NAT کیا جانا چاہیے جہاں سے درخواست آئی تھی۔
- کیلیکو جیسی اسٹیٹفول فائر والز کنیکٹ ٹریک سے وائٹ لسٹ "ردعمل" ٹریفک تک کی معلومات پر انحصار کرتی ہیں۔ یہ آپ کو ایک نیٹ ورک پالیسی لکھنے کی اجازت دیتا ہے جس میں کہا گیا ہے کہ "میرے پوڈ کو کسی بھی ریموٹ IP ایڈریس سے منسلک ہونے کی اجازت دیں" بغیر کسی پالیسی کو واضح طور پر جوابی ٹریفک کی اجازت دینے کے لیے لکھے۔ (اس کے بغیر، آپ کو بہت کم محفوظ "کسی بھی آئی پی سے میرے پوڈ میں پیکٹ کی اجازت دیں" اصول شامل کرنا پڑے گا۔)
مزید برآں، conntrack عام طور پر سسٹم کی کارکردگی کو بہتر بناتا ہے (سی پی یو کی کھپت اور پیکٹ کی تاخیر کو کم کرکے) کیونکہ اسٹریم میں صرف پہلا پیکٹ ہوتا ہے۔
اس کے ساتھ کیا کرنا ہے اس بات کا تعین کرنے کے لیے پورے نیٹ ورک اسٹیک سے گزرنا چاہیے۔ پوسٹ دیکھیں""یہ کیسے کام کرتا ہے اس کی ایک مثال دیکھنے کے لئے۔
تاہم، conntrack کی اپنی حدود ہیں...
تو یہ سب کہاں غلط ہوا؟
conntrack ٹیبل میں ایک قابل ترتیب زیادہ سے زیادہ سائز ہے، اور اگر یہ مکمل ہو جاتا ہے، تو کنکشن عام طور پر مسترد یا چھوڑنا شروع ہو جاتے ہیں۔ زیادہ تر ایپلیکیشنز کے ٹریفک کو سنبھالنے کے لیے ٹیبل میں کافی خالی جگہ ہے، اور یہ کبھی بھی مسئلہ نہیں بنے گا۔ تاہم، کچھ ایسے منظرنامے ہیں جن میں آپ conntrack ٹیبل کے استعمال پر غور کرنا چاہتے ہیں:
- سب سے واضح معاملہ یہ ہے کہ اگر آپ کا سرور بیک وقت ایکٹو کنکشنز کی ایک بہت بڑی تعداد کو ہینڈل کرتا ہے۔ مثال کے طور پر، اگر آپ کا conntrack ٹیبل 128k اندراجات کے لیے ترتیب دیا گیا ہے، لیکن آپ کے پاس >128k کنکرنٹ کنکشنز ہیں، تو آپ کو یقیناً کسی پریشانی کا سامنا کرنا پڑے گا!
- ایک قدرے کم واضح معاملہ: اگر آپ کا سرور فی سیکنڈ کنکشنز کی ایک بہت بڑی تعداد پر کارروائی کرتا ہے۔ یہاں تک کہ اگر کنکشن قلیل المدت ہیں، ان کی نگرانی لینکس کے ذریعے کچھ عرصے تک جاری رہتی ہے (120s بذریعہ ڈیفالٹ)۔ مثال کے طور پر، اگر آپ کا کنٹراک ٹیبل 128k اندراجات کے لیے ترتیب دیا گیا ہے اور آپ فی سیکنڈ 1100 کنکشنز کو ہینڈل کرنے کی کوشش کر رہے ہیں، تو وہ کنٹراک ٹیبل کے سائز سے زیادہ ہو جائیں گے، چاہے کنکشن بہت ہی قلیل مدتی ہوں (128k/120s = 1092 کنکشن/ s)۔
ایپس کی کئی مخصوص قسمیں ہیں جو ان زمروں میں آتی ہیں۔ مزید برآں، اگر آپ کے پاس بہت سارے برے اداکار ہیں، تو آپ کے سرور کے کنٹراک ٹیبل کو بہت سارے آدھے کھلے کنکشنز سے بھرنا سروس کے انکار (DOS) حملے کے حصے کے طور پر استعمال کیا جا سکتا ہے۔ دونوں صورتوں میں، conntrack آپ کے سسٹم میں ایک محدود رکاوٹ بن سکتا ہے۔ کچھ معاملات میں، کنٹراک ٹیبل کے پیرامیٹرز کو ایڈجسٹ کرنا آپ کی ضروریات کو پورا کرنے کے لیے کافی ہو سکتا ہے - سائز کو بڑھا کر یا کنٹراک ٹائم آؤٹ کو کم کر کے (لیکن اگر آپ اسے غلط کرتے ہیں تو آپ کو کافی پریشانی کا سامنا کرنا پڑے گا)۔ دیگر معاملات کے لیے جارحانہ ٹریفک کے لیے کانٹراک کو بائی پاس کرنا ضروری ہوگا۔
حقیقی مثال
آئیے ایک خاص مثال دیتے ہیں: ایک بڑے SaaS فراہم کنندہ کے ساتھ جس کے ساتھ ہم نے کام کیا ہے میزبانوں پر متعدد میمکیچڈ سرورز تھے (ورچوئل مشینیں نہیں)، جن میں سے ہر ایک 50K+ قلیل مدتی کنکشن فی سیکنڈ پروسیس کرتا تھا۔
انہوں نے conntrack کنفیگریشن کے ساتھ تجربہ کیا، ٹیبل کے سائز میں اضافہ کیا اور ٹریکنگ کا وقت کم کیا، لیکن کنفیگریشن ناقابل اعتبار تھی، RAM کی کھپت میں نمایاں اضافہ ہوا، جو کہ ایک مسئلہ تھا (GBytes کے آرڈر پر!)، اور کنکشنز اتنے مختصر تھے کہ conntrack نے ایسا نہیں کیا۔ اس کا معمول کی کارکردگی کا فائدہ بنائیں (کم استعمال CPU یا پیکٹ میں تاخیر)۔
انہوں نے متبادل کے طور پر کیلیکو کا رخ کیا۔ کیلیکو نیٹ ورک کی پالیسیاں آپ کو مخصوص قسم کی ٹریفک کے لیے conntrack استعمال نہ کرنے کی اجازت دیتی ہیں (doNotTrack پالیسی کے اختیار کا استعمال کرتے ہوئے)۔ اس سے انہیں کارکردگی کی وہ سطح ملی جس کی انہیں ضرورت تھی، نیز Calico کی طرف سے فراہم کردہ سیکیورٹی کی اضافی سطح۔
کنٹراک کو بائی پاس کرنے کے لیے آپ کو کن حد تک جانا پڑے گا؟
- نیٹ ورک کو ٹریک نہ کرنے کی پالیسیاں عام طور پر ہموار ہونی چاہئیں۔ SaaS فراہم کنندہ کے معاملے میں: ان کی ایپلی کیشنز ایک محفوظ زون کے اندر چلتی ہیں اور اس وجہ سے، نیٹ ورک پالیسی کا استعمال کرتے ہوئے، وہ دیگر مخصوص ایپلی کیشنز سے ٹریفک کو وائٹ لسٹ کر سکتے ہیں جنہیں میم کیچ تک رسائی کی اجازت تھی۔
- ٹریک نہ کرنے کی پالیسی کنکشن کی سمت کو مدنظر نہیں رکھتی۔ اس طرح، اگر میم کیچڈ سرور ہیک ہو گیا ہے، تو آپ نظریاتی طور پر کسی بھی میم کیچڈ کلائنٹس سے رابطہ قائم کرنے کی کوشش کر سکتے ہیں، جب تک کہ یہ صحیح سورس پورٹ استعمال کرے۔ تاہم، اگر آپ نے اپنے memcached کلائنٹس کے لیے نیٹ ورک پالیسی کی درست وضاحت کی ہے، تو پھر بھی کنکشن کی یہ کوششیں کلائنٹ کی جانب سے مسترد کر دی جائیں گی۔
- نہ ٹریک کرنے کی پالیسی ہر پیکٹ پر لاگو ہوتی ہے، جیسا کہ عام پالیسیوں کے برعکس، جو صرف ایک فلو میں پہلے پیکٹ پر لاگو ہوتی ہے۔ اس سے فی پیکٹ CPU کی کھپت بڑھ سکتی ہے کیونکہ ہر پیکٹ کے لیے پالیسی کا اطلاق ہونا ضروری ہے۔ لیکن قلیل المدتی رابطوں کے لیے، یہ خرچ کنٹراک پروسیسنگ کے لیے وسائل کی کھپت میں کمی سے متوازن ہے۔ مثال کے طور پر، SaaS فراہم کنندہ کے معاملے میں، ہر کنکشن کے لیے پیکٹوں کی تعداد بہت کم تھی، اس لیے ہر پیکٹ پر پالیسیاں لاگو کرتے وقت اضافی CPU کا استعمال جائز تھا۔
آئیے جانچ شروع کرتے ہیں۔
ہم نے ریموٹ نوڈس پر چلنے والے میمکیچڈ سرور اور متعدد میمکیچڈ کلائنٹ پوڈز کے ساتھ ایک پوڈ پر ٹیسٹ چلایا، لہذا ہم فی سیکنڈ بہت بڑی تعداد میں کنکشن چلا سکتے ہیں۔ میم کیچڈ سرور پوڈ والے سرور کے کنٹراک ٹیبل میں 8 کور اور 512k اندراجات تھے (میزبان کے لیے معیاری ترتیب شدہ ٹیبل کا سائز)۔
ہم نے کارکردگی کا فرق اس کے درمیان ناپا: کوئی نیٹ ورک پالیسی نہیں؛ باقاعدہ کیلیکو پالیسی کے ساتھ؛ اور Calico do-not-track پالیسی۔
پہلے ٹیسٹ کے لیے، ہم نے کنکشنز کی تعداد 4.000 فی سیکنڈ مقرر کی، تاکہ ہم CPU کی کھپت میں فرق پر توجہ مرکوز کر سکیں۔ کوئی پالیسی اور باقاعدہ پالیسی کے درمیان کوئی خاص فرق نہیں تھا، لیکن do-not-track CPU کی کھپت میں تقریباً 20% اضافہ ہوا:
دوسرے ٹیسٹ میں، ہم نے اتنے ہی کنکشنز شروع کیے جتنے ہمارے کلائنٹ پیدا کر سکتے تھے اور فی سیکنڈ کنکشن کی زیادہ سے زیادہ تعداد کی پیمائش کی جسے ہمارا میمکیچڈ سرور سنبھال سکتا ہے۔ جیسا کہ توقع کی گئی ہے، "کوئی پالیسی نہیں" اور "باقاعدہ پالیسی" کے معاملات دونوں 4,000 کنکشنز فی سیکنڈ (512k/120s = 4,369 کنکشنز/s) کی کنٹراک حد تک پہنچ گئے۔ ٹریک نہ کرنے کی پالیسی کے ساتھ، ہمارے کلائنٹس نے بغیر کسی پریشانی کے 60,000 کنکشن فی سیکنڈ بھیجے۔ ہمیں یقین ہے کہ ہم مزید کلائنٹس کو شامل کر کے اس تعداد میں اضافہ کر سکتے ہیں، لیکن ہمیں لگتا ہے کہ یہ نمبر پہلے ہی اس مضمون کے نقطہ نظر کو واضح کرنے کے لیے کافی ہیں!
حاصل يہ ہوا
Conntrack دانا کی ایک اہم خصوصیت ہے۔ وہ اپنا کام پوری طرح کرتا ہے۔ یہ اکثر کلیدی نظام کے اجزاء کے ذریعہ استعمال ہوتا ہے۔ تاہم، کچھ مخصوص حالات میں، کنٹراک کی وجہ سے بھیڑ اس کے فراہم کردہ عام فوائد سے کہیں زیادہ ہے۔ اس منظر نامے میں، کیلیکو نیٹ ورک کی پالیسیوں کا استعمال نیٹ ورک سیکیورٹی میں اضافہ کرتے ہوئے conntrack کے استعمال کو منتخب طور پر غیر فعال کرنے کے لیے کیا جا سکتا ہے۔ دیگر تمام ٹریفک کے لیے، conntrack آپ کا دوست بننا جاری رکھے ہوئے ہے!
ہمارے بلاگ پر دیگر مضامین بھی پڑھیں:
ماخذ: www.habr.com