Geen inkomende eweknieë op jou Bitcoin-node agter 'n VPN nie?

Uitgaande eweknieë en 'n gesinkroniseerde ketting bewys nie inkomende bereikbaarheid nie. Kontroleer die kartering, die luisteraar en die inkomende vlag voordat jy die VPN blameer.

Jou node is gesinkroniseer, die VPN sê dit is gekonnekteer, en getpeerinfo wys agt of tien eweknieë. Nie een van hulle het inbound op waar gestel nie. Daardie kombinasie is normaal en dit is nie 'n fout nie: uitgaande verbindings bewys dat die node ander kan bereik, en niks daaromtrent bewys dat enigiemand jou kan bereik nie. As die doel 'n node is wat inkomende P2P-verbindings deur 'n VPN aanvaar, moet jy daardie rigting op sy eie toets.

Volg die pakket van die eweknie na jou luisteraar

Inkomende P2P is 'n ketting van vier dinge, en dit faal by die swakste skakel eerder as by die interessantste een.

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

Core se hoofnet-P2P-verstek is 8333, maar die verskaffer kan vir jou 'n ander openbare poort en 'n ander kliëntkant-bestemming gee. Skryf die openbare adres, die eksterne poort en waar die verskaffer die verkeer werklik aflewer neer. Bevestig dan dat jou plan en rekening inkomende verbindings hoegenaamd toelaat, want 'n toegewyde uitgangsadres is nie 'n poortverwysingskontrak nie.

Daardie onderskeid vang mense wat 'n statiese IP koop en bereikbaarheid verwag. Dat die adres stabiel is, sê niks oor of die verskaffer 'n inkomende poort na jou sessie verwys nie.

Kontroleer die luisteraar voordat jy die verskaffer kontroleer

Core moet luister op die adres en poort waarnatoe die kartering aflewer, en die gasheer se firewall moet dit toelaat. As die node in 'n houer of op 'n ander LAN-masjien loop, hoort die volgende sprong en sy antwoordroete ook in die ketting.

'n Plaaslike firewall-reël kan nie 'n kartering by 'n verskaffer skep wat inkomende pakkette laat val nie, en 'n verskafferkartering kan nie 'n proses bereik wat net aan loopback gebind is nie. Albei helftes moet oor dieselfde tuple saamstem, en daarom is die eerste stap om die tuple neer te skryf eerder as om dit te raai.

Hou die geadverteerde eindpunt in ooreenstemming met die lewendige kartering. 'n Statiese adres maak nie 'n toegewysde poort of sy huur permanent oor herverbindings nie, so 'n eindpunt wat maande gelede gepubliseer is, wys nou dalk na niks. Lees die verskaffer se bladsy weer nadat jy herverbind het en vergelyk dit met wat jou node adverteer. As die poort geskuif het, is die ou eindpunt nou óf niemand s'n óf iemand anders s'n.

Lees die inkomende vlag, nie die totale verbindings nie

Vanaf 'n gemagtigde plaaslike RPC-konteks lys hierdie lees-alleen-navraag die eweknieë:

bitcoin-cli getpeerinfo

Die RPC-verwysing definieer inbound as waar vir 'n inkomende verbinding en onwaar vir 'n uitgaande een. Kyk na daardie veld. 'n Totaal bo tien bewys niks oor rigting nie, en die totale en kategorieë verskuif in elk geval met konfigurasie en weergawe.

Toets dan die gekarteerde eindpunt van buite met 'n nuwe bereikbaarheidstoets wat jy gemagtig is om te hardloop, en kyk of 'n ooreenstemmende inkomende eweknie verskyn. Wees versigtig met die uitset wat jy in 'n ondersteuningsdraad plak: eweknie-adresse is ander mense se verbindingsbesonderhede, en dit hoef nie gepubliseer te word sodat jou vraag beantwoord kan word nie.

Moenie dit oplos deur RPC bloot te stel nie

Bitcoin Core se RPC-dokumentasie waarsku uitdruklik daarteen om die RPC-koppelvlak aan die openbare internet bloot te stel. Eweknie-verbindings en geauthentiseerde administrasie is verskillende dienste, en om P2P bereikbaar te maak deur RPC te publiseer verruil 'n verbindingsprobleem vir 'n veel erger een.

As jy liewer glad nie van inkomende P2P afhanklik wil wees nie, is 'n onion-diens die gedokumenteerde alternatief, en dit het sy eie voorvereistes: Tor beskikbaar, beheerverifikasie opgestel en luisterinstellings wat toelaat dat die diens geskep word. Dit verskyn nie omdat daar toevallig 'n VPN loop nie.

Om Core van die VPN uit te sluit is 'n derde ontwerp, en vir sommige operateurs 'n wettige een, maar dit plaas eweknie-verkeer op jou gewone verbinding. Dit is nie inkomende toegang deur die VPN nie, en 'n router of opstroom-NAT het dalk steeds sy eie toegelate inskrywing nodig. Kies watter van die drie jy werklik toets voordat jy enigiets anders verander.

Verwante artikels