کیا کوئی نیٹ ورک انکرپشن توڑے بغیر آپ کا VPN بلاک کر سکتا ہے؟
انکرپشن مواد کی حفاظت کرتی ہے، پہنچانے کی نہیں۔ بلاک فہرستوں، اجازت فہرستوں اور مکمل بندشوں کا موازنہ کریں، پھر پوچھیں کہ ایک مشاہدہ واقعی کیا ثابت کر سکتا ہے۔
کسی آپریٹر کو سرنگ روکنے کے لیے سیشن کلید کی ضرورت نہیں: راستے میں پیکٹ پھینک دیں اور وہ ناکام ہو جاتی ہے، جبکہ کرپٹوگرافی بالکل اتنی ہی مضبوط رہتی ہے جتنا اس کے ڈیزائن نے وعدہ کیا تھا۔ انکرپشن اس چیز کی حفاظت کرتی ہے جو گفتگو اٹھاتی ہے، کسی نیٹ ورک کی اسے اٹھانے کی آمادگی کی نہیں۔ ان دو خصوصیات کو الگ کرنا ناقابلِ بلاک ہونے کی بحث کو اس سوال میں بدل دیتا ہے کہ کون سی پالیسی نافذ ہے اور وہ کتنی دور تک پہنچتی ہے۔ نیچے کا موازنہ دستیابی اور رازداری کو الگ رکھتا ہے، کیونکہ VPN بلاکنگ کے بارے میں بیشتر پختہ دعوے خاموشی سے دونوں کو ملا دیتے ہیں۔
رسائی کا امکان راستے کا فیصلہ ہے
ہر ترسیل کسی راستے پر منحصر ہے جو پیکٹ آگے بھیجتا ہے، اور یہاں ہر پالیسی سوال اسی بھیجنے کے فیصلے پر آ کر رکتا ہے۔ پیکٹ پھینکنے والا قاعدہ رازداری کو چھوئے بغیر دستیابی بدل دیتا ہے، اور اسی طرح ایک سرنگ بےداغ انکرپٹ ہو کر بھی اسی لمحے مکمل طور پر ناقابلِ استعمال ہو سکتی ہے۔ اس نتیجے میں کچھ بھی سائفر توڑنے یا کلید واپس حاصل کرنے کا تقاضا نہیں کرتا۔ یہ صرف راستے پر کنٹرول کا تقاضا کرتا ہے۔
الجھن عام طور پر اس وقت شروع ہوتی ہے جب دو خصوصیات ایک ہی لفظ بانٹتی ہیں۔ مضبوط کرپٹوگرافی بتاتی ہے کہ بہاؤ کون پڑھ سکتا ہے؛ یہ اس بارے میں کچھ نہیں کہتی کہ کوئی درمیانی آلہ اسے گزرنے دے گا یا نہیں۔ اس لیے یہ دعویٰ کہ VPN بلاک نہیں ہو سکتا، اس کے نیچے دوسرے دعوے کا محتاج ہے، یعنی راستے پر کوئی بھی پیکٹ پھینکنے کو تیار نہیں۔
لازم کرنے کے انداز اور ہر ایک کی قیمت
تین انداز زیادہ تر حقیقی پالیسیوں کا احاطہ کرتے ہیں، اور وہ اس میں مختلف ہیں کہ کیا جاننا ضروری ہے، چلانے کی لاگت کیا ہے اور اور کون تکلیف اٹھاتا ہے۔ ان میں سے ہر ایک کچھ بھی ڈکرپٹ کیے بغیر سرنگ سے انکار کر سکتا ہے۔ فرق اہم ہیں کیونکہ ایک ہی لفظ، بلاکنگ، تینوں کے لیے استعمال ہوتا ہے۔
| Style | Default | What it must know | Who else is affected |
|---|---|---|---|
| Blocklist | Allow, minus listed destinations | Addresses and ports of known endpoints | Unrelated tenants on a listed address |
| Allowlist | Deny, plus approved destinations | A maintained definition of permitted traffic | Anything outside the approved set |
| Shutdown | Deny broadly for a period | Nothing about the protocol | Ordinary services along the same path |
وہ جدول لاگت کا نقشہ ہے، درجہ بندی نہیں۔ بلاک فہرست شروع کرنا سستا اور درست رکھنا مہنگا ہے؛ اجازت فہرست دریافت کو اجازت شدہ مجموعے کی دیکھ بھال سے بدل دیتی ہے، اور مکمل بندش کو کسی درجہ بندی کی ضرورت ہی نہیں۔ انہیں الگ کرنے والی چیز تکنیکی نفاست نہیں بلکہ یہ ہے کہ ہر ایک مسلسل محنت کہاں رکھتا ہے۔ کاغذ پر سادہ دکھنے والی پالیسی میں عام طور پر کہیں اور ایک پوشیدہ دیکھ بھال کی سطر ہوتی ہے۔
بلاک فہرست اس بات سے محدود ہے کہ پتہ کسی خدمت کو کتنی اچھی طرح نام دیتا ہے
بلاک فہرست پہلے سے شناخت شدہ منزلوں سے انکار کرتی ہے اور باقی کو عام طور پر دستیاب رکھتی ہے۔ اسے نافذ کرنے کے لیے پتے اور پورٹ درکار ہیں، صاف متن نہیں، اور یہی اسے شروع میں سستا بناتا ہے۔ لاگت بعد میں آتی ہے، کیونکہ جو حد کبھی ایک فراہم کنندہ کی نشاندہی کرتی تھی وہ بعد میں درجنوں غیر متعلق کرایہ داروں کی میزبانی کر سکتی ہے۔ ہر پتہ تبدیلی فہرست میں ترمیم لازم کرتی ہے، اور ہر پرانا اندراج معصوم ٹریفک اپنے ساتھ لے جاتا ہے۔
اس ماڈل میں درستگی اس بات سے محدود ہے کہ منزل کسی خدمت کو کتنی اچھی طرح شناخت کرتی ہے، اور مصروف مشترکہ آخری نقطہ ناقص شناخت کنندہ ہے۔ یہ ساختی حد ہے، عمل درآمد کی خرابی نہیں، اس لیے بہتر اوزار اسے دور نہیں کرتے۔ یہ بھی بتاتا ہے کہ بلاک فہرستیں کیوں بڑھتی ہیں: ہر نیا آخری نقطہ معمولی اضافہ لگتا ہے، اور ضمنی نقصان فہرست کے ساتھ بڑھتا ہے۔
اجازت فہرست دیکھ بھال کا بوجھ منتقل کرتی ہے
اجازت فہرست طے شدہ کو الٹ دیتی ہے تاکہ صرف پہلے سے منتخب منزلیں یا ٹریفک کی اقسام گزر سکیں۔ اسے ہر ممنوعہ آخری نقطے کی فہرست بنانا ضروری نہیں، جو اس وقت مدد کرتا ہے جب ممنوعہ مجموعہ بڑا ہو یا تیزی سے بدلے۔ اس کے بجائے اسے اجازت شدہ کی ایک برقرار رکھی گئی تعریف اور اس تعریف سے میل کھانے والا نفاذ درکار ہے۔
ایسی تعریف میں پورٹ نمبر عام کمزور مقام ہیں۔ پورٹ کی اجازت دینا اس ہر ایپلیکیشن کی شناخت کے برابر نہیں جو اسے استعمال کر سکتی ہے، اس لیے پورٹ پر مبنی اجازت فہرست اکثر مصنف کے ارادے سے زیادہ قبول کر لیتی ہے۔ پروٹوکول فنگر پرنٹ کا بھی دوسرے زاویے سے وہی مسئلہ ہے، کیونکہ وہ ٹریفک کی شکل پہچانتے ہیں، نیت نہیں۔ اس لیے اجازت فہرست خود بخود بلاک فہرست سے زیادہ درست نہیں؛ یہ کسی اور چیز کے بارے میں درست ہے۔
ایک مشاہدہ کس چیز کی تائید کر سکتا ہے اور کس چیز کی نہیں
بلاکنگ کے بارے میں کوئی بھی دعویٰ ہاتھ میں چار سوال لیے پڑھنا چاہیے: کون سے رسائی نیٹ ورک، کون سی منزلیں، کون سے پروٹوکول اور کون سی مشاہداتی مدت۔ آج ایک موبائل نیٹ ورک پر دیکھی گئی ناکامی کل کسی دوسرے نیٹ ورک سے اسی آخری نقطے کے بارے میں کچھ نہیں کہتی۔ ایک بار چلی سرنگ بھی مستقل دستیابی کے بارے میں کچھ نہیں کہتی۔
ناکامی کی وجہ پر نظریہ بنانے سے پہلے اس کی شکل کا مشاہدہ کیا جا سکتا ہے۔ خاموش اٹکنا، فوری انکار اور جڑنے کے بعد ری سیٹ مختلف نفاذ کے انداز کی طرف اشارہ کرتے ہیں، اور دو کمانڈیں انہیں الگ کرتی ہیں:
curl -sS -m 8 https://vpn.example.com/ -o /dev/null -w "%{http_code}\n"
traceroute -n -m 8 vpn.example.comوقت کی حد میں ختم ہونے والا اٹکنا خاموش پھینکنے کی طرف، تیز انکار راستے پر انکار کرنے والے آلے کی طرف، اور جڑنے کے بعد ری سیٹ غائب راستے کے بجائے حالت والی مداخلت کی طرف اشارہ کرتا ہے۔ سنسرشپ تکنیکوں پر RFC 9505 کا جائزہ ان شکلوں کے پیچھے موجود کنٹرول پوائنٹس اور مداخلت کے نمونوں کی وضاحت کرتا ہے۔ تاہم ان میں سے کوئی نہیں بتاتا کہ پالیسی کتنی وسیع پیمانے پر لاگو ہوتی ہے۔ استحکام رسائی سے زیادہ مضبوط دعویٰ ہے: آخری نقطے، سافٹ ویئر، پالیسیاں اور اجازت شدہ خدمات سب بدلتی ہیں، اس لیے غیر معینہ تاثیر کے لیے نفاذ کے جاری رہنے کے مفروضے درکار ہیں، ایک لمحے میں دیکھے گئے پتوں کی فہرست نہیں۔