Pi VPN سرور: ترکیب سے نہیں، فون کی ایپ سے شروع کریں

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

وہ ترتیب جو دوبارہ تعمیر سے بچاتی ہے

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

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

ایپ طے ہونے کے بعد سرور کا انتخاب تنگ ہو جاتا ہے اور باقی تعمیر کا ایک ہدف ہوتا ہے۔

فون کی ایپ دراصل کیا نافذ کرتی ہے

شائع شدہ کلائنٹ فہرست کسی سروس نہیں بلکہ ایپلیکیشن کی وضاحت کرتی ہے۔ Android کے لیے OpenVPN Connect ایپ OpenVPN سرور کی توقع رکھتی ہے؛ یہ سرور کا پہلو فراہم نہیں کرتی۔ پروفائل مشابہ دکھنے پر یہ IPsec یا L2TP کلائنٹ بھی نہیں بنتی۔

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

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

چار حصوں کا معاہدہ

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

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

اسناد کے الگ کام ہیں

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

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

پروفائل ہاتھ سے جوڑنے کے بجائے سروس کے معاون برآمد اور درآمد کے عمل کو استعمال کریں۔ ہاتھ سے بنائے گئے پروفائل عام طور پر صرف ڈیسک ٹاپ کے لیے ہدایات رکھتے ہیں جنہیں موبائل ایپ نظر انداز یا مسترد کرتی ہے۔

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

رسائی ایک الگ معاہدہ ہے

فون کو سرور کے بیرونی اینڈ پوائنٹ تک حقیقی اپ اسٹریم ترتیب کے ذریعے پہنچنا ہوگا۔ گھریلو راؤٹر کا ترجمہ، فلٹرنگ اور آپریٹر کا NAT سب دونوں کے درمیان ہیں۔ متحرک DNS نام اینڈ پوائنٹ کو صرف ایک مستحکم نام دیتا ہے; یہ اندر آنے والا راستہ نہیں بناتا۔

پھر طے کریں کہ جڑنے کے بعد کلائنٹ کہاں تک پہنچ سکتا ہے: نجی سابقے یا مکمل انٹرنیٹ اخراج، ان کے آگے بھیجنے اور جواب کے راستے، DNS کا رویہ، اور کیا IPv6 دائرے میں ہے۔ کامیاب لاگ ان ان میں سے کچھ بھی ثابت نہیں کرتا۔

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