macOS پر OpenVPN TAP: ڈی بگ کرنے سے پہلے کلائنٹ کی جانچ کریں

ایک پرانا پروفائل جدید Mac پر آتا ہے، کلائنٹ اسے بغیر کسی شکایت کے درآمد کرتا ہے، اور کنکشن ٹوٹ جاتا ہے یا ٹریفک کبھی نہیں گزرتا۔ سرٹیفکیٹ پر پوری دوپہر صرف کرنے سے پہلے پروفائل میں ڈیوائس لائن پڑھیں۔ اگر وہاں dev tap لکھا ہے، تو آپ کلائنٹ سے Ethernet طرز کا انٹرفیس مانگ رہے ہیں، اور macOS پر ایسے زیادہ تر سیشن اسی درخواست پر ختم ہوتے ہیں۔

مرحلہ 1: تصدیق کریں کہ پروفائل واقعی TAP مانگتا ہے

پروفائل کا نام بدلتا ہے، لپٹا جاتا ہے اور دوبارہ برآمد ہوتا ہے، اس لیے وہی فائل دیکھیں جو آپ نے واقعی درآمد کی۔ ڈیوائس کی ہدایت اور کوئی بھی include تلاش کریں جو اسے اوور رائیڈ کر سکے۔ زیادہ تر معاملات میں آؤٹ پٹ کی دو لائنیں سوال طے کر دیتی ہیں۔ جب dev اور dev-type دونوں نظر آئیں، تو بعد والی ہدایت جیتتی ہے، اور کاپی شدہ پروفائل بالکل ایسی ہی تفصیل چھپاتا ہے۔

grep -nE "^[[:space:]]*(dev|dev-type)[[:space:]]" client.ovpn
ls -l ~/Library/Application\ Support/ 2>/dev/null

اگر فائل میں dev tap یا dev tap0 ہے، تو کلائنٹ کو TAP انٹرفیس نافذ کرنا ہوگا۔ اگر اس میں dev tun ہے، تو اس مضمون کا باقی حصہ لاگو نہیں ہوتا اور خرابی کہیں اور ہے۔

کلائنٹ کا نام اور ورژن، macOS کا ورژن اور پروفائل کہاں سے آیا، لکھ لیں۔ یہ تین حقائق طے کرتے ہیں کہ نیچے دیے گئے دو راستوں میں سے کون سا ممکن بھی ہے۔

مرحلہ 2: جانیں کہ ڈیوائس موڈ واقعی کیا بدلتا ہے

TUN انٹرفیس IP پیکٹ لے کر جاتا ہے۔ کلائنٹ IP ساتھی کو بھیجے گئے پیکٹ پڑھتا اور لکھتا ہے، اور آپریٹنگ سسٹم انہیں کسی بھی دوسرے انٹرفیس کی طرح روٹ کرتا ہے۔

TAP انٹرفیس Ethernet فریم لے کر جاتا ہے، جن میں براڈکاسٹ اور ARP بھی شامل ہیں۔ یہی برج والے سرور کو DHCP کے ذریعے پتے تقسیم کرنے اور کلائنٹ کو چیخ کر ڈیوائس تلاش کرنے دیتا ہے، اور اسی لیے کچھ پرانے ڈیزائن اس پر انحصار کرتے ہیں۔

قیمت یہ ہے کہ TAP کو ایسا ڈرائیور چاہیے جو سسٹم کو Ethernet انٹرفیس دکھائے۔ Apple نے وہ کرنل ایکسٹینشن ماڈل بند کر دیا ہے جس پر پرانے Mac TAP ڈرائیور انحصار کرتے تھے، اور اس کا متبادل API ان کلائنٹس میں جادوئی طور پر ظاہر نہیں ہوتا جنہیں کبھی اسے استعمال کرنے کے لیے اپ ڈیٹ نہیں کیا گیا۔ پلیٹ فارم کی صلاحیت اور بھیجی گئی مصنوع دو مختلف چیزیں ہیں۔

مرحلہ 3: موافق کلائنٹ اور مائیگریشن کے درمیان چنیں

دو ایماندار راستے ہیں۔ پہلا ایسا کلائنٹ ہے جس کا ناشر آپ کے macOS ورژن اور ہارڈویئر کے لیے اعلان کرتا ہے کہ وہ آپ کی مطلوبہ TAP ترتیب کی حمایت کرتا ہے۔ چار سال پرانی فورم پوسٹ نہیں، اور محفوظ شدہ انسٹالر نہیں: موجودہ اعلان اور ایک آزمائشی کنکشن۔

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

جو کام نہیں کرتا وہ یہ ہے کہ اپنی مقامی کاپی میں tap کو tun بنا کر امید کریں۔ سرور اب بھی برج کر رہا ہے، کلائنٹ اب IP بولتا ہے، اور کچھ بھی میل نہیں کھاتا۔

مرحلہ 4: چلتی سروس بدلنے سے پہلے حقائق جمع کریں

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

گیٹ وے کے مالک سے تین سوال پوچھیں۔ سرور برج والی ٹوپولوجی پر چل رہا ہے یا روٹ شدہ؟ کون سے دور دراز پریفکس قابل رسائی ہونے چاہئیں؟ اور کیا کنفیگریشن تبدیلی کے لیے دیکھ بھال کا وقت ہے، یا سرور کو چھوئے بغیر کام کرنے کی توقع ہے؟

ان کے جوابات طے کرتے ہیں کہ آپ آج دوپہر کلائنٹ کا مسئلہ حل کر رہے ہیں یا اگلے ہفتے نیٹ ورک کی تبدیلی کا منصوبہ بنا رہے ہیں۔

مرحلہ 5: دونوں سروں سے مائیگریشن کی تصدیق کریں

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

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

ایک بار دوبارہ جڑ کر اور ایک بار ری بوٹ کر کے ختم کریں، کیونکہ صرف پہلی کوشش میں چلنے والا پروفائل عام طور پر یہ بتاتا ہے کہ دھکیلے گئے روٹ یا DNS سیٹنگ دوبارہ جڑنے پر لاگو نہیں ہوتی۔

جب پھر بھی ناکام ہو، تو پہلی غلطی پڑھیں

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

متبادل ثابت ہونے تک اصل پروفائل اور چلتی کنفیگریشن رکھیں۔ کلائنٹ تبدیلی واپس لینا تیز ہے؛ کسی کے اندازے پر توڑا گیا برج والا نیٹ ورک دوبارہ بنانا ایسا نہیں ہے۔