Няма ўваходных піраў на вашым вузле Bitcoin за 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 усё яшчэ можа спатрэбіцца ўласны дазволены запіс. Вызначце, які з трох варыянтаў вы насамрэч правяраеце, перш чым змяняць што-небудзь яшчэ.