На вашем узле 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 всё ещё может понадобиться собственная разрешённая запись. Прежде чем менять что-то ещё, определите, какой из трёх вариантов вы на самом деле проверяете.

Похожие статьи