کلاؤڈ سرحد پر VPN کلائنٹ کے IP محفوظ رکھیں یا SNAT کریں

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

تین شرطیں اسے طے کرتی ہیں

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

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

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

راستہ جعل سازی کی اجازت نہیں

واپسی راستہ شامل کرنے سے آپ کے سب نیٹ کو پتہ چلتا ہے کہ جوابات کہاں جانے چاہئیں۔ یہ تانے بانے کو یہ نہیں بتاتا کہ ان پیکٹوں کو آگے بھیجنے والا انسٹینس انہیں کسی غیر ملکی ماخذ کے ساتھ بھیجنے کا مجاز ہے۔ AWS میں متعلقہ کنٹرول ماخذ اور منزل کی جانچ ہے، اور یہ ہر انسٹینس کے لیے نظر آتا ہے:

aws ec2 describe-instances --instance-ids i-0a1b2c3d4e5f60718 \
  --query "Reservations[].Instances[].SourceDestCheck"
aws ec2 modify-instance-attribute --instance-id i-0a1b2c3d4e5f60718 \
  --no-source-dest-check

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

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

ترجمہ کیا خریدتا ہے اور کیا لاگت دیتا ہے

گیٹ وے پر ماخذ دوبارہ لکھنے سے واپسی راستے کی دشواری ختم ہو جاتی ہے۔ ایپلیکیشن ایک ایسا پتہ دیکھتی ہے جس تک پہنچنے کا طریقہ اسے پہلے سے معلوم ہے، اور کلائنٹ سابقے کو کبھی کلاؤڈ روٹ جدول میں آنے کی ضرورت نہیں ہوتی۔ Linux میں قاعدہ ایک سطر ہے، اور جو سب سے تنگ نسخہ آپ لکھ سکتے ہیں وہ لکھنے کے قابل ہے:

sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -s 172.20.8.0/24 -o ens5 -j SNAT --to-source 10.40.3.10

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

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

ریلے ایک مختلف انٹرفیس ہے

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

وہ ہیڈر صرف تب قابل اعتماد ہے جب بیک اینڈ اسے پراکسی سے قبول کرے اور کسی اور سے نہیں۔ nginx کی اصطلاح میں اس کا مطلب ہے کہ آنے والی ہر چیز پر بھروسہ کرنے کے بجائے قابل اعتماد ساتھی کا نام واضح طور پر لیں:

set_real_ip_from 10.40.3.10;
real_ip_header X-Forwarded-For;
real_ip_recursive on;

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

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

لکھیں کہ ہر سرحد کیا دیکھتی ہے

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

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