VPN-এর পেছনে আপনার Bitcoin নোডে কোনো ইনবাউন্ড পিয়ার নেই?

আপনার নোড সিঙ্ক হয়েছে, VPN সংযুক্ত বলছে, আর getpeerinfo আট বা দশটি পিয়ার দেখাচ্ছে। তাদের কারও inbound true-তে সেট নেই। এই সমন্বয়টি স্বাভাবিক এবং এটি কোনো ত্রুটি নয়: আউটবাউন্ড সংযোগ প্রমাণ করে নোডটি অন্যদের কাছে পৌঁছাতে পারে, কিন্তু সেগুলোর কিছুই প্রমাণ করে না যে কেউ আপনার কাছে পৌঁছাতে পারে। লক্ষ্য যদি VPN-এর মাধ্যমে ইনবাউন্ড P2P সংযোগ গ্রহণকারী নোড হয়, তবে সেই দিকটি আলাদাভাবে পরীক্ষা করতে হবে।

পিয়ার থেকে আপনার লিসেনার পর্যন্ত প্যাকেটটি অনুসরণ করুন

ইনবাউন্ড P2P চারটি জিনিসের একটি শৃঙ্খল, আর এটি সবচেয়ে দুর্বল কড়িতে ব্যর্থ হয়, সবচেয়ে আকর্ষণীয় কড়িতে নয়।

other peer
  -> provider's public address and assigned port
  -> the permitted VPN mapping
  -> Bitcoin Core's P2P listener

Core-এর মেইননেটে P2P ডিফল্ট 8333, তবে প্রোভাইডার আপনাকে ভিন্ন পাবলিক পোর্ট ও ভিন্ন ক্লায়েন্ট-সাইড গন্তব্য দিতে পারে। পাবলিক ঠিকানা, এক্সটার্নাল পোর্ট এবং প্রোভাইডার আসলে কোথায় ট্রাফিক পৌঁছায় তা লিখে রাখুন। তারপর নিশ্চিত করুন যে আপনার প্ল্যান ও অ্যাকাউন্ট আদৌ ইনবাউন্ড সংযোগের অনুমতি দেয়, কারণ ডেডিকেটেড এক্সিট ঠিকানা কোনো পোর্ট-ফরওয়ার্ডিং চুক্তি নয়।

এই পার্থক্যটিই তাদের ধরে যারা পৌঁছানোযোগ্যতার আশায় স্ট্যাটিক IP কেনে। ঠিকানাটি স্থির থাকা এ কথা বলে না যে প্রোভাইডার আপনার সেশনে একটি ইনবাউন্ড পোর্ট ফরওয়ার্ড করছে কি না।

প্রোভাইডার যাচাই করার আগে লিসেনার যাচাই করুন

ম্যাপিং যে ঠিকানা ও পোর্টে পৌঁছায়, Core-কে সেখানেই শুনতে হবে এবং হোস্ট ফায়ারওয়ালকে তা অনুমতি দিতে হবে। নোডটি যদি কনটেইনারে বা অন্য কোনো LAN মেশিনে চলে, তবে পরের হপ ও তার রিপ্লাই রুটও শৃঙ্খলে অন্তর্ভুক্ত।

যে প্রোভাইডার ইনকামিং প্যাকেট ফেলে দেয়, সেখানে লোকাল ফায়ারওয়াল নিয়ম কোনো ম্যাপিং তৈরি করতে পারে না, আর প্রোভাইডারের ম্যাপিং কেবল loopback-এ বাঁধা কোনো প্রসেস পর্যন্ত পৌঁছাতে পারে না। দুই অর্ধেককেই একই টাপলে একমত হতে হবে, তাই প্রথম ধাপ হলো টাপলটি অনুমান না করে লিখে রাখা।

বিজ্ঞাপিত এন্ডপয়েন্টকে লাইভ ম্যাপিংয়ের সঙ্গে সামঞ্জস্যপূর্ণ রাখুন। স্ট্যাটিক ঠিকানা নির্ধারিত পোর্ট বা তার লিজকে পুনঃসংযোগের মধ্যে স্থায়ী করে না, তাই মাসখানেক আগে প্রকাশ করা এন্ডপয়েন্ট এখন কোনো কিছুতে নির্দেশ নাও করতে পারে। যেকোনো পুনঃসংযোগের পর প্রোভাইডারের পৃষ্ঠাটি আবার পড়ুন এবং আপনার নোড যা বিজ্ঞাপন করছে তার সঙ্গে তুলনা করুন। পোর্ট সরে গেলে পুরোনো এন্ডপয়েন্ট এখন হয় কারও নয়, নয়তো অন্য কারও।

ইনবাউন্ড ফ্ল্যাগ পড়ুন, সংযোগের মোট সংখ্যা নয়

একটি অনুমোদিত লোকাল RPC প্রসঙ্গ থেকে এই শুধু-পড়ার কোয়েরিটি পিয়ারদের তালিকা করে:

bitcoin-cli getpeerinfo

RPC রেফারেন্স inbound বলতে ইনকামিং সংযোগের জন্য true এবং আউটগোয়িংয়ের জন্য false বোঝায়। ওই ফিল্ডটি দেখুন। দশের বেশি মোট সংখ্যা দিক সম্পর্কে কিছুই প্রমাণ করে না, আর মোট ও শ্রেণিবিভাগ কনফিগারেশন ও রিলিজের সঙ্গে বদলাতেই থাকে।

তারপর যে ম্যাপ করা এন্ডপয়েন্ট আপনি চালানোর অনুমতি রাখেন এমন নতুন পৌঁছানোযোগ্যতা যাচাই দিয়ে বাইরে থেকে পরীক্ষা করুন এবং দেখুন সংশ্লিষ্ট কোনো ইনবাউন্ড পিয়ার দেখা যায় কি না। সাপোর্ট থ্রেডে যে আউটপুট পেস্ট করবেন সেখানে সতর্ক থাকুন: পিয়ার ঠিকানাগুলো অন্য মানুষের সংযোগের বিবরণ, আপনার প্রশ্নের উত্তর পেতে সেগুলো প্রকাশ করার দরকার নেই।

RPC প্রকাশ করে এটি সমাধান করবেন না

Bitcoin Core-এর RPC ডকুমেন্টেশন প্রকাশ্য ইন্টারনেটে RPC ইন্টারফেস প্রকাশের বিরুদ্ধে স্পষ্টভাবে সতর্ক করে। পিয়ার সংযোগ ও প্রমাণীকৃত প্রশাসন আলাদা সেবা, আর RPC প্রকাশ করে P2P পৌঁছানোযোগ্য বানানো একটি সংযোগ সমস্যার বদলে আরও খারাপ সমস্যা ডেকে আনে।

আপনি যদি ইনবাউন্ড P2P-এর ওপর আদৌ নির্ভর করতে না চান, তবে ডকুমেন্টেড বিকল্প হলো একটি onion সেবা, যার নিজস্ব পূর্বশর্ত আছে: Tor উপলব্ধ থাকা, কন্ট্রোল প্রমাণীকরণ কনফিগার করা এবং এমন লিসেনিং সেটিংস যা সেবাটি তৈরি হতে দেয়। VPN চলছে বলেই সেটি দেখা যায় না।

VPN থেকে Core বাদ দেওয়া তৃতীয় একটি ডিজাইন এবং কিছু অপারেটরের জন্য বৈধ, কিন্তু এটি পিয়ার ট্রাফিককে আপনার সাধারণ সংযোগে ফেলে দেয়। এটি VPN-এর মাধ্যমে ইনবাউন্ড অ্যাক্সেস নয়, আর রাউটার বা আপস্ট্রিম NAT-এর এখনও নিজস্ব অনুমোদিত এন্ট্রি লাগতে পারে। অন্য কিছু বদলানোর আগে স্থির করুন আপনি আসলে তিনটির কোনটি পরীক্ষা করছেন।