Pool penambangan lewat VPN: jaga sesi di jalur yang benar

Perangkat lunak penambangan menjaga satu soket terbuka ke satu alamat, dan setiap pertanyaan tentang tunnel, rute, dan pekerjaan yang dikreditkan bergantung pada soket itu. Soket itu adalah sesi klien keluar ke endpoint pool, bukan listener yang menerima peer. Penelusuran di bawah mengikutinya dari empat nilai yang diterbitkan pool sampai share yang benar-benar dibukukan pool, dan membiarkan layanan lain di host tidak tersentuh. Setiap langkah menghasilkan jawaban yang bisa Anda bandingkan, bukan kesan.

Mulai dari endpoint yang benar-benar diterbitkan pool

Pool memberi Anda empat nilai yang membentuk seluruh kontrak: nama host atau alamat, port, varian protokol, dan string akun. Ambil dari dasbor pool atau pesan orientasi, bukan dari tutorial untuk pool lain. Ada shard regional untuk layanan yang sama, jadi nama host yang disalin dari panduan lama masih bisa terhubung dan masih bisa mengkreditkan akun yang tidak pernah ingin Anda gunakan. Salin keempat nilai itu apa adanya ke konfigurasi miner, karena string akun yang diketik ulang kehilangan pemisah.

Aliran yang Anda rutekan adalah yang oleh panduan pengembang Bitcoin disebut sesi Stratum: koneksi TCP dua arah persisten tempat pool membagikan pekerjaan dan miner mengembalikan share. Ini bukan aliran yang sama dengan koneksi peer node penuh atau sinkronisasi rantai dompet, dan melipat semuanya ke satu kelas lalu lintas adalah titik awal sebagian besar kebingungan. Hanya yang pertama termasuk kebijakan ini.

Di tempat pool menawarkan TLS, pertahankan verifikasi server yang diwajibkan dokumentasinya. Tunnel mengenkripsi lompatan dari mesin Anda ke server VPN dan berhenti di sana; itu tidak menjamin siapa pun yang menjawab di sisi lain. Pertahankan kedua pemeriksaan, satu di tiap ujung, jika Anda ingin sesi bertahan dari pintu keluar yang disusupi.

Tempelkan tunnel ke proses, bukan ke rumah tangga

Dua titik penempelan berhasil: jalankan klien VPN di dalam namespace jaringan yang dipakai miner, atau beri namespace itu gateway yang membawa lalu lintasnya ke tunnel. Kedua pengaturan menaruh sesi di jalur sebelum pool melihatnya. Kegagalan yang biasa adalah klien di host, miner di kontainer dengan jembatannya sendiri, dan rute host yang tidak pernah dikonsultasikan kontainer. Jendela klien terlihat sehat sementara pool mencatat alamat rumah Anda.

Periksa transport tunnel itu sendiri sebelum membatasi apa pun. Klien harus mencapai servernya melalui lapisan bawah, jadi kebijakan yang menangkap setiap paket juga menangkap paket yang akan membangun tunnel. Lalu tunnel tidak bisa mulai dan tidak ada yang lain keluar juga. Pilih dengan fitur split tunnel klien apa yang masuk ke tunnel; menyunting rute default dengan tangan adalah cara lapisan bawah menghilang.

Setelah kebijakan berlaku, baca tabel soket di namespace tempat miner berada. Aliran ke port pool seharusnya berada di antarmuka tunnel, dan dua perintah menjawab pertanyaan itu. Port di bawah adalah contoh; ganti dengan yang diterbitkan 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

Baca rute dan resolver dari konteks miner sendiri

Perutean dan resolusi nama bersifat per namespace, jadi pemeriksaan yang dijalankan di shell biasa menggambarkan mesin yang salah setiap kali miner berada di kontainer. Masuk ke namespace dulu, lalu tanyakan antarmuka mana yang akan membawa paket ke alamat pool dan resolver mana yang akan menjawab untuk nama host-nya. Jawaban host tidak ikut berpindah, dan selisih di antaranya adalah sumber umum kesalahan tuduhan.

Sebutkan antarmuka yang Anda dapat: tunnel berarti sesi berada di jalur yang dimaksud, sedangkan tautan fisik berarti sebuah aturan cocok lebih awal dari yang Anda perkirakan. Panjang prefiks memutuskan lebih dulu, lalu metrik, lalu aturan kebijakan, jadi tabel dengan beberapa entri default tidak menggandakan paket, hanya kalah.

Resolver gagal terpisah dari rute. Tunnel yang menulis ulang /etc/resolv.conf dapat membuat namespace menunjuk ke resolver yang hanya bisa dijangkau dari dalam tunnel, yang gagal sebelum jabat tangan TCP apa pun terjadi. Selesaikan nama host pool di dalam namespace dan bandingkan dengan alamat yang dipublikasikan. Jika pencarian habis waktu atau mengembalikan hal lain, perbaiki resolusi sebelum menyentuh rute.

Pisahkan klien pool dan listener node

Port 8333 adalah port peer Bitcoin Core, tempat node penuh mendengarkan koneksi masuk; miner pool tidak pernah membutuhkannya terbuka, dan membukanya tidak memperbaiki kegagalan keluar. Listener masuk dan sesi keluar adalah peran yang berlawanan dengan asumsi kepercayaan yang berlawanan. Tidak ada apa pun dalam konfigurasi miner yang mengikat port itu, jadi port tertutup tidak bisa menjelaskan kesalahan apa pun yang dilaporkannya. Saran yang ditulis untuk keterjangkauan node karena itu bisa meninggalkan layanan publik berjalan di host yang seharusnya hanya mengirim share.

Jika satu mesin benar-benar melakukan keduanya, perlakukan setiap peran sebagai layanan sendiri dengan keputusan aksesnya sendiri. Listener node termasuk di balik kebijakan yang Anda terapkan pada layanan publik, dan sesi miner termasuk kebijakan keluar yang memilih tunnel. Catat peran apa yang dimainkan host dan hapus aturan peran lain saat itu berubah, karena aturan izin yang tertinggal hidup lebih lama dari alasannya.

Buktikan bahwa pool menerima pekerjaan itu

Kipas yang sibuk dan hashrate yang naik menunjukkan miner sedang berhitung, bukan bahwa ada yang mencapai pool. Buktinya ada di penghitung pengiriman klien atau di dasbor pool: share diterima, share ditolak, dan alasan yang dilampirkan pada setiap penolakan. Angka-angka itu memisahkan tiga kegagalan yang dari luar tampak sama: tidak ada sesi, sesi tanpa kredit, dan sesi yang terus menyambung ulang. Bacalah sebelum mengubah konfigurasi apa pun.

Amati satu percobaan koneksi dengan log verbose dan catat tahap terakhir yang berhasil. Tahap tempat urutan berhenti lebih berguna daripada pesan tunggal mana pun di sekitarnya:

Lalu biarkan klien berjalan selama jendela tetap dan hitung kedua hasil dari lognya. Satu grep per penghitung cukup, dan membandingkannya pada jendela yang sama memisahkan pool lambat dari jalur rusak. Sesuaikan jalur ke tempat klien Anda menulis, karena kedua hitungan tidak bergantung pada lokasi:

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

Jika sebuah aturan melarang koneksi pool langsung setiap kali tunnel putus, nyatakan sebagai blokir eksplisit pada endpoint pool. Klien yang diam-diam mencoba lagi lewat tautan fisik akan terus menambang dan terus melanggar aturan itu, dan tampilan statusnya tidak akan menyebutkannya. Uji aturan itu dengan menjatuhkan tunnel sengaja dan memastikan port pool sama sekali tidak terjangkau.