دفتر اور VPN کے لیے ایک ہی URL؟ فہرستِ اجازت کا افسانہ کیوں ناکام ہوتا ہے

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

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

افسانہ: جڑنا راستہ بنانا نہیں ہے

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

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

درخواست کی تین حالتیں، دو منظور شدہ اخراج

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

ان منصوبوں کی بیشتر درمیانی قطار پر ٹوٹتی ہیں۔ اہم وہ پتہ ہے جو نفاذ کرنے والا آلہ دیکھتا ہے، نہ وہ نجی پتہ جو لیپ ٹاپ ٹنل کے اندر رکھتا ہے اور نہ اُس کا LAN پتہ۔ 10.8.0.6 جیسی قدر کسی عوامی سائٹ کے لیے کچھ معنی نہیں رکھتی، اور 192.168.1.44 بھی نہیں۔ ٹنل کا پتہ ٹنل کی پتہ بندی کی تفصیل ہے، کوئی ایسا سند نہیں جسے سائٹ جانچ سکے۔

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

ماخذ وہیں پڑھیں جہاں فیصلہ ہوتا ہے

پابندی اُس آلے پر رکھیں جو درخواست ختم کرتا ہے، اور یقینی بنائیں کہ کوئی متبادل اصلی راستہ اُسے نہیں بچاتا۔ Nginx رسائی ماڈیول allow اور deny ہدایات کو ترتیب سے جانچتا ہے، پہلا میل جیتتا ہے، اور گرد آلود بلاک سے وراثت میں ملنے والے قواعد location کے اندر بھی لاگو رہتے ہیں۔ ایک ہی جگہ تنگ allow کے ساتھ چوڑا allow ہو تو عام طور پر چوڑا فیصلہ کرتا ہے۔ اُس location کی پوری مؤثر ترتیب کو، اُس کی ایک بھی سطر میں ترمیم کرنے سے پہلے پڑھیں۔

server {
    listen 443 ssl;
    server_name intranet.example.com;

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

    location /app/ {
        allow 203.0.113.24;    # office public exit
        allow 198.51.100.77;   # approved VPN egress
        deny  all;
        proxy_pass http://app_backend;
    }
}

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

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

منقسم ٹنل: وہ درخواست جو کبھی اندر نہیں آتی

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

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

انکار ثابت کریں، پھر بحالی

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

curl -sS -o /dev/null -w 'status=%{http_code}
' https://intranet.example.com/app/login
# repeat with the tunnel up, then with it down
tail -f /var/log/nginx/access.log | grep ' /app/'

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

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