VPN کا ایگزٹ IP سرنگ کا ثبوت نہیں: سرور کیا دیکھتے ہیں

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

سرور ہر کنکشن پر ایک پتہ دیکھتا ہے

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

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

جانچیں کہ آپ کا ایگزٹ کیسا دکھتا ہے

قاعدہ لکھنے سے پہلے دونوں سروں سے راستہ دیکھیں۔ کلائنٹ کا اپنے ایگزٹ کے بارے میں نظریہ اور سرور کا کنکشن کے بارے میں نظریہ یہ دو حقائق ہیں جو اہم ہیں۔

curl -sS https://api.ipify.org; echo
ss -tn state established '( sport = :443 )' | head

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

دو ایگزٹ مجموعوں میں سے صرف ایک درج کیا جا سکتا ہے

ایک صورت درخواست کے لمحے جانچی جا سکتی ہے اور دوسری نہیں، جس سے بہت مختلف ضمانتیں پیدا ہوتی ہیں۔

curl -sS https://check.torproject.org/torbulkexitlist | wc -l

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

پتوں کو پالیسی ان پٹ کے طور پر استعمال کریں، ثبوت کے طور پر نہیں

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

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