Žádní příchozí partneři na vašem uzlu Bitcoin za VPN?

Váš uzel je synchronizovaný, VPN hlásí připojení a getpeerinfo zobrazuje osm nebo deset partnerů. Žádný z nich nemá inbound nastaveno na true. Taková kombinace je normální a není to závada: odchozí spojení dokazují, že uzel dosáhne na ostatní, a nic z toho nedokazuje, že se někdo dostane k vám. Pokud je cílem uzel, který přijímá příchozí P2P spojení přes VPN, musíte tento směr otestovat zvlášť.

Sledujte paket od partnera k vašemu naslouchači

Příchozí P2P je řetěz čtyř věcí a selhává na nejslabším článku, ne na tom nejzajímavějším.

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

Výchozí hodnota P2P Core v hlavní síti je 8333, ale poskytovatel vám může dát jiný veřejný port a jiné cílové místo na straně klienta. Zapište veřejnou adresu, externí port a to, kam poskytovatel provoz skutečně doručuje. Pak potvrďte, že váš plán a účet vůbec povolují příchozí spojení, protože vyhrazená odchozí adresa není smlouva o přesměrování portu.

Tento rozdíl chytá lidi, kteří si kupují statickou IP a čekají dostupnost. To, že je adresa stabilní, nic neříká o tom, zda poskytovatel přesměruje příchozí port na vaši relaci.

Zkontrolujte naslouchač dřív než poskytovatele

Core musí naslouchat na adrese a portu, kam mapování doručuje, a hostitelský firewall to musí povolit. Pokud uzel běží v kontejneru nebo na jiném stroji v LAN, patří do řetězu i další skok a jeho zpáteční trasa.

Místní pravidlo firewallu nedokáže vytvořit mapování u poskytovatele, který příchozí pakety zahazuje, a mapování poskytovatele nedosáhne na proces vázaný jen na loopback. Obě poloviny se musí shodnout na stejné n-tici, a proto je prvním krokem n-tici zapsat, ne hádat.

Udržujte inzerovaný koncový bod v souladu se skutečným mapováním. Statická adresa nedělá přiřazený port ani jeho pronájem trvalým přes opětovná připojení, takže koncový bod zveřejněný před měsíci už nemusí ukazovat na nic. Po každém opětovném připojení znovu přečtěte stránku poskytovatele a porovnejte ji s tím, co inzeruje váš uzel. Pokud se port přesunul, starý koncový bod teď buď není ničí, nebo je někoho jiného.

Čtěte příznak příchozího spojení, ne celkový počet

Z autorizovaného místního kontextu RPC tento dotaz jen pro čtení vypíše partnery:

bitcoin-cli getpeerinfo

Referenční příručka RPC definuje inbound jako true pro příchozí spojení a false pro odchozí. Podívejte se na to pole. Celkový počet nad deset nedokazuje nic o směru a součty i kategorie se s konfigurací a verzí stejně mění.

Pak otestujte namapovaný koncový bod zvenku novou kontrolou dostupnosti, kterou máte oprávnění spustit, a podívejte se, zda se objeví odpovídající příchozí partner. Buďte opatrní s výstupem, který vkládáte do vlákna podpory: adresy partnerů jsou údaje o spojení jiných lidí a nemusí být zveřejněny, aby vám někdo odpověděl.

Neřešte to vystavením RPC

Dokumentace RPC Bitcoin Core výslovně varuje před vystavením rozhraní RPC veřejnému internetu. Spojení s partnery a autentizovaná správa jsou různé služby a zpřístupnění P2P zveřejněním RPC mění problém s konektivitou za mnohem horší.

Pokud raději nechcete na příchozím P2P vůbec záviset, dokumentovanou alternativou je onion služba a má své vlastní předpoklady: dostupný Tor, nakonfigurované ověřování správy a nastavení naslouchání, které umožní službu vytvořit. Neobjeví se jen proto, že běží VPN.

Vyloučení Core z VPN je třetí design a pro některé operátory legitimní, ale přenáší provoz partnerů na vaše běžné připojení. To není příchozí přístup přes VPN a router nebo nadřazený NAT může stále potřebovat vlastní povolený záznam. Vyberte, který ze tří skutečně testujete, než změníte cokoli dalšího.