Mining-Pool über VPN: die Sitzung auf dem richtigen Pfad halten

Mining-Software hält einen einzigen Socket auf eine einzige Adresse offen, und alle Fragen zu Tunnel, Route und angerechneter Arbeit hängen an diesem Socket. Dieser Socket ist eine ausgehende Client-Sitzung zu einem Pool-Endpunkt, kein Listener, der Peers annimmt. Der folgende Rundgang folgt ihm von den vier Werten, die der Pool ausgegeben hat, bis zu einem Share, das der Pool tatsächlich verbucht hat, und lässt die übrigen Dienste des Hosts unangetastet. Jeder Schritt liefert eine Antwort, die Sie vergleichen können, keinen Eindruck.

Beim Endpunkt ansetzen, den der Pool tatsächlich ausgegeben hat

Der Pool übergibt Ihnen vier Werte, die den gesamten Vertrag bilden: Hostname oder Adresse, Port, Protokollvariante und Account-String. Nehmen Sie sie aus dem Dashboard des Pools oder aus der Onboarding-Nachricht, nicht aus einer Anleitung für einen anderen Pool. Regionale Shards gibt es für denselben Dienst, daher kann ein aus einer alten Anleitung kopierter Hostname immer noch verbinden und immer noch ein Konto anrechnen, das Sie nie verwenden wollten. Kopieren Sie die vier Werte wörtlich in die Konfiguration des Miners, denn ein neu getippter Account-String verliert ein Trennzeichen.

Der Verkehrsfluss, den Sie routen, ist der, den der Bitcoin-Entwicklerleitfaden als Stratum-Sitzung: eine dauerhafte bidirektionale TCP-Verbindung, in der der Pool Arbeit verteilt und der Miner Shares zurückgibt. Das ist nicht derselbe Fluss wie die Peer-Verbindungen eines Full Node oder die Chain-Synchronisierung einer Wallet, und sie in eine Verkehrsklasse zu falten, ist der Punkt, an dem die meiste Verwirrung beginnt. Nur der erste gehört unter diese Richtlinie.

Wo der Pool TLS anbietet, behalten Sie die Serverprüfung bei, die seine Dokumentation verlangt. Ein Tunnel verschlüsselt den Hop von Ihrem Rechner zum VPN-Server und endet dort; er bürgt nicht für denjenigen, der auf der anderen Seite antwortet. Behalten Sie beide Prüfungen, eine an jedem Ende, wenn die Sitzung einen kompromittierten Ausgang überstehen soll.

Den Tunnel an den Prozess hängen, nicht an den Haushalt

Zwei Anknüpfungspunkte funktionieren: Führen Sie den VPN-Client im Netzwerk-Namespace aus, den der Miner nutzt, oder geben Sie diesem Namespace ein Gateway, das seinen Verkehr in den Tunnel trägt. Beide Anordnungen bringen die Sitzung auf den Pfad, bevor der Pool sie sieht. Der übliche Fehler ist ein Client auf dem Host, ein Miner in einem Container mit eigener Bridge und eine Host-Route, die der Container nie heranzieht. Das Client-Fenster sieht gesund aus, während der Pool Ihre Privatadresse protokolliert.

Prüfen Sie den eigenen Transport des Tunnels, bevor Sie irgendetwas abgrenzen. Der Client muss seinen Server über das Underlay erreichen, also fängt eine Richtlinie, die jedes Paket einfängt, auch die Pakete ein, die den Tunnel aufbauen würden. Dann kann der Tunnel nicht starten, und auch sonst geht nichts hinaus. Wählen Sie mit der Split-Tunneling-Funktion des Clients aus, was in den Tunnel geht; Standardrouten von Hand zu bearbeiten, ist der Weg, auf dem das Underlay verschwindet.

Wenn die Richtlinie steht, lesen Sie die Socket-Tabelle in dem Namespace, dem der Miner gehört. Der Fluss zum Pool-Port sollte auf dem Tunnel-Interface liegen, und zwei Befehle beantworten diese Frage. Der Port unten ist ein Beispiel; setzen Sie den ein, den der Pool ausgegeben hat.

sudo nsenter -t "$(pidof cgminer)" -n ss -tnp state established 'dport = :3333'
sudo nsenter -t "$(pidof cgminer)" -n ip route get 203.0.113.10

Route und Resolver aus dem eigenen Kontext des Miners lesen

Routing und Namensauflösung gelten pro Namespace, daher beschreibt eine Prüfung in einer gewöhnlichen Shell den falschen Rechner, sobald der Miner in einem Container läuft. Betreten Sie zuerst den Namespace und fragen Sie dann, welches Interface ein Paket zur Pool-Adresse tragen würde und welcher Resolver für seinen Hostnamen antworten würde. Die Antworten des Hosts übertragen sich nicht, und die Lücke dazwischen ist eine häufige Quelle falsch adressierter Schuld.

Benennen Sie das Interface, das Sie erhalten: der Tunnel bedeutet, die Sitzung ist auf dem beabsichtigten Pfad, während die physische Verbindung bedeutet, dass eine Regel früher gegriffen hat, als Sie erwartet haben. Die Präfixlänge entscheidet zuerst, dann die Metrik, dann die Policy-Regeln, daher dupliziert eine Tabelle mit mehreren Standardeinträgen keine Pakete, sie verliert nur.

Resolver scheitern getrennt von Routen. Ein Tunnel, der /etc/resolv.conf umschreibt, kann den Namespace auf einen Resolver zeigen lassen, der nur von innerhalb des Tunnels erreichbar ist, was scheitert, bevor irgendein TCP-Handshake stattfindet. Lösen Sie den Pool-Hostnamen innerhalb des Namespace auf und vergleichen Sie ihn mit der veröffentlichten Adresse. Wenn die Abfrage ausläuft oder etwas anderes zurückgibt, beheben Sie die Auflösung, bevor Sie Routen anfassen.

Den Pool-Client und den Node-Listener getrennt halten

Port 8333 ist der Peer-Port von Bitcoin Core, an dem ein Full Node auf eingehende Verbindungen hört; ein Pool-Miner braucht ihn nie offen, und ihn zu öffnen repariert keinen ausgehenden Fehler. Eingehende Listener und ausgehende Sitzungen sind entgegengesetzte Rollen mit entgegengesetzten Vertrauensannahmen. Nichts in der Konfiguration eines Miners bindet diesen Port, daher kann ein geschlossener Port keinen Fehler erklären, den er meldet. Ratschläge, die für die Erreichbarkeit eines Nodes geschrieben wurden, können deshalb einen öffentlichen Dienst auf einem Host laufen lassen, der nur Shares einreichen sollte.

Wenn eine Maschine wirklich beides macht, behandeln Sie jede Rolle als eigenen Dienst mit eigener Zugriffsentscheidung. Der Listener des Nodes gehört hinter die Richtlinie, die Sie auf öffentliche Dienste anwenden, und die Sitzung des Miners gehört zur Egress-Richtlinie, die den Tunnel wählt. Halten Sie fest, welche Rolle der Host spielt, und entfernen Sie die Regeln der anderen Rolle, wenn sich das ändert, denn eine übrig gebliebene Allow-Regel überlebt ihren Grund.

Beweisen, dass der Pool die Arbeit erhalten hat

Ein laufender Lüfter und eine steigende Hashrate zeigen, dass der Miner rechnet, nicht dass etwas den Pool erreicht hat. Die Belege liegen in den Übermittlungszählern des Clients oder auf dem Dashboard des Pools: angenommene Shares, abgelehnte Shares und der Grund zu jeder Ablehnung. Diese Zahlen trennen drei Fehler, die von außen gleich aussehen: keine Sitzung, eine Sitzung ohne Anrechnung und eine Sitzung, die ständig neu verbindet. Lesen Sie sie, bevor Sie irgendeine Konfiguration ändern.

Beobachten Sie einen Verbindungsversuch mit ausführlichem Logging und notieren Sie die letzte Stufe, die erfolgreich war. Die Stufe, an der die Sequenz stoppt, ist nützlicher als jede einzelne Meldung darum herum:

Lassen Sie den Client dann ein festes Fenster laufen und zählen Sie beide Ausgänge aus seinem Log. Ein grep pro Zähler reicht, und ein Vergleich über dasselbe Fenster trennt einen langsamen Pool von einem kaputten Pfad. Passen Sie den Pfad an, an den Ihr Client schreibt, denn die beiden Zählungen hängen nicht vom Ort ab:

grep -c Accepted /var/log/miner.log
grep -c Rejected /var/log/miner.log

Wenn eine Regel eine direkte Pool-Verbindung verbietet, sobald der Tunnel ausfällt, drücken Sie das als expliziten Block auf den Pool-Endpunkt aus. Ein Client, der still über die physische Verbindung erneut versucht, minet weiter und verletzt diese Regel weiter, und seine Statusanzeige erwähnt es nicht. Testen Sie die Regel, indem Sie den Tunnel absichtlich abwerfen und bestätigen, dass der Pool-Port überhaupt nicht erreichbar ist.