На вашому вузлі Bitcoin за VPN немає вхідних пірів?
Вихідні піри та синхронізований ланцюг не доводять вхідної доступності. Перевірте відображення, слухач і прапорець inbound, перш ніж звинувачувати 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 у Core в основній мережі — 8333, але провайдер може видати інший публічний порт та інше призначення на боці клієнта. Запишіть публічну адресу, зовнішній порт і місце, куди провайдер насправді доставляє трафік. Потім підтвердьте, що ваш тариф і обліковий запис узагалі дозволяють вхідні з'єднання, бо виділена вихідна адреса — це не договір про проброс портів.
Ця різниця ловить тих, хто купує статичну IP, сподіваючись на доступність. Стабільність адреси нічого не каже про те, чи пробрасує провайдер вхідний порт у вашу сесію.
Спочатку перевірте слухач, потім провайдера
Core має слухати на адресі й порту, куди доставляє відображення, а брандмауер хоста має це дозволяти. Якщо вузол працює в контейнері або на іншій машині в LAN, наступний перехід і маршрут відповіді теж входять до ланцюга.
Локальне правило брандмауера не може створити відображення в провайдера, який відкидає вхідні пакети, а відображення провайдера не дістане до процесу, прив'язаного лише до loopback. Обидві половини мають зійтися на одному кортежі, тому перший крок — записати кортеж, а не вгадувати його.
Тримайте оголошену кінцеву точку відповідно до поточного відображення. Статична адреса не робить призначений порт чи його оренду постійними між перепідключеннями, тож кінцева точка, опублікована місяці тому, може тепер не вказувати нікуди. Перечитайте сторінку провайдера після кожного перепідключення і порівняйте з тим, що оголошує ваш вузол. Якщо порт змістився, стара кінцева точка тепер або нічия, або чужа.
Читайте прапорець входу, а не загальну кількість з'єднань
З авторизованого локального контексту RPC цей запит лише для читання перелічує пірів:
bitcoin-cli getpeerinfo
Довідник RPC визначає inbound як true для вхідного з'єднання і false для вихідного. Подивіться на це поле. Загальна кількість понад десять нічого не доводить про напрямок, а суми й категорії все одно змінюються з конфігурацією та версією.
Потім перевірте відображену кінцеву точку ззовні новою перевіркою доступності, яку вам дозволено запускати, і подивіться, чи з'явиться відповідний вхідний пір. Будьте обережні з виводом, який вставляєте в тему підтримки: адреси пірів — це дані про з'єднання інших людей, і їх не потрібно публікувати, щоб вам відповіли.
Не вирішуйте це розкриттям RPC
Документація RPC Bitcoin Core прямо попереджає проти розкриття інтерфейсу RPC у публічний інтернет. З'єднання з пірами й автентифіковане адміністрування — різні сервіси, і робити P2P доступним, публікуючи RPC, означає міняти проблему зв'язності на значно гіршу.
Якщо ви волієте взагалі не залежати від вхідного P2P, документована альтернатива — служба onion, і вона має власні передумови: доступний Tor, налаштована автентифікація керування і параметри прослуховування, які дозволяють створити службу. Вона не з'являється лише тому, що випадково працює VPN.
Виключення Core з VPN — це третій варіант, і для деяких операторів він законний, але він переносить трафік пірів на ваше звичайне з'єднання. Це не вхідний доступ через VPN, і маршрутизатору або верхньому NAT усе ще може знадобитися власний дозволений запис. Перш ніж щось інше змінювати, визначте, який із трьох варіантів ви насправді перевіряєте.