فیل-اوپن بمقابلہ فیل-کلوزڈ: VPN کا کِل سوئچ کیا طے کرتا ہے
دونوں اصطلاحات بتاتی ہیں کہ ٹنل جانے کے بعد کیا ہوتا ہے، یہ نہیں کہ انکرپشن کتنی مضبوط ہے۔ آپ کا منتخب کردہ دائرہ طے کرتا ہے کہ ٹریفک واقعی لیک ہوتی ہے یا نہیں۔
یہ ایک افسانہ ہے کہ فیل-کلوزڈ محفوظ سیٹنگ ہے اور فیل-اوپن لاپرواہ۔ دونوں بتاتی ہیں کہ ٹنل جانے کے بعد ٹریفک کے ساتھ کیا ہوتا ہے، اور کوئی بھی یہ نہیں بدلتی کہ وہ ٹنل کتنی اچھی طرح انکرپٹ کرتی ہے۔ طویل استثنا فہرست والی فیل-کلوزڈ پالیسی ایسے ڈیوائس پر فیل-اوپن پالیسی سے زیادہ لیک کر سکتی ہے جو کبھی دفتر کا نیٹ ورک نہیں چھوڑتا۔ وہ نتیجہ منتخب کریں جو آپ ٹریفک کے مالک کو سمجھا سکیں۔
لیبل نتیجہ بتاتا ہے، طاقت نہیں
یہ الفاظ کنٹرول سسٹمز سے آئے ہیں: کسی جزو کے ناکام ہونے پر فیل-اوپن کام کی اجازت دیتا ہے، فیل-کلوزڈ اسے مسترد کرتا ہے۔ VPN پر لاگو کریں تو ناکام ہونے والا جزو ٹنل ہے، اور سوال یہ ہے کہ ٹریفک کو کسی دوسرے راستے سے جاری رہنے کی اجازت ہے یا نہیں۔ سائفر کا انتخاب، کلید کی لمبائی اور پروٹوکول الگ فیصلے ہیں۔
الجھن برقرار رہتی ہے کیونکہ کِل سوئچ سیکیورٹی فیچر جیسا لگتا ہے، اور بیچنے والے اسی طرح اس کی مارکیٹنگ کرتے ہیں۔ میکانی طور پر یہ ایک روٹنگ اور فائر وال اصول ہے جو اس ٹریفک کو روکتا ہے جو ٹنل کو لے جانا تھا، جو کلائنٹ میں، آپریٹنگ سسٹم میں یا گیٹ وے پر نافذ ہوتا ہے۔ جو تہہ اسے نافذ کرتی ہے وہی اس کا دائرہ بھی طے کرتی ہے، اور ایک تہہ کا اصول دوسری کو نہیں ڈھانپتا۔ گیٹ وے کا اصول ایسے لیپ ٹاپ کی حفاظت نہیں کر سکتا جو پہلے ہی دوسرے نیٹ ورک پر جا چکا ہو۔
ہر نتیجہ کیسی شکل میں نظر آتا ہے
ایک ہی پالیسی اس بات پر بہت مختلف برتاؤ کر سکتی ہے کہ آپ کو کون سی ناکامی پیش آتی ہے، اس لیے لیبل نہیں، واقعات کا موازنہ کریں۔
| Event | Fail-open result | Fail-closed result |
|---|---|---|
| Tunnel drops while a transfer runs | Transfer continues on the direct path | Transfer stalls until the tunnel returns |
| Client exits or crashes | Rules disappear with the process | Rules persist only if the OS owns them |
| Device boots before sign-in | Normal network access | Blocked until the VPN connects |
| Captive portal needed | Portal loads normally | Portal unreachable without an exception |
| IPv6 not carried by the tunnel | IPv6 traffic leaks directly | Leaks too, unless the block covers IPv6 |
آخری قطار وہی ہے جو انہیں پکڑتی ہے جو سمجھتے ہیں کہ کِل سوئچ ایک ہی سوئچ ہے۔ IPv4 روٹ ٹیبل کے لیے لکھا اصول IPv6 کے ڈیفالٹ راستے کو اچھوتا چھوڑ دیتا ہے، اور ایپلیکیشن اسے خوشی سے استعمال کر سکتی ہے۔
دائرہ طے کرتا ہے کہ لیک ہوتا ہے یا نہیں
یہ پوچھنے سے پہلے کہ کون سا موڈ ہے، پوچھیں کہ پالیسی کیا ڈھانپتی ہے۔ فی ایپلیکیشن اصول ایک ایپ کی حفاظت کرتا ہے اور کچھ نہیں، ڈیوائس بھر کا اصول استثناؤں کے سوا سب کا، اور گیٹ وے کا اصول صرف اس ٹریفک کا جو اس گیٹ وے تک پہنچتا ہے۔ DNS کو اپنا فیصلہ درکار ہے، کیونکہ مقامی ریزولور کو بھیجی گئی استفسار پے لوڈ مسدود ہونے پر بھی نام ظاہر کر سکتی ہے۔
مقامی نیٹ ورک کے استثنا پرنٹرز، کاسٹنگ اور کیپٹیو پورٹلز کے لیے ہیں، اور ہر ایک بلاک میں ایک سوراخ ہے۔ انہیں پالیسی کے ساتھ دستاویز کریں، کیونکہ کنفیگریشن وراثت میں پانے والا شخص ورنہ فیل-کلوزڈ کو مطلق پڑھے گا۔
دوبارہ جڑنا اور مسدود کرنا بھی الگ کنٹرول ہیں۔ کلائنٹ کبھی مسدود کیے بغیر خودکار طور پر دوبارہ جڑ سکتا ہے، یا دوبارہ جڑنے کے بغیر مسدود کر سکتا ہے، اور امتزاج طے کرتا ہے کہ خلل کے دوران صارف کیا تجربہ کرتا ہے۔
اسے منتقلی کے دوران ثابت کریں
مستحکم حالت کی جانچ کچھ ثابت نہیں کرتی۔ ٹنل کو جان بوجھ کر گرا دیں اور اس ایپلیکیشن کو آزمائیں جسے محفوظ ہونا چاہیے، پھر دیکھیں کہ وہ نیٹ ورک تک پہنچی یا نہیں۔ کلائنٹ کے اشارے کا نتیجے سے موازنہ کریں، کیونکہ جو اشارہ اب بھی جڑا ہوا بتاتا ہے وہی وہ حالت ہے جس کے لیے یہ پالیسی موجود ہے۔ اگر محفوظ ایپلیکیشن کامیاب ہو تو موڈ کے نام سے کوئی فرق نہیں پڑتا؛ آپ کے پاس لیک ہے۔
سائن اِن سے پہلے کولڈ بوٹ سے دہرائیں، Wi-Fi سے سیلولر پر جاتے وقت، اور محفوظ ایپ کو پس منظر میں رکھ کر۔ اگر بلاک کلائنٹ پروسیس نافذ کرتی ہے تو یہ بھی جانچیں کہ جب وہ پروسیس صاف بند ہونے کے بجائے مار دیا جائے تو کیا ہوتا ہے۔
آخر میں، صفائی کا راستہ دیکھیں۔ اگر کلائنٹ کے اصول فعال ہوں تو اسے ان انسٹال کیا جائے، تو آپریٹنگ سسٹم کا فائر وال بند کرنے کے بجائے بیچنے والے کا دستاویزی ہٹانے کا طریقہ استعمال کریں، کیونکہ فائر وال بند کرنا غیر متعلقہ حفاظت ہٹا دیتا ہے اور بچے ہوئے اصول کا مالک کون ہے اس کا جواب نہیں دیتا۔