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

میپنگ ٹیبل ہی سب کچھ طے کرتی ہے

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

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

ملاقات کی سروس کیا کر سکتی ہے اور کیا نہیں

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

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

کیپ الائیو، ری بوٹ اور سرکتا اینڈ پوائنٹ

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

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

غائب فارورڈ کے گرد تین راستے

پہلا راستہ راؤٹر سے کہتا ہے کہ وہ خود اندراج بنائے، UPnP IGD، NAT-PMP یا PCP کے ذریعے، جب خصوصیت موجود ہو اور فعال ہو۔ دوسرا ٹریفک کو عوامی پتے والے ریلے کے سپرد کرتا ہے، جو ہمیشہ کام کرتا ہے اور ہمیشہ بینڈوتھ کے ساتھ ایک مختلف اعتماد کی حد خرچ کرتا ہے۔ تیسرا سمت الٹ دیتا ہے: اندرونی ہوسٹ عوامی سرور کی طرف باہر جانے والی ٹنل کھولتا ہے اور باقی سب اس کے اندر سوار ہوتا ہے۔

[Peer]
PublicKey = 6yGj3kQ2wVb8sTn1pLx4dRc7hZa9mKf2uYe5oNq0iXw=
Endpoint = relay.corp.internal:51820
PersistentKeepalive = 25
AllowedIPs = 10.44.0.0/24

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

حل کو راؤٹر کے مالک کے مطابق ڈھالیں

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

نوٹ کریں کہ آپ جس راستے پر پہنچے وہ سیدھا تھا یا ریلے کے ذریعے، کیونکہ یہی ایک حقیقت تاخیر اور ناکامی کے رویے دونوں کا اندازہ دیتی ہے۔ RFC 4787 ان سب کے نیچے میپنگ رویے کا حوالہ رہتا ہے، اور اس کا میپنگ حصہ پڑھنا تین حل ترتیب سے جانچنے سے تیز ہے۔ ٹیبل کو اس سے غرض نہیں کہ آپ نے کون سا اختیار چنا؛ وہ صرف درج کرتی ہے کہ اگلا پیکٹ کیا کر سکتا ہے۔

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