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 چل رہا ہے۔

Core کو VPN سے باہر رکھنا تیسرا ڈیزائن ہے، اور کچھ آپریٹرز کے لیے جائز ہے، لیکن یہ پیئر ٹریفک کو آپ کے عام کنکشن پر ڈال دیتا ہے۔ یہ VPN کے ذریعے اِن باؤنڈ رسائی نہیں ہے، اور راؤٹر یا اَپ اسٹریم NAT کو ابھی بھی اپنی اجازت شدہ انٹری کی ضرورت ہو سکتی ہے۔ کچھ اور بدلنے سے پہلے طے کریں کہ آپ واقعی تین میں سے کون سی جانچ رہے ہیں۔