Mac PF VPN لاک: سائٹ کی پالیسی، نہ کہ بھیجنے کے قابل خصوصیت
Packet Filter تقسیم شدہ مصنوعات کے لیے معاون API نہیں ہے۔ قواعد کے مجموعے کو مالک دیں، ہر استثنا کا نام لیں، اور منتقلیوں کی جانچ کریں۔
یہ آپ کے Mac پر کام کرتا ہے، اس لیے یہ ایسی چیز لگتی ہے جو آپ صارفین کو دے سکتے ہیں۔ یہ مفروضہ پہلی چیز ہے جسے چھوڑنا ہے۔ Apple کا TN3165 واضح طور پر کہتا ہے کہ عام طور پر تقسیم کی جانے والی مصنوعات کے لیے Packet Filter معاون API نہیں ہے، اور یہ مراعات یافتہ، کنٹرول شدہ سائٹ انتظام کو معقول صورت مانتا ہے۔ اس لیے PF پر بنایا گیا VPN لاک مالک والی مقامی عملی پالیسی ہے، ایپ کے اندر بھیجنے کے قابل خصوصیت نہیں۔
PF پیکیجنگ سطح نہیں ہے
یہ فرق علمی نہیں ہے۔ PF پر منحصر تقسیم شدہ مصنوعہ Apple کی اس میں کی جانے والی ہر تبدیلی، قواعد لکھنے والے کسی دوسرے اوزار کے ساتھ ہر تصادم، اور اس انتظام کے جاری رہنے کی کوئی معاونت کی ضمانت کے بغیر ورثے میں لیتا ہے۔ جو سائٹ اپنی مشینیں خود سنبھالتی ہے اس کا رشتہ مختلف ہے: وہ انحصار دستاویز کر سکتی ہے، ہر OS ریلیز پر اسے جانچ سکتی ہے، اور دیکھ بھال قبول کر سکتی ہے۔
نصب کرنے کے کچھ مشورے ایک حد سے گزرتے ہیں جس کا نام لینا چاہیے۔ ایک اینکر لوڈ کرنے کے لیے پورا سسٹم قواعد کا مجموعہ دوبارہ لکھنا، Apple کی سسٹم اسٹارٹ اپ کنفیگریشن میں ترمیم کرنا، یا System Integrity Protection کو غیر فعال کرنا دوبارہ استعمال کے قابل ترکیب کے لیے قابل قبول تقاضے نہیں ہیں۔ اگر کسی شائع شدہ رہنما کو ان میں سے کوئی چیز درکار ہو، تو وہ تجربہ گاہ بیان کر رہا ہے، تعینات کرنے کے قابل پالیسی نہیں۔
نحو سے پہلے اخراج کا ارادہ لکھیں
ایک بھی کلیدی لفظ چننے سے پہلے طے کریں کہ کیا اجازت ہے۔ عام طور پر تین راستے ہونے چاہئیں: VPN کلائنٹ کی اپنی سرور تک نقل و حمل، سرنگ کے اندر محفوظ ایپلیکیشن ٹریفک، اور ہر وہ چیز جسے سیٹ اپ یا مقامی خدمات کو واقعی براہ راست راستہ درکار ہو۔
ہر تجویز کردہ استثنا کو منزل، نقل و حمل اور مالک دیں۔ ایک سرے تک ہر پورٹ کی اجازت سرنگ کے استعمال کردہ ایک نقل و حمل سے کہیں زیادہ کی اجازت دیتی ہے، اور اضافی افشا کسی کے یہ طے کیے بغیر آتا ہے کہ ایسا ہی ہونا چاہیے۔ عوامی حل کنندہ کی اجازت دوستانہ لباس میں وہی جال ہے: یہ سرنگ بند ہونے پر بھی براہ راست DNS راستہ بناتا ہے، اس لیے ناموں کی تلاش اب بھی رستی ہے۔
| Path | Destination | Owner |
|---|---|---|
| VPN transport | Gateway address, one UDP port | Network team |
| Tunnel traffic | Internal prefixes | Application owner |
| Resolver exception | Named internal resolver | Security team |
استثنا کے لیے مفید جانچ یہ ہے کہ کیا آپ اس شخص کا نام لے سکتے ہیں جس نے اس کی درخواست کی اور وہ ناکامی جسے یہ روکتا ہے۔ اگر دونوں جواب نہ ہوں تو یہ قاعدہ غالباً غلط کنفیگریشن کا راستہ ہے جو بصورت دیگر نظر نہ آتا۔
utun نمبر شناخت نہیں ہیں
MacOS سرنگ انٹرفیس utun آلات کے طور پر بناتا ہے، اور آپ کے VPN کو دیا گیا نمبر مستحکم نہیں ری بوٹ، دوبارہ جڑنے، یا کسی دوسرے کلائنٹ کی موجودگی میں۔ کئی اندازہ شدہ نمبروں کی فہرست دینے والا قاعدہ پالیسی نہیں ہے؛ یہ ایک دوپہر کی تصویر ہے۔
قاعدہ کسی ایسی چیز سے باندھیں جو مطلوبہ فراہم کنندہ کی شناخت کرے: سرنگ کا دیا گیا پتہ منصوبہ، انٹرفیس کا مالک عمل، یا وہ کنفیگریشن جو VPN کلائنٹ خود سنبھالتا ہے۔ پھر لکھیں کہ وہ شناخت کیسے کام کرتی ہے، کیونکہ ایک سال بعد قاعدہ کا جائزہ لینے والے کے پاس آپ کی shell تاریخ نہیں ہوگی۔
لوڈ شدہ پالیسی کو قابل انتساب بنائیں
اینکر کا نام قواعد منظم کرتا ہے؛ یہ ثابت نہیں کرتا کہ موثر پالیسی وہی ہے جو آپ کا ارادہ تھا۔ اینکروں کے درمیان ترجیح، دوسرے سافٹ ویئر کے لوڈ کردہ قواعد، اور موجودہ حالت سب نتیجہ بدل سکتے ہیں۔ اس مشین پر PF کے مالک باقی سب کے ساتھ موثر مجموعے کا جائزہ لیں، اور ملکیت کو کنفیگریشن والی جگہ پر ہی دستاویز کریں۔ مختلف مفروضوں کے ساتھ مختلف اینکرز میں ترمیم کرنے والے دو مالک وہ عام طریقہ ہیں جس سے لاک میں سوراخ پیدا ہوتا ہے۔
قواعد کا مجموعہ سائٹ کے معاون کنفیگریشن راستے میں رکھیں، اس کا ورژن بنائیں، اور لکھیں کہ کون سی macOS ریلیزیں جانچی گئیں۔ ہاتھ سے لاگو ہونے والی اور ایک شخص کو یاد رہنے والی تبدیلی، فائل ہیڈر کچھ بھی کہے، دیکھ بھال والا ڈھانچہ نہیں ہے۔
منتقلیوں کی جانچ کریں، جڑی حالت کی نہیں
سرنگ چلنے کے دوران لی گئی اسکرین شاٹ تقریباً کچھ ثابت نہیں کرتی۔ اس کے بجائے حالتوں سے گزریں: کسی بھی کنکشن سے پہلے آغاز، کام کرتی سرنگ، بغیر انتباہ گرنے والی سرنگ، جان بوجھ کر منقطع کرنا، اور Wi-Fi سے ہاٹ اسپاٹ پر منتقلی۔ ہر حالت کا اپنا جواب ہے، اور دلچسپ وہ ناکامیاں ہیں، خوشگوار راستہ نہیں۔
ہر حالت میں لکھیں کہ جان بوجھ کر کیا قابل رسائی ہے۔ IPv4 اور IPv6 الگ الگ جانچیں، نام کی تحلیل جانچیں، اور وہ بہاؤ شامل کریں جو منتقلی سے پہلے قائم ہو چکا تھا، کیونکہ موجودہ کنکشن ہمیشہ نئی پالیسی کی پیروی نہیں کرتے۔ سرنگ بند ہونے پر ناکام ہونے والا براؤزر ایک ڈیٹا نقطہ ہے، دیگر تمام راستوں کے بند ہونے کا ثبوت نہیں۔
آخر میں، بحالی کا ایسا طریقہ رکھیں جو آپ کے بدلے جانے والے نیٹ ورک راستے پر منحصر نہ ہو۔ مقامی ذخیرے میں معلوم اچھی کنفیگریشن اور اسے لوڈ کرنے کا دستاویزی طریقہ لاک کو پالیسی بنا دیتے ہیں؛ ان کے بغیر، ایک خراب نظرثانی منتظم کو اس مشین سے باہر تالا لگا دیتی ہے جسے محفوظ ہونا چاہیے تھا۔