Keine eingehenden Peers auf deinem Bitcoin-Node hinter einem VPN?

Ausgehende Peers und eine synchronisierte Chain beweisen keine eingehende Erreichbarkeit. Prüfe Mapping, Listener und das inbound-Flag, bevor du das VPN verantwortlich machst.

Dein Node ist synchronisiert, das VPN meldet verbunden, und getpeerinfo zeigt acht oder zehn Peers. Keiner davon hat inbound auf true gesetzt. Diese Kombination ist normal und kein Fehler: ausgehende Verbindungen beweisen, dass der Node andere erreicht, und nichts daran beweist, dass jemand dich erreicht. Wenn das Ziel ein Node ist, der eingehende P2P-Verbindungen über ein VPN annimmt, musst du diese Richtung separat testen.

Verfolge das Paket vom Peer bis zu deinem Listener

Eingehendes P2P ist eine Kette aus vier Dingen, und sie bricht am schwächsten Glied, nicht am interessantesten.

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

Der P2P-Standard von Core im Mainnet ist 8333, aber der Anbieter kann dir einen anderen öffentlichen Port und ein anderes Ziel auf der Clientseite geben. Notiere die öffentliche Adresse, den externen Port und den Ort, an den der Anbieter den Verkehr tatsächlich ausliefert. Bestätige dann, dass dein Tarif und dein Konto eingehende Verbindungen überhaupt erlauben, denn eine dedizierte Ausgangsadresse ist kein Port-Forwarding-Vertrag.

Diese Unterscheidung erwischt Leute, die eine statische IP in der Erwartung von Erreichbarkeit kaufen. Dass die Adresse stabil ist, sagt nichts darüber aus, ob der Anbieter einen eingehenden Port auf deine Sitzung weiterleitet.

Prüfe zuerst den Listener, dann den Anbieter

Core muss auf der Adresse und dem Port lauschen, an die das Mapping ausliefert, und die Host-Firewall muss es erlauben. Läuft der Node in einem Container oder auf einem anderen Rechner im LAN, gehören der nächste Hop und seine Antwortroute ebenfalls zur Kette.

Eine lokale Firewall-Regel kann kein Mapping bei einem Anbieter erzeugen, der eingehende Pakete verwirft, und ein Anbieter-Mapping erreicht keinen Prozess, der nur an Loopback gebunden ist. Beide Hälften müssen sich auf dasselbe Tupel einigen, weshalb der erste Schritt ist, das Tupel aufzuschreiben, statt es zu raten.

Halte den beworbenen Endpunkt mit dem aktuellen Mapping konsistent. Eine statische Adresse macht einen zugewiesenen Port oder dessen Lease nicht dauerhaft über Wiederverbindungen hinweg, sodass ein vor Monaten veröffentlichter Endpunkt jetzt auf nichts zeigen kann. Lies die Seite des Anbieters nach jeder Wiederverbindung erneut und vergleiche sie mit dem, was dein Node bewirbt. Hat sich der Port verschoben, gehört der alte Endpunkt jetzt entweder niemandem oder jemand anderem.

Lies das inbound-Flag, nicht die Gesamtzahl der Verbindungen

Aus einem autorisierten lokalen RPC-Kontext listet diese schreibgeschützte Abfrage Peers auf:

bitcoin-cli getpeerinfo

Die RPC-Referenz definiert inbound als true für eine eingehende Verbindung und false für eine ausgehende. Sieh dir dieses Feld an. Eine Gesamtzahl über zehn beweist nichts über die Richtung, und die Summen und Kategorien ändern sich mit Konfiguration und Version ohnehin.

Teste dann den gemappten Endpunkt von außen mit einer frischen Erreichbarkeitsprüfung, die du ausführen darfst, und sieh nach, ob ein entsprechender eingehender Peer auftaucht. Sei vorsichtig mit der Ausgabe, die du in einen Support-Thread einfügst: Peer-Adressen sind Verbindungsdaten anderer Leute, und sie müssen nicht veröffentlicht werden, damit deine Frage beantwortet wird.

Löse es nicht, indem du RPC exponierst

Die RPC-Dokumentation von Bitcoin Core warnt ausdrücklich davor, die RPC-Schnittstelle ins öffentliche Internet zu exponieren. Peer-Verbindungen und authentifizierte Administration sind verschiedene Dienste, und P2P durch das Veröffentlichen von RPC erreichbar zu machen, tauscht ein Konnektivitätsproblem gegen ein viel schlimmeres.

Wenn du lieber gar nicht von eingehendem P2P abhängen willst, ist ein Onion-Dienst die dokumentierte Alternative, und er hat eigene Voraussetzungen: Tor verfügbar, Control-Authentifizierung konfiguriert und Listening-Einstellungen, die das Erstellen des Dienstes erlauben. Er erscheint nicht, nur weil zufällig ein VPN läuft.

Core vom VPN auszunehmen ist ein drittes Design und für manche Betreiber legitim, aber es legt den Peer-Verkehr auf deine gewöhnliche Verbindung. Das ist kein eingehender Zugang über das VPN, und ein Router oder Upstream-NAT kann trotzdem einen eigenen erlaubten Eintrag brauchen. Entscheide, welches der drei du tatsächlich testest, bevor du irgendetwas anderes änderst.

Ähnliche Artikel