ایک کلاؤڈ سروس کے لیے مقامی TLS، SSH فارورڈنگ یا VPN

سوال شاذ و نادر ہی یہ ہوتا ہے کہ دو کلاؤڈ مشینوں کے درمیان کسی چیز کو انکرپٹ کرنا چاہیے یا نہیں؛ سوال یہ ہے کہ آپ کون سا انٹرفیس انکرپٹ کر رہے ہیں اور کون کس کی شناخت جانچتا ہے۔ میں یہ گفتگو نیٹ ورک ڈایاگرام سے نہیں بلکہ سروس سے شروع کرتا ہوں، کیونکہ سروس پہلے ہی جانتی ہے کہ اسے کیا چاہیے۔ تین حدیں زیادہ تر معاملات ڈھک لیتی ہیں: ایپلیکیشن کا اپنا TLS، SSH کے ذریعے فارورڈ کیا گیا ایک TCP پورٹ، اور ایک روٹ شدہ اوورلی جو ہر شریک کو پتہ دیتا ہے۔ انہیں طاقت کے اعتبار سے نہیں، بلکہ اس اعتبار سے ترتیب دیا جاتا ہے کہ مسئلے کا کتنا حصہ ڈھکتے ہیں۔

نیٹ ورک سے نہیں، سروس سے شروع کریں

عمل سے باہر جائیں۔ یہ کون سا پروٹوکول بولتی ہے، کلائنٹ کون سا نام تصدیق کرے گا، اور کس کو بالکل کنکشن کھولنے کی اجازت ہے؟ یہ تین جواب کسی بھی موازنہ جدول سے زیادہ تیزی سے اختیارات ہٹاتے ہیں، اور سروس کی اپنی ترتیب عام طور پر چند منٹوں میں ان کا جواب دے دیتی ہے۔

ایک چھوٹی اندرونی API لیں جو پہلے ہی 8443 پورٹ پر HTTPS پیش کرتی ہے، api.internal.example کے لیے سرٹیفکیٹ کے ساتھ۔ ہوسٹ پر ss -ltnp دکھاتا ہے کہ یہ کس سے جڑا ہے، اور openssl s_client -connect 127.0.0.1:8443 -verify_hostname api.internal.example دکھاتا ہے کہ سرٹیفکیٹ اس نام کے لیے درست ہے یا نہیں جو کلائنٹ واقعی استعمال کرے گا۔ اگر دونوں صحت مند ہوں تو سروس اپنا بہاؤ خود محفوظ کر سکتی ہے اور صرف رسائی باقی رہتی ہے۔ یہ نیٹ ورک بنانے سے کہیں چھوٹا مسئلہ ہے۔

مرحلہ 1: کیا سروس اپنی حفاظت کرتی ہے؟

یہ وہ اختیار ہے جو موزوں ہونے پر لیا جاتا ہے، اور ٹیموں کے اندازے سے زیادہ بار موزوں ہوتا ہے۔ سروس کی انکرپشن کلائنٹ اور سرور کے درمیان پورا راستہ ڈھکتی ہے، درمیان کی ہر چھلانگ سمیت، جسے درمیان کے گرد کوئی سرنگ بہتر نہیں کرتی۔ متوقع نام اور اعتماد واضح طور پر مقرر کریں، کلائنٹ کے طے شدہ ذخیرے میں اتفاقاً جو موجود ہے اس پر انحصار کرنے کے بجائے۔

انکرپشن اور رسائی الگ کنٹرول رہتے ہیں، اور انہیں ملانا ہی وہ جگہ ہے جہاں یہ اختیار غلط ہوتا ہے۔ غیر محدود عوامی سننے والے پر TLS سروس اب بھی کسی سے بھی کنکشن کی کوششیں قبول کرتی ہے، اس لیے سننے والے اور نیٹ ورک قواعد کا تعین پے لوڈ محفوظ ہونے سے آزاد طور پر کرنا ہوگا۔ پھر انحصارات جانچیں، کیونکہ TLS پر API دریافت کے اختتامی نقطے، ایڈمن پورٹ یا ساتھ والے بلک ٹرانسفر چینل کے بارے میں کچھ نہیں کہتا۔ ان میں سے ہر ایک کو اپنا جواب چاہیے، اور ایک غیر محفوظ بھائی پوری حد کو افسانہ بنانے کے لیے کافی ہے۔

مرحلہ 2: کیا ایک TCP پورٹ ہی پوری ضرورت ہے؟

جب ضرورت واقعی ایک TCP پورٹ ہو، فارورڈنگ سب سے چھوٹی کام کرنے والی چیز ہے۔ SSH مقامی فارورڈنگ اس پورٹ کو پہلے سے موجود تصدیق شدہ کنکشن کے ذریعے لے جاتی ہے۔

شکل ssh -N -L 8443:127.0.0.1:8443 [email protected] ہے، اور اہم تفصیل ہدف کا پتہ ہے: 127.0.0.1 دور کی طرف حل ہوتا ہے، اس لیے سروس سے کنکشن آپ کے لیپ ٹاپ سے نہیں بلکہ باسٹین سے کھلتا ہے۔ مقامی سننے والے کو -L 127.0.0.1:8443:... کے طور پر تنگ باندھیں تاکہ آپ اتفاقاً سروس کو اپنے مقامی نیٹ ورک پر شائع نہ کریں۔ سرور کی طرف، کلائنٹ کے اچھے رویے پر بھروسہ کرنے کے بجائے محدود کریں کہ اکاؤنٹ کیا فارورڈ کر سکتا ہے۔ PermitOpen، AllowTcpForwarding local اور GatewayPorts no طے شدہ وہ تین ترتیبات ہیں جو عام ریلے کو مخصوص چینل میں بدل دیتی ہیں۔

معاہدہ دونوں سمتوں میں تنگ ہے۔ SSH اپنے چینل کی حفاظت کرتا ہے، اور باسٹین سے کسی دوسری ایپلیکیشن تک اگلی چھلانگ کو اپنی حفاظت چاہیے۔ صرف باسٹین کے loopback پر سننے والی سروس کی نمائش دوسرے نیٹ ورک سے پہنچنے والی سروس سے بالکل مختلف ہے، اور فارورڈنگ اسے نہیں بدلتی۔ سرنگ کو ان کا متبادل سمجھنے کے بجائے ایپلیکیشن کی تصدیق اور TLS جانچ برقرار رکھیں۔

یہ ایک مالک کے ساتھ ایک کنکشن کے لیے اچھی طرح کام کرتا ہے۔ بڑے پیمانے پر یہ ایک نظام بن جاتا ہے: مقامی پورٹ تصادم، نگرانی، کلید کی گردش اور یہ سوال کہ ری بوٹ کے بعد فارورڈنگ کون دوبارہ شروع کرتا ہے۔

مرحلہ 3: کیا روٹنگ ہی اصل ضرورت ہے؟

وہ فہرست سب سے چھوٹے اختیار کی ایماندار قیمت ہے، اور اسی لیے ٹیمیں بالآخر چند بھولے ہوئے پس منظر کمانڈز کو کسی منظم چیز سے بدل دیتی ہیں۔ متبادل خود بخود VPN نہیں ہے۔ اگر ضرورت اب بھی ایک TCP پورٹ ہے، تو دستاویزی مالک کے ساتھ زیر نگرانی فارورڈنگ اوورلی کے مقابلے میں سستے میں چلتی ہے اور ایسے طریقوں سے ناکام ہوتی ہے جو آپ دیکھ سکتے ہیں۔ خوبصورتی ماپنے سے پہلے عملی ملکیت ماپیں۔

روٹنگ اسی وقت درست جواب بنتی ہے جب روٹنگ ضرورت ہو۔ کئی ایپلیکیشنز جنہیں عام IP رابطہ چاہیے، ایسے پروٹوکول جنہیں TCP فارورڈنگ لے نہیں سکتی، یا میزبانوں کے درمیان منتقل ہونے والی سروسز — سب ایک ہی سمت اشارہ کرتے ہیں۔

اوورلی شرکاء کو پتہ اور راستہ دیتی ہے، پھر اصل کام شروع ہوتا ہے: غیر متوازی حدود، راستے کی ملکیت، DNS، اندراج، منسوخی اور ساتھی کے غائب ہونے پر کیا ہوتا ہے۔ ان میں سے کچھ بھی پتے کے ساتھ نہیں آتا۔ اوورلی میں قبول کیا گیا ساتھی بھی منزل پر ہر عمل کے لیے خود بخود مجاز نہیں ہوتا، اس لیے سروس سطح کی تصدیق باقی رہتی ہے۔

بعد میں آپ کے پاس کیا ہے

آپ جو ریکارڈ چھوڑتے ہیں اس میں دو چیزیں شامل ہیں۔ پہلی وہ شناخت ہے جس کی تصدیق کلائنٹ سے متوقع ہے، کیونکہ کچھ کام کرانے کے لیے نام کی جانچ نرم ہوتے ہی ان میں سے ہر حد خاموشی سے بگڑتی ہے۔ دوسری ہٹانے کا مرحلہ ہے: رسائی ختم ہونے پر کون سی کلید، کون سا قاعدہ یا کون سا راستہ غائب ہوتا ہے، اور یہ کون کرتا ہے۔

یہ سفر وہیں ختم ہوتا ہے جہاں شروع ہوا، سروس پر۔ وہ حد چنیں جو حقیقی ٹریفک ڈھکتی ہے اور ان ساتھیوں کی تصدیق کرتی ہے جن کی آپ تصدیق کرنا چاہتے تھے، پھر لکھیں کہ رسائی کیسے اپ ڈیٹ، نگرانی اور ہٹائی جاتی ہے۔ OpenSSH حوالہ تنگ معاہدے کا وعدہ کرنے سے پہلے فارورڈنگ اختیارات کی تصدیق کی جگہ ہے۔ اگر آپ ہٹانے کا مرحلہ ایک جملے میں بیان نہیں کر سکتے، تو حد مسئلے سے بڑی ہے۔