عقدتك متزامنة، ويقول VPN إنه متصل، و getpeerinfo يعرض ثمانية أو عشرة أقران. لا يوجد في أي منها inbound مضبوطًا على true. هذا المزيج طبيعي وليس عطلًا: الاتصالات الصادرة تثبت أن العقدة تستطيع الوصول إلى الآخرين، ولا شيء فيها يثبت أن أي أحد يستطيع الوصول إليك. وإذا كان الهدف عقدة تقبل اتصالات P2P الواردة عبر VPN، فعليك اختبار ذلك الاتجاه بمعزل عن غيره.

تتبَّع الحزمة من القرين إلى المستمع لديك

الـ P2P الوارد سلسلة من أربعة أشياء، وهو يفشل عند أضعف حلقة لا عند أكثرها إثارة.

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

القيمة الافتراضية لـ P2P على الشبكة الرئيسية في Core هي 8333، لكن المزوّد قد يمنحك منفذًا عامًا مختلفًا ووجهة مختلفة على جانب العميل. دوّن العنوان العام والمنفذ الخارجي والمكان الذي يسلّم فيه المزوّد حركة المرور فعليًا. ثم تأكد من أن خطتك وحسابك يسمحان أصلًا بالاتصالات الواردة، لأن عنوان خروج مخصصًا ليس عقد نقل منافذ.

هذا التمييز يوقع من يشترون عنوان IP ثابتًا توقعًا لقابلية الوصول. فكون العنوان مستقرًا لا يقول شيئًا عن قيام المزوّد بتمرير منفذ وارد إلى جلستك.

افحص المستمع قبل أن تفحص المزوّد

على Core أن يكون مستمعًا على العنوان والمنفذ الذي يسلّم إليه التعيين، وعلى جدار الحماية في المضيف أن يسمح بذلك. وإذا كانت العقدة تعمل في حاوية أو على جهاز آخر في الشبكة المحلية، فإن القفزة التالية ومسار ردها يدخلان في السلسلة أيضًا.

قاعدة جدار حماية محلية لا تستطيع إنشاء تعيين لدى مزوّد يُسقط الحزم الواردة، وتعيين المزوّد لا يستطيع الوصول إلى عملية مرتبطة بواجهة loopback فقط. على النصفين الاتفاق على نفس الصف، ولهذا فإن الخطوة الأولى هي تدوين الصف بدلًا من تخمينه.

حافظ على اتساق نقطة النهاية المعلنة مع التعيين الحالي. العنوان الثابت لا يجعل منفذًا مخصصًا أو عقد إيجاره دائمًا عبر عمليات إعادة الاتصال، لذا قد تشير نقطة نهاية نُشرت قبل أشهر إلى لا شيء الآن. أعد قراءة صفحة المزوّد بعد أي إعادة اتصال وقارنها بما تعلنه عقدتك. وإذا انتقل المنفذ، فإما ألا تكون نقطة النهاية القديمة لأحد أو أن تكون لشخص آخر.

اقرأ علم الاتصال الوارد، لا إجمالي الاتصالات

من سياق RPC محلي مصرّح به، يسرد هذا الاستعلام للقراءة فقط الأقران:

bitcoin-cli getpeerinfo

يعرّف مرجع RPC الحقل inbound بأنه true للاتصال الوارد وfalse للاتصال الصادر. انظر إلى ذلك الحقل. الإجمالي الذي يتجاوز عشرة لا يثبت شيئًا عن الاتجاه، كما أن الإجماليات والفئات تتغير مع الإعداد والإصدار على أي حال.

ثم اختبر نقطة النهاية المعيّنة من الخارج بفحص وصول جديد مصرّح لك بتشغيله، وانظر هل يظهر قرين وارد مطابق. كن حذرًا مع المخرجات التي تلصقها في موضوع دعم: عناوين الأقران هي تفاصيل اتصال تخص أشخاصًا آخرين، وليست بحاجة إلى النشر ليُجاب عن سؤالك.

لا تحلّها بكشف RPC

تحذّر وثائق RPC الخاصة بـ Bitcoin Core صراحةً من كشف واجهة RPC للإنترنت العام. اتصالات الأقران والإدارة الموثّقة خدمات مختلفة، وجعل P2P قابلًا للوصول عبر نشر RPC يقايض مشكلة اتصال بمشكلة أسوأ بكثير.

إن كنت تفضّل ألا تعتمد على P2P الوارد إطلاقًا، فإن خدمة onion هي البديل الموثّق، ولها متطلباتها المسبقة: توفّر Tor، وإعداد مصادقة التحكم، وإعدادات استماع تسمح بإنشاء الخدمة. وهي لا تظهر لمجرد أن VPN يعمل.

استثناء Core من VPN تصميم ثالث، وهو مشروع لبعض المشغّلين، لكنه يضع حركة الأقران على اتصالك العادي. وهذا ليس وصولًا واردًا عبر VPN، وقد يحتاج الموجّه أو NAT في المنبع إلى مدخله المصرّح به أيضًا. حدّد أيّ الثلاثة تختبره فعلًا قبل أن تغيّر أي شيء آخر.

مقالات ذات صلة