کیا ایک VPN سروس Windows، Mac اور Linux ڈیسک ٹاپ کو ڈھانپ سکتی ہے؟

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

کلائنٹ فائل سے نہیں، رسائی کے معاہدے سے شروع کریں

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

دفتر کی ایک مثال شکل کو ٹھوس بناتی ہے: ایپلیکیشن سرورز 10.60.0.0/16 میں، نجی نام corp.example کے تحت، اندرونی ریزالور 10.61.0.53 پر، اور عام براؤزنگ اسی راستے پر چھوڑ دی گئی ہے جو ڈیوائس پہلے ہی استعمال کرتا ہے۔ آخری شق پالیسی کا فیصلہ ہے، کلائنٹ کا طے شدہ رویہ نہیں، اور اگر کوئی اور بات نہ کہے تو کئی کلائنٹس سب کچھ سرنگ سے بھیج دیں گے۔ معاہدے کو تاریخ اور مالک کے ساتھ درج کریں، کیونکہ وہی ریکارڈ بعد میں بتائے گا کہ سرنگ بدلی یا پالیسی۔

ایک پروٹوکول اور ایک تصدیقی جوڑا چنیں جسے آپ جائز قرار دے سکیں

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

تعیناتی گائیڈ لکھنے سے پہلے، بعد میں نہیں، ہر ہدف پلیٹ فارم پر اس جوڑے کو جانچیں۔ جو گیٹ وے EAP-MSCHAPv2 اور EAP-TLS دونوں دیتا ہے وہ فالبیک کے لیے گنجائش دیتا ہے، بشرطیکہ وہ فالبیک معاون کے طور پر درج ہو، کسی واقعے کے دوران دریافت نہ ہوا ہو۔ دو معاون راستے سستا بیمہ ہیں؛ بغیر دستاویز والا تیسرا راستہ مستقبل کا ٹکٹ ہے۔

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

معاہدے سے ہر پلیٹ فارم کے لیے ایک آرٹیفیکٹ بنائیں

Windows VPNv2 پروفائل لیتا ہے، جو MDM کے ذریعے دی جاتی ہے یا Add-VpnConnection اور اس کے XML پے لوڈ کے ساتھ مقامی طور پر بنائی جاتی ہے۔ جو چیز کاٹتی ہے وہ دائرہ کار اور اعتماد ہے۔ ڈیوائس دائرہ کار والی پروفائل اور صارف دائرہ کار والی پروفائل مختلف اسٹورز میں انسٹال ہوتی ہیں، اس لیے کلائنٹ کو درکار سرٹیفکیٹ اسی اسٹور میں ہونا چاہیے جو آپ کے چنے دائرہ کار سے میل کھاتا ہو۔ یہ جوڑا غلط ہونے پر ایسی پروفائل ملتی ہے جو صاف طور پر درآمد ہوتی ہے اور پھر پہلے کنکشن پر ناکام ہو جاتی ہے۔

macOS میں منظم VPN پے لوڈ والی کنفیگریشن پروفائل ہوتی ہے، جسے دستخط کر کے MDM سے تقسیم کیا جاتا ہے یا پائلٹ کے لیے ہاتھ سے انسٹال کیا جاتا ہے۔ شناخت اور CA زنجیر الگ الگ پے لوڈ کے طور پر سفر کرتی ہیں، اسی لیے کوئی پروفائل بغیر شکایت انسٹال ہو کر بھی کنیکٹ کے وقت ناکام ہو سکتی ہے۔ پے لوڈ کی فہرست جانچیں، صرف انسٹال کا نتیجہ نہیں۔

Linux، NetworkManager کے پیچھے والے بیک اینڈ پر منحصر ہے، اور strongSwan اور NetworkManager پلگ ان الگ پیکجز ہیں۔ کنکشن کی خصوصیات پلگ ان کے مخصوص ہیں، عام VPN چابیاں نہیں، اس لیے کسی دوسرے پلگ ان سے نقل کی گئی چابی اکثر بغیر خرابی محفوظ ہو جاتی ہے اور پھر فعال ہونے پر ناکام ہو جاتی ہے۔ کنکشن کو صاف امیج پر بنائیں تاکہ تصدیق ہو سکے کہ پلگ ان وہیں ہے جہاں وہ واقعی چلے گا۔

تینوں آرٹیفیکٹ فارمیٹ میں مختلف ہیں، لیکن ہر ایک وہی پانچ معاہدے کی سطریں انکوڈ کرتا ہے۔ یہی جانچ ہے کہ کوئی آرٹیفیکٹ مکمل ہے یا نہیں: ہر سطر کہیں نہ کہیں موجود ہے، اور راستے میں کوئی اضافی چیز ایجاد نہیں کی گئی۔

صاف اکاؤنٹ پر راستے، ریزالور اور دوبارہ کنکشن کی تصدیق کریں

جڑا ہونا قبولیت کی جانچ نہیں ہے۔ Windows پر Get-VpnConnection پروفائل دکھاتا ہے اور route print بتاتا ہے کہ نجی سابقہ سرنگ انٹرفیس پر اترا یا نہیں۔ macOS پر scutil --nc list فعال سروس کی تصدیق کرتا ہے جبکہ scutil --dns وہ ریزالور ترتیب دکھاتا ہے جو سسٹم واقعی استعمال کرے گا۔

Linux پر nmcli connection show --active ثابت کرتا ہے کہ کنکشن چل رہا ہے اور resolvectl status فی لنک DNS دکھاتا ہے۔ کنکشن فائل میں موجود مگر فی لنک آؤٹ پٹ میں غائب ریزالور کا مطلب ہے کہ منقسم DNS لاگو نہیں ہو رہا۔ یہی فرق ہے نام حل ہونے اور نام سرنگ سے حل ہونے کے درمیان، اور یہ بدلتا ہے کہ اگلا قدم کس معاون ٹیم کے پاس ہے۔ فی لنک آؤٹ پٹ کا موازنہ کنکشن اٹھنے سے پہلے اور بعد میں کریں، صرف بعد میں نہیں۔

پوری جانچ ایک نئے اکاؤنٹ سے کریں، جس میں کوئی کیش شدہ اسناد نہ ہوں اور منتظم کا نصب کردہ کوئی سرٹیفکیٹ نہ ہو۔ پھر معطلی اور بحالی کے بعد دہرائیں، اور اسناد دوبارہ درج کرنے پر مجبور کرنے کے بعد ایک بار پھر۔ یہ دو تبدیلیاں ان زیادہ تر دوبارہ کنکشن ناکامیوں کو سامنے لاتی ہیں جو پہلا کنکشن کبھی نہیں دکھاتا۔

پیکج کو ورژن دیں اور واپسی کا راستہ رکھیں

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

ہر پلیٹ فارم کا پچھلا پیکج قابل حصول رکھیں اور اس کے ساتھ ہٹانے کا کمانڈ لکھیں۔ VPN پروفائل ہٹانا Windows، macOS یا Linux پر اسے نصب کرنے کی آئینہ تصویر نہیں ہے، اور فرق بدترین وقت پر سامنے آتے ہیں۔ کسی فالتو ڈیوائس پر ایک بار ہٹانے کی مشق کریں تاکہ محفوظ شدہ دستاویز منصوبہ بنے، امید نہیں۔