هیچ همتای ورودی روی نود بیت‌کوین شما پشت VPN نیست؟

نود شما همگام شده است، 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 کور در شبکه اصلی 8333 است، اما ارائه‌دهنده می‌تواند پورت عمومی متفاوتی و مقصد متفاوتی در سمت کلاینت به شما بدهد. نشانی عمومی، پورت بیرونی و جایی که ارائه‌دهنده واقعاً ترافیک را تحویل می‌دهد بنویسید. سپس تأیید کنید که طرح و حساب شما اصلاً اتصال ورودی را مجاز می‌دانند، چون یک نشانی خروج اختصاصی قرارداد انتقال پورت نیست.

همین تمایز کسانی را که با انتظار دسترس‌پذیری یک IP ثابت می‌خرند گرفتار می‌کند. پایدار بودن نشانی هیچ چیزی درباره این که ارائه‌دهنده پورت ورودی را به نشست شما هدایت می‌کند یا نه نمی‌گوید.

پیش از بررسی ارائه‌دهنده، شنونده را بررسی کنید

کور باید روی نشانی و پورتی که نگاشت به آن تحویل می‌دهد گوش کند و فایروال میزبان باید آن را مجاز کند. اگر نود در یک کانتینر یا روی ماشین دیگری در LAN اجرا می‌شود، پرش بعدی و مسیر پاسخ آن هم بخشی از زنجیره است.

یک قاعده فایروال محلی نمی‌تواند در ارائه‌دهنده‌ای که بسته‌های ورودی را دور می‌ریزد نگاشت بسازد، و نگاشت ارائه‌دهنده نمی‌تواند به فرآیندی که فقط به loopback متصل است برسد. هر دو نیمه باید روی یک تاپل توافق کنند، به همین دلیل گام اول نوشتن تاپل است، نه حدس زدن آن.

نقطه پایانی اعلام‌شده را با نگاشت فعلی هماهنگ نگه دارید. نشانی ثابت باعث نمی‌شود پورت تخصیص‌یافته یا اجاره آن در میان اتصال‌های مجدد دائمی بماند، پس نقطه پایانی که ماه‌ها پیش منتشر شده ممکن است اکنون به هیچ‌چیز اشاره نکند. پس از هر اتصال مجدد صفحه ارائه‌دهنده را دوباره بخوانید و با آنچه نود شما اعلام می‌کند مقایسه کنید. اگر پورت جابه‌جا شده باشد، نقطه پایانی قدیمی اکنون یا مال هیچ‌کس نیست یا مال کس دیگری است.

پرچم ورودی را بخوانید، نه مجموع اتصال‌ها را

از یک زمینه RPC محلی مجاز، این پرس‌وجوی فقط‌خواندنی همتایان را فهرست می‌کند:

bitcoin-cli getpeerinfo

مرجع RPC inbound را برای اتصال ورودی true و برای اتصال خروجی false تعریف می‌کند. به آن فیلد نگاه کنید. مجموع بالای ده هیچ چیزی درباره جهت اثبات نمی‌کند، و مجموع‌ها و دسته‌ها هم با پیکربندی و نسخه تغییر می‌کنند.

سپس نقطه پایانی نگاشت‌شده را از بیرون با یک بررسی دسترس‌پذیری تازه که مجاز به اجرای آن هستید آزمایش کنید و ببینید همتای ورودی متناظری ظاهر می‌شود یا نه. مراقب خروجی‌ای که در یک رشته پشتیبانی می‌چسبانید باشید: نشانی همتایان جزئیات اتصال دیگران است و لازم نیست برای پاسخ گرفتن به پرسش شما منتشر شود.

آن را با افشای RPC حل نکنید

مستندات RPC بیت‌کوین کور صریحاً نسبت به افشای رابط RPC در اینترنت عمومی هشدار می‌دهد. اتصال همتایان و مدیریت احراز هویت‌شده دو سرویس متفاوت‌اند، و دسترس‌پذیر کردن P2P با انتشار RPC یک مشکل اتصال را با مشکلی بسیار بدتر معاوضه می‌کند.

اگر ترجیح می‌دهید اصلاً به P2P ورودی وابسته نباشید، سرویس onion جایگزین مستند است و پیش‌نیازهای خودش را دارد: دسترس بودن Tor، پیکربندی احراز هویت کنترل و تنظیمات شنیدنی که ایجاد سرویس را ممکن کند. به صرف این که VPN در حال اجراست ظاهر نمی‌شود.

کنار گذاشتن کور از VPN طرح سومی است و برای بعضی اپراتورها مشروع، اما ترافیک همتایان را روی اتصال معمولی شما می‌گذارد. این دسترسی ورودی از طریق VPN نیست، و روتر یا NAT بالادستی ممکن است هنوز به ورودی مجاز خودش نیاز داشته باشد. پیش از تغییر هر چیز دیگری مشخص کنید کدام یک از این سه را واقعاً آزمایش می‌کنید.