Pool εξόρυξης μέσω VPN: κρατήστε τη συνεδρία στη σωστή διαδρομή

Το λογισμικό εξόρυξης κρατά ένα socket ανοιχτό προς μία διεύθυνση, και κάθε ερώτηση για το tunnel, τη διαδρομή και την πιστωμένη εργασία κρέμεται από αυτό το socket. Αυτό το socket είναι μια εξερχόμενη συνεδρία πελάτη προς ένα endpoint του pool, όχι ένας listener που δέχεται peers. Η διαδρομή παρακάτω το ακολουθεί από τις τέσσερις τιμές που εξέδωσε το pool μέχρι ένα share που το pool όντως κατέγραψε, και αφήνει τις άλλες υπηρεσίες του host ήσυχες. Κάθε βήμα παράγει μια απάντηση που μπορείτε να συγκρίνετε, όχι μια εντύπωση.

Ξεκινήστε από το endpoint που εξέδωσε πραγματικά το pool

Το pool σάς δίνει τέσσερις τιμές που σχηματίζουν όλο το συμβόλαιο: όνομα host ή διεύθυνση, θύρα, παραλλαγή πρωτοκόλλου και συμβολοσειρά λογαριασμού. Πάρτε τις από τον πίνακα του pool ή από το μήνυμα υποδοχής, όχι από έναν οδηγό για άλλο pool. Υπάρχουν περιφερειακά shards για την ίδια υπηρεσία, οπότε ένα όνομα host αντιγραμμένο από παλιό οδηγό μπορεί ακόμη να συνδεθεί και ακόμη να πιστώσει λογαριασμό που δεν θέλατε ποτέ να χρησιμοποιήσετε. Αντιγράψτε τις τέσσερις τιμές αυτολεξεί στη διαμόρφωση του miner, γιατί μια ξαναγραμμένη συμβολοσειρά λογαριασμού χάνει έναν διαχωριστή.

Η ροή που δρομολογείτε είναι αυτή που ο οδηγός προγραμματιστή του Bitcoin ονομάζει συνεδρία Stratum: μια επίμονη αμφίδρομη σύνδεση TCP όπου το pool διανέμει εργασία και ο miner επιστρέφει shares. Δεν είναι η ίδια ροή με τις συνδέσεις peer ενός πλήρους κόμβου ή τον συγχρονισμό αλυσίδας ενός πορτοφολιού, και το δίπλωμά τους σε μία κλάση κίνησης είναι το σημείο όπου αρχίζει η περισσότερη σύγχυση. Μόνο η πρώτη ανήκει σε αυτή την πολιτική.

Όπου το pool προσφέρει TLS, κρατήστε την επαλήθευση διακομιστή που απαιτεί η τεκμηρίωσή του. Ένα tunnel κρυπτογραφεί το hop από το μηχάνημά σας στον διακομιστή VPN και τελειώνει εκεί· δεν εγγυάται για όποιον απαντά στην άλλη πλευρά. Κρατήστε και τους δύο ελέγχους, έναν σε κάθε άκρο, αν θέλετε η συνεδρία να επιβιώσει από μια παραβιασμένη έξοδο.

Συνδέστε το tunnel στη διεργασία, όχι στο νοικοκυριό

Δύο σημεία σύνδεσης δουλεύουν: εκτελέστε τον πελάτη VPN μέσα στον namespace δικτύου που χρησιμοποιεί ο miner, ή δώστε σε αυτόν τον namespace μια πύλη που μεταφέρει την κίνησή του στο tunnel. Και οι δύο διατάξεις βάζουν τη συνεδρία στη διαδρομή πριν τη δει το pool. Η συνηθισμένη αποτυχία είναι ένας πελάτης στον host, ένας miner σε container με τη δική του γέφυρα και μια διαδρομή host που το container δεν συμβουλεύεται ποτέ. Το παράθυρο του πελάτη φαίνεται υγιές ενώ το pool καταγράφει τη διεύθυνση του σπιτιού σας.

Ελέγξτε τη δική του μεταφορά του tunnel πριν οριοθετήσετε οτιδήποτε. Ο πελάτης πρέπει να φτάσει στον διακομιστή του μέσω του υποστρώματος, οπότε μια πολιτική που συλλαμβάνει κάθε πακέτο συλλαμβάνει και τα πακέτα που θα έχτιζαν το tunnel. Τότε το tunnel δεν μπορεί να ξεκινήσει και τίποτα άλλο δεν βγαίνει επίσης. Επιλέξτε με τη λειτουργία split tunnel του πελάτη τι μπαίνει στο tunnel· η χειροκίνητη επεξεργασία προεπιλεγμένων διαδρομών είναι ο τρόπος με τον οποίο το υπόστρωμα εξαφανίζεται.

Με την πολιτική στη θέση της, διαβάστε τον πίνακα socket στον namespace στον οποίο ανήκει ο miner. Η ροή προς τη θύρα του pool θα πρέπει να κάθεται στη διεπαφή του tunnel, και δύο εντολές απαντούν σε αυτή την ερώτηση. Η θύρα παρακάτω είναι ένα παράδειγμα· αντικαταστήστε την με αυτή που εξέδωσε το pool.

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

Διαβάστε διαδρομή και resolver από το δικό του context του miner

Η δρομολόγηση και η ανάλυση ονομάτων είναι ανά namespace, οπότε ένας έλεγχος σε ένα συνηθισμένο κέλυφος περιγράφει το λάθος μηχάνημα όποτε ο miner είναι σε container. Μπείτε πρώτα στον namespace και μετά ρωτήστε ποια διεπαφή θα μετέφερε ένα πακέτο στη διεύθυνση του pool και ποιος resolver θα απαντούσε για το όνομα host του. Οι απαντήσεις του host δεν μεταφέρονται, και το χάσμα μεταξύ τους είναι μια συνηθισμένη πηγή λανθασμένης καταλογισμού ευθύνης.

Ονομάστε τη διεπαφή που παίρνετε: το tunnel σημαίνει ότι η συνεδρία είναι στην προβλεπόμενη διαδρομή, ενώ ο φυσικός σύνδεσμος σημαίνει ότι ένας κανόνας ταίριαξε νωρίτερα από ό,τι περιμένατε. Το μήκος προθέματος αποφασίζει πρώτο, μετά η μετρική, μετά οι κανόνες πολιτικής, οπότε ένας πίνακας με πολλές προεπιλεγμένες εγγραφές δεν διπλασιάζει πακέτα, απλώς χάνει.

Οι resolver αποτυγχάνουν χωριστά από τις διαδρομές. Ένα tunnel που ξαναγράφει το /etc/resolv.conf μπορεί να αφήσει τον namespace να δείχνει σε resolver προσβάσιμο μόνο από μέσα στο tunnel, κάτι που αποτυγχάνει πριν από οποιαδήποτε χειραψία TCP. Επιλύστε το όνομα host του pool μέσα στον namespace και συγκρίνετέ το με τη δημοσιευμένη διεύθυνση. Αν η αναζήτηση λήξει ή επιστρέψει κάτι άλλο, διορθώστε την επίλυση πριν αγγίξετε διαδρομές.

Κρατήστε χωριστά τον πελάτη του pool και τον listener του κόμβου

Η θύρα 8333 είναι η θύρα peer του Bitcoin Core, όπου ένας πλήρης κόμβος ακούει εισερχόμενες συνδέσεις· ένας miner pool δεν τη χρειάζεται ποτέ ανοιχτή, και το άνοιγμά της δεν επισκευάζει μια εξερχόμενη βλάβη. Οι εισερχόμενοι listener και οι εξερχόμενες συνεδρίες είναι αντίθετοι ρόλοι με αντίθετες παραδοχές εμπιστοσύνης. Τίποτα στη διαμόρφωση ενός miner δεν δεσμεύει αυτή τη θύρα, οπότε μια κλειστή θύρα δεν μπορεί να εξηγήσει οποιοδήποτε σφάλμα αναφέρει. Μια συμβουλή γραμμένη για την προσβασιμότητα ενός κόμβου μπορεί επομένως να αφήσει μια δημόσια υπηρεσία να τρέχει σε έναν host που προοριζόταν μόνο να υποβάλλει shares.

Αν ένα μηχάνημα κάνει πραγματικά και τα δύο, αντιμετωπίστε κάθε ρόλο ως ξεχωριστή υπηρεσία με τη δική της απόφαση πρόσβασης. Ο listener του κόμβου ανήκει πίσω από την πολιτική που εφαρμόζετε σε δημόσιες υπηρεσίες, και η συνεδρία του miner ανήκει στην πολιτική εξόδου που επιλέγει το tunnel. Καταγράψτε ποιον ρόλο παίζει ο host και αφαιρέστε τους κανόνες του άλλου ρόλου όταν αυτό αλλάξει, γιατί ένας κανόνας άδειας που έμεινε πίσω επιβιώνει του λόγου του.

Αποδείξτε ότι το pool έλαβε την εργασία

Ένας απασχολημένος ανεμιστήρας και ένα ανερχόμενο hashrate δείχνουν ότι ο miner υπολογίζει, όχι ότι κάτι έφτασε στο pool. Η απόδειξη βρίσκεται στους μετρητές υποβολής του πελάτη ή στον πίνακα του pool: αποδεκτά shares, απορριφθέντα shares και ο λόγος που συνοδεύει κάθε απόρριψη. Αυτοί οι αριθμοί διαχωρίζουν τρεις βλάβες που φαίνονται ίδιες από έξω: καμία συνεδρία, συνεδρία χωρίς πίστωση και συνεδρία που επανασυνδέεται συνεχώς. Διαβάστε τους πριν αλλάξετε οποιαδήποτε διαμόρφωση.

Παρατηρήστε μία απόπειρα σύνδεσης με λεπτομερές logging και σημειώστε το τελευταίο στάδιο που πέτυχε. Το στάδιο όπου η ακολουθία σταματά είναι πιο χρήσιμο από οποιοδήποτε μεμονωμένο μήνυμα γύρω του:

Στη συνέχεια αφήστε τον πελάτη να τρέξει ένα σταθερό παράθυρο και μετρήστε και τα δύο αποτελέσματα από το log του. Ένα grep ανά μετρητή αρκεί, και η σύγκρισή τους στο ίδιο παράθυρο διαχωρίζει ένα αργό pool από μια σπασμένη διαδρομή. Προσαρμόστε τη διαδρομή εκεί όπου γράφει ο πελάτης σας, αφού οι δύο μετρήσεις δεν εξαρτώνται από την τοποθεσία:

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

Αν ένας κανόνας απαγορεύει άμεση σύνδεση στο pool κάθε φορά που πέφτει το tunnel, εκφράστε το ως ρητό αποκλεισμό στο endpoint του pool. Ένας πελάτης που επαναπροσπαθεί ήσυχα μέσω του φυσικού συνδέσμου θα συνεχίσει να εξορύσσει και θα συνεχίσει να παραβιάζει αυτόν τον κανόνα, και η οθόνη κατάστασής του δεν θα το αναφέρει. Δοκιμάστε τον κανόνα ρίχνοντας επίτηδες το tunnel και επιβεβαιώνοντας ότι η θύρα του pool δεν είναι καθόλου προσβάσιμη.