N2N ওভারলে কোনো প্রক্সি নয়: দুটি সংযোগই আঁকুন

Firefox 127.0.0.1:8000-এ ইশারা করে, N2N প্রান্ত চালু আছে, পিয়ার তার ওভারলে ঠিকানায় ping-এর উত্তর দেয়, তবুও ব্রাউজার জানায় যে প্রক্সি সংযোগটি প্রত্যাখ্যান করেছে। এই শৃঙ্খলে কোনো অসঙ্গতি নেই। একটি ওভারলে হোস্টকে ব্যক্তিগত নেটওয়ার্কে পৌঁছানোর মতো ঠিকানা দেয়; এটি প্রক্সি প্রোটোকল বলতে পারে এমন কোনো প্রক্রিয়া তৈরি করে না। ব্রাউজার পিয়ারের দিকে রুট চাইছে না। এটি স্থানীয় লিসেনার চাইছে।

এখানে দুটি সংযোগ গুলিয়ে ফেলা হচ্ছে, আর সেগুলো আলাদা করে আঁকলে বেশিরভাগ বিভ্রান্তি এক মিনিটেই পরিষ্কার হয়।

দুটি সংযোগ, একটি নয়

প্রথম সংযোগটি ব্রাউজার থেকে loopback পোর্টে যেটি শোনে সেখানে চলে। এটি একটি স্থানীয় সকেট, এবং যদি এর মালিক কেউ না থাকে, তবে একটি প্যাকেটও N2N-এ পৌঁছানোর আগেই সংযোগটি প্রত্যাখ্যাত হয়। দ্বিতীয়টি প্রক্সি প্রক্রিয়া থেকে তার আনা উৎসের দিকে চলে। সেই পথটি প্রক্সি হোস্টের রাউটিং টেবিল বেছে নেয়, এবং সেটি সাধারণ আপলিংক, অন্য টানেল, বা ওভারলের সঙ্গে কোনো সম্পর্কহীন নীতি-রুট হতে পারে।

পিয়ারকে ping করা প্রমাণ করে ওভারলে প্রান্ত-ঠিকানার মধ্যে প্যাকেট পৌঁছাতে পারে। এটি 8000 পোর্টে লিসেনার সম্পর্কে কিছুই প্রমাণ করে না, এবং সেই হোস্ট উৎসে পৌঁছাতে পারে কি না তাও নয়। আলাদা ব্যর্থতা, আলাদা সমাধান।

লিসেনার কোথায় থাকতে হবে

127.0.0.1-এ বাইন্ড করা প্রক্সি ইচ্ছাকৃতভাবে স্থানীয়: এটি কেবল যে মেশিনে চলে সেখান থেকেই সংযোগ গ্রহণ করে। ব্যক্তিগত প্রক্সির জন্য এটি সঠিক ডিফল্ট, আর ওভারলে জুড়ে ভাগ করে নেওয়ার জন্য ভুল আকৃতি। ওভারলে পিয়ারদের সেবা দিতে হলে হয় ওভারলে ইন্টারফেসে একটি বাইন্ড ঠিকানা, নয়তো একটি ফরওয়ার্ডিং উপাদান দরকার যা loopback সংযোগ শেষ করে তা রিলে করে। যেভাবেই হোক, কোন ওভারলে উৎসগুলো সেবাটি ব্যবহার করতে পারবে তা স্পষ্ট নীতি দিয়ে ঠিক করা উচিত, কারণ ভাগ করা নেটওয়ার্কে খোলা প্রক্সি মানে আমন্ত্রণ।

কনফিগারেশন ফাইলের পরিবর্তে সকেট তালিকা দিয়ে প্রকৃত বাইন্ড পরীক্ষা করুন। ওভারলে ওঠার আগে চালু হওয়া ডেমন এমন ঠিকানায় বাঁধা থাকতে পারে যা আর নেই।

localhost পিয়ার নয়

ব্রাউজারের প্রক্সি ক্ষেত্রে localhost ব্রাউজারের নিজের মেশিনকে বোঝায়। এটি প্রান্ত নয়, সুপারনোড নয়, এবং টানেলের দূরবর্তী প্রান্তের হোস্টও নয়। যদি প্রক্সি অন্য পিয়ারে চলে, তবে সেই পিয়ারের পৌঁছানোযোগ্য ওভারলে ঠিকানা ও পোর্ট ক্ষেত্রটিতে দিন, তারপর নিশ্চিত করুন যে লিসেনার আপনার প্রান্ত-ঠিকানা থেকে সংযোগ গ্রহণ করে।

সুপারনোডগুলো প্রান্তদের একে অপরকে খুঁজে পেতে সাহায্য করে; তারা প্রক্সি সেবা নয়। সুপারনোড ঠিকানাকে প্রক্সি এন্ডপয়েন্ট হিসেবে গণ্য করলে একই প্রত্যাখ্যান পাওয়া যায়, সঙ্গে বাড়তি এক ধাপ বিভ্রান্তি।

একটি রুট হ্যান্ডশেক করতে পারে না

ঠিকানা ঠিক থাকলেও, রাউটিং প্রক্সিং নয়। একটি HTTP প্রক্সি সংযোগ CONNECT অনুরোধ বা পরম-রূপ অনুরোধ লাইন দিয়ে শুরু হয়, আর SOCKS প্রক্সি শুরু হয় সংস্করণ ও পদ্ধতি নিয়ে দরকষাকষি দিয়ে। রাউটার বা ওভারলে বাইট এগিয়ে পাঠায়; এটি সেই বার্তাগুলো বিশ্লেষণ করে না বা আপনার হয়ে পরবর্তী সংযোগ খোলে না। এজন্যই ping ও SSH-এ কাজ করা রুট একটি ব্রাউজার প্রক্সির জন্য ব্যর্থ হতে পারে: ব্রাউজারের প্রয়োজন সহযোগী প্রক্রিয়া, কেবল পৌঁছানোযোগ্যতা নয়।

যদি লক্ষ্য শুধু পিয়ারের একটি সেবায় পৌঁছানো হয়, তবে প্রক্সি সেটিং সরিয়ে সেবাটির ওভারলে ঠিকানা সরাসরি ব্যবহার করুন।

সীমাগুলো ক্রম অনুসারে পরীক্ষা করুন

নিশ্চিত করুন ওভারলে ঠিকানা উত্তর দিচ্ছে, তারপর নিশ্চিত করুন কনফিগার করা পোর্টে লিসেনার আছে এবং তার বাইন্ড ঠিকানা লিখে রাখুন। একটি নিয়ন্ত্রিত অনুরোধ করুন এবং প্রক্সির লগ পড়ুন, যাতে বুঝতে পারেন ব্যর্থতা লিসেনারে না পরবর্তী আনে। সবশেষে, প্রক্সি হোস্টের রুট ও উৎসের জন্য DNS নীতি পরীক্ষা করুন।

N2N প্রকল্প প্রান্ত ও সুপারনোডকে ওভারলে উপাদান হিসেবে নথিভুক্ত করে। এটি প্রান্তকে অ্যাপ্লিকেশন প্রক্সিতে পরিণত করে না, এবং কোনো রাউটিং কনফিগারেশন এমন কোনো প্রোটোকল হ্যান্ডলার যোগ করে না যা কেউ চালু করেনি।