میل بغیر VPN سرور تک پہنچتی ہے: اصول کہاں نافذ کریں

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

پروڈکٹ منتخب کرنے سے پہلے تقاضا منتخب کریں۔ سرور کا اصول اور کلائنٹ کا اصول مختلف جگہوں پر ناکام ہوتے ہیں، مختلف ثبوت دیتے ہیں اور مختلف مالکان کے ہوتے ہیں۔ دونوں کا اطلاق اسی وقت درست ہے جب دونوں بیانات سچ ہوں، مگر ایک دوسرے کا متبادل نہیں۔ دونوں تقاضے جائز ہیں؛ بس وہ ایک ہی کنٹرول نہیں ہیں۔

علامت Mac جیسی لگتی ہے، مگر رساؤ سرور میں ہو سکتا ہے

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

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

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

سرور پر داخلہ: ایپ نہیں، ماخذ مسترد کریں

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

جب تقاضا «سروس براہ راست کلائنٹس کی خدمت نہ کرے» ہو تو یہ سب سے مضبوط حد ہے۔ صارف دوسرا میل کلائنٹ نصب کرے تو بھی یہ قائم رہتا ہے، کیوں کہ انکار توثیق سے پہلے ہوتا ہے۔ یہ اس Mac پر بھی قائم رہتا ہے جو اپنی VPN پالیسی نظرانداز کرتا ہے۔

اس کی حد بھی اتنی ہی اہم ہے۔ مسترد شدہ رابطہ ثابت کرتا ہے کہ سروس نے نشست مسترد کی؛ یہ ثابت نہیں کرتا کہ Mac نے کوئی کوشش نہیں کی۔ DNS حل، پچھلے لوڈ بیلنسر کی طرف TCP SYN اور ناکامی کے بعد دوبارہ کوشش، سب سرور کے اصول تک پہنچنے سے پہلے ہو سکتے ہیں۔ اگر تقاضا رسائی کے بجائے کوششوں کے انکشاف سے متعلق ہو، تو سرور پر داخلہ آدھا کنٹرول ہے۔

کلائنٹ پر نفاذ: صرف سرنگ نہیں، کوشش روکیں

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

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

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

ایپ اور منزل کی سطح کے اصولوں کا اثر مختلف ہے

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

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

تقاضے کے الفاظ کے مطابق چنیں۔ «یہ کام والا اکاؤنٹ براہ راست نہ جڑے» منزل کے دائرے کی طرف اشارہ کرتا ہے۔ «یہ Mac VPN سے باہر میل نہ چلائے» وسیع ایپ اصول کو جائز ٹھہراتا ہے، بشرطیکہ مالک ذاتی اکاؤنٹ پر پڑنے والے اثر کو قبول کرے۔

انکار اور عدم موجودگی الگ الگ جانچیں

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

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

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