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

پتہ لکھنے سے پہلے فیلڈ کی قسم جانچیں

مثال کے طور پر، WireGuard Endpoint فیلڈ میں پورٹ والا IPv6 لٹریل پتے کے گرد بریکٹ استعمال کرتا ہے، جیسے [2001:db8::10]:51820 میں۔ اس مثال کا دستاویزی سابقہ عوامی سرور نہیں ہے، اور بریکٹ نحو کا حصہ ہیں، پتے کا نہیں۔

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

جب پورٹ وہی فیلڈ بانٹے تو لٹریل بریکٹ میں رکھیں

یاد رکھنے والا قاعدہ سادہ ہے: بریکٹ تب آتے ہیں جب اسی تار میں پورٹ آگے آئے۔ جب پتہ بغیر پورٹ والے فیلڈ میں تنہا ہو تو وہ نہیں آتے۔

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

پتہ اور پورٹ فیلڈ الگ کریں

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

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

زون شناخت کنندگان کو احتیاط سے سنبھالیں

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

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

پہلے تجزیہ، پھر رسائی جانچیں

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

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

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

متعلقہ مضامین