VPN آن ہونے پر ایپ نہیں چلنی چاہیے: اسے کیا نافذ کرتا ہے

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

افسانہ: kill switch پروگراموں کو شروع ہونے سے روکتا ہے

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

پروگرام شروع ہو سکتا ہے یا نہیں، یہ واقعی طے کرنے والا انتظام ایپلیکیشن کنٹرول ہے۔ Windows پر اس کا مطلب AppLocker یا WDAC ہے، اور منظم macOS پر ڈیوائس پروفائل کے ذریعے نافذ اجازت فہرست۔ دونوں ٹنل سے آزاد ہیں، اسی لیے دونوں تقاضے ایک ہی ٹکٹ میں ضم کر دیے جاتے ہیں اور پھر کوئی بھی پورا نہیں ہوتا۔

اوزار کا نام لینے سے پہلے موڈ کا نام لیں

قاعدہ کو تین حالتوں والی اسٹیٹ مشین کے طور پر لکھیں: عام استعمال، VPN کام کا سیشن اور اخراج۔ ممنوع اوورلیپ درمیانی حالت کا ہے، کلائنٹ سافٹ ویئر کا نہیں۔

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

دو طرفہ تصادم واقعی کیا کرتا ہے

واقعی systemd کے زیرِ انتظام دو سروسز کے لیے Conflicts= متوازی ہے: ایک کو شروع کرنا دوسری کو روکتا ہے۔ یونٹ حوالہ اس رویے کو دستاویز کرتا ہے اور الگ سے واضح ترتیب مانگتا ہے جب ایک کو دوسری کے شروع ہونے سے پہلے رکنا مکمل کرنا ہو۔ ان ترتیب اندراجات کے بغیر رکنا اور شروع ہونا مقابلہ کرتے ہیں، اور نتیجہ وقت پر منحصر ہوتا ہے۔

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

صرف پہلا آغاز نہیں، منتقلیاں جانچیں

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

systemctl show work-vpn.service -p Conflicts -p After
systemctl start work-vpn.service
systemctl is-active office-sync.service
nmcli connection show --active

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

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