N2N اوورلے پروکسی نہیں ہے: دونوں کنکشن بنائیں

Firefox 127.0.0.1:8000 کی طرف اشارہ کرتا ہے، N2N کنارہ فعال ہے، ہم منصب اپنے اوورلے پتے پر ping کا جواب دیتا ہے، اور براؤزر اب بھی بتاتا ہے کہ پروکسی نے کنکشن سے انکار کیا۔ اس زنجیر میں کوئی تضاد نہیں۔ اوورلے میزبان کو نجی نیٹ ورک پر قابل رسائی پتہ دیتا ہے؛ یہ پروکسی پروٹوکول بولنے والا عمل نہیں بناتا۔ براؤزر ہم منصب کی طرف راستہ نہیں مانگ رہا۔ یہ مقامی سننے والا مانگ رہا ہے۔

یہاں دو کنکشنز کو خلط ملط کیا جا رہا ہے، اور انہیں الگ الگ کھینچنا زیادہ تر الجھن ایک منٹ میں واضح کر دیتا ہے۔

دو کنکشنز، ایک نہیں

پہلا کنکشن براؤزر سے اس چیز تک جاتا ہے جو loopback پورٹ پر سنتی ہے۔ یہ مقامی ساکٹ ہے، اور اگر اس کا کوئی مالک نہ ہو تو ایک پیکٹ بھی N2N تک پہنچنے سے پہلے کنکشن مسترد ہو جاتا ہے۔ دوسرا پروکسی عمل سے اس ماخذ تک جاتا ہے جو وہ لاتا ہے۔ وہ راستہ پروکسی میزبان کی روٹنگ ٹیبل چنتی ہے، اور یہ عام uplink، کوئی دوسری سرنگ، یا ایسی پالیسی راستہ ہو سکتا ہے جس کا اوورلے سے کوئی تعلق نہ ہو۔

ہم منصب کو ping کرنا ثابت کرتا ہے کہ اوورلے کنارے کے پتوں کے درمیان پیکٹ پہنچا سکتا ہے۔ یہ پورٹ 8000 پر سننے والے کے بارے میں کچھ ثابت نہیں کرتا، اور نہ یہ کہ وہ میزبان ماخذ تک پہنچ سکتا ہے۔ الگ ناکامیاں، الگ اصلاحات۔

سننے والا کہاں رہنا چاہیے

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

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

localhost ہم منصب نہیں ہے

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

سپرنوڈ کناروں کو ایک دوسرے کو ڈھونڈنے میں مدد دیتے ہیں؛ وہ پروکسی خدمت نہیں ہیں۔ سپرنوڈ پتے کو پروکسی اینڈ پوائنٹ سمجھنا وہی انکار اضافی الجھن کے قدم کے ساتھ دیتا ہے۔

راستہ handshake نہیں کر سکتا

پتہ درست ہونے پر بھی، روٹنگ پروکسی کرنا نہیں ہے۔ HTTP پروکسی کنکشن CONNECT درخواست یا مطلق شکل کی درخواست سطر سے شروع ہوتا ہے، اور SOCKS پروکسی ورژن اور طریقہ کی گفت و شنید سے شروع ہوتی ہے۔ روٹر یا اوورلے بائٹس آگے بھیجتا ہے؛ یہ ان پیغامات کا تجزیہ نہیں کرتا اور آپ کی طرف سے اگلا کنکشن نہیں کھولتا۔ اسی لیے ping اور SSH کے لیے کام کرنے والا راستہ براؤزر پروکسی کے لیے ناکام ہو سکتا ہے: براؤزر کو تعاون کرنے والا عمل درکار ہے، صرف رسائی نہیں۔

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

حدود کو ترتیب سے جانچیں

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

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