VPN کے پیچھے SaaS کا منتظم علاقہ: کس پتے پر اعتماد کریں؟

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

ٹنل کے بعد ماخذ کو واقعی کیا ملتا ہے

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

curl -s https://ifconfig.me
dig +short admin.example.com

منقسم ٹنلنگ اس مفروضے کو خاموشی سے توڑ دیتی ہے۔ اگر VPN صرف نجی دفتری راستے لے جائے تو عوامی منتظم ہوسٹ نام کی درخواست مقامی ISP سے باہر جاتی ہے اور ماخذ رہائشی پتہ دیکھتا ہے۔ منسلک VPN آئیکن اس مخصوص منزل کے بارے میں کچھ ثابت نہیں کرتا، لہٰذا ٹنل نہیں، منزل جانچیں۔

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

صرف اس پراکسی پر اعتماد کریں جو پتہ دوبارہ لکھتا ہے

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

set_real_ip_from 192.0.2.0/24;
real_ip_header X-Forwarded-For;
real_ip_recursive on;
curl -H 'X-Forwarded-For: 198.51.100.27' https://origin.example.com/admin

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

شرط کو ہر محفوظ کارروائی سے منسلک کریں

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

user = requireAuthenticatedSession()
requirePermission(user, "admin")
requireVpnEgress(verifiedClientAddress(request))
performProtectedOperation(user, request)

یہی حد JSON API، برآمدات، دستخط شدہ ڈاؤن لوڈ URL اور WebSocket ہینڈ شیک کو بھی ڈھانپنی چاہیے، کیونکہ ان میں سے کسی کو بھی پہلے HTML صفحہ منگوانے کی ضرورت نہیں۔ VPN کے فعال ہونے کے دوران بنایا گیا ڈاؤن لوڈ لنک بعد میں بھی درست رہتا ہے جب تک ڈاؤن لوڈ اینڈ پوائنٹ دوبارہ جانچ نہ کرے۔ طویل المعیاد سیشنز کو بھی دوبارہ جانچنے کا قاعدہ درکار ہے، ورنہ ایک تصدیق شدہ درخواست مستقل استثنا بن جاتی ہے۔ ڈیفالٹ انکار ہی وہ واحد ترتیب ہے جو عملے کی تبدیلی سے بچتی ہے۔

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

ابھی بند کیے گئے بائی پاس جانچیں

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

curl -sI https://admin.example.com/export.csv
curl -s -H 'X-Forwarded-For: 198.51.100.27' https://origin.example.com/admin
curl -s https://admin.example.com/api/me -o /dev/null -w '%{http_code}\n'

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

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