Žiadni prichádzajúci partneri na vašom uzle Bitcoin za VPN?

Váš uzol je synchronizovaný, VPN hlási pripojenie a getpeerinfo zobrazuje osem alebo desať partnerov. Žiadny z nich nemá inbound nastavené na true. Taká kombinácia je normálna a nie je to porucha: odchádzajúce spojenia dokazujú, že uzol dosiahne na ostatných, a nič v nich nedokazuje, že sa niekto dostane k vám. Ak je cieľom uzol, ktorý prijíma prichádzajúce P2P spojenia cez VPN, musíte tento smer otestovať zvlášť.

Sledujte paket od partnera k vášmu naslúchaču

Prichádzajúce P2P je reťaz štyroch vecí a zlyháva na najslabšom článku, nie na tom najzaujímavejšom.

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

Predvolená hodnota P2P Core v hlavnej sieti je 8333, ale poskytovateľ vám môže dať iný verejný port a iné cieľové miesto na strane klienta. Zapíšte verejnú adresu, externý port a miesto, kam poskytovateľ prevádzku skutočne doručuje. Potom overte, že váš plán a účet vôbec povoľujú prichádzajúce spojenia, pretože vyhradená odchádzajúca adresa nie je zmluva o presmerovaní portov.

Tento rozdiel chytá ľudí, ktorí si kupujú statickú IP v očakávaní dostupnosti. To, že je adresa stabilná, nič nehovorí o tom, či poskytovateľ presmeruje prichádzajúci port na vašu reláciu.

Skontrolujte naslúchač skôr než poskytovateľa

Core musí počúvať na adrese a porte, kam mapovanie doručuje, a hostiteľský firewall to musí povoliť. Ak uzol beží v kontajneri alebo na inom počítači v LAN, do reťaze patrí aj ďalší skok a jeho spiatočná trasa.

Miestne pravidlo firewallu nedokáže vytvoriť mapovanie u poskytovateľa, ktorý zahadzuje prichádzajúce pakety, a mapovanie poskytovateľa nedosiahne proces viazaný len na loopback. Obe polovice sa musia zhodnúť na tej istej n-tici, preto je prvým krokom n-ticu zapísať, nie hádať.

Udržujte inzerovaný koncový bod v súlade so skutočným mapovaním. Statická adresa nerobí priradený port ani jeho prenájom trvalým medzi opätovnými pripojeniami, takže koncový bod zverejnený pred mesiacmi už nemusí ukazovať na nič. Po každom opätovnom pripojení znova prečítajte stránku poskytovateľa a porovnajte ju s tým, čo inzeruje váš uzol. Ak sa port posunul, starý koncový bod teraz buď nie je ničí, alebo je niekoho iného.

Čítajte príznak prichádzajúceho spojenia, nie celkový počet

Z autorizovaného miestneho kontextu RPC tento dotaz iba na čítanie vypíše partnerov:

bitcoin-cli getpeerinfo

Referenčná príručka RPC definuje inbound ako true pre prichádzajúce spojenie a false pre odchádzajúce. Pozrite sa na to pole. Celkový počet nad desať nedokazuje nič o smere a súčty aj kategórie sa s konfiguráciou a verziou aj tak menia.

Potom otestujte namapovaný koncový bod zvonku novou kontrolou dostupnosti, ktorú máte oprávnenie spustiť, a pozrite sa, či sa objaví zodpovedajúci prichádzajúci partner. Buďte opatrní s výstupom, ktorý vkladáte do vlákna podpory: adresy partnerov sú údaje o spojeniach iných ľudí a nemusia byť zverejnené, aby vám niekto odpovedal.

Neriešte to vystavením RPC

Dokumentácia RPC Bitcoin Core výslovne varuje pred vystavením rozhrania RPC verejnému internetu. Spojenia s partnermi a autentizovaná správa sú rôzne služby a sprístupnenie P2P zverejnením RPC mení problém s konektivitou za oveľa horší.

Ak radšej nechcete na prichádzajúcom P2P vôbec závisieť, dokumentovanou alternatívou je služba onion a má svoje vlastné predpoklady: dostupný Tor, nakonfigurované overovanie správy a nastavenia počúvania, ktoré umožnia službu vytvoriť. Neobjaví sa len preto, že náhodou beží VPN.

Vylúčenie Core z VPN je tretí dizajn a pre niektorých operátorov legitímny, ale presúva prevádzku partnerov na vaše bežné pripojenie. To nie je prichádzajúci prístup cez VPN a router alebo nadradený NAT môže stále potrebovať vlastný povolený záznam. Vyberte, ktorý z troch skutočne testujete, než zmeníte čokoľvek ďalšie.