VPN 経由のマイニングプール：セッションを正しい経路に保つ

マイニングソフトは 一つのソケットを 一つのアドレスに対して開いたままにし、トンネル、経路、計上された作業に関するあらゆる問いはそのソケットにぶら下がっています。そのソケットはプールのエンドポイントへ向かう外向きのクライアントセッションであり、ピアを受け入れるリスナーではありません。以下の道筋は、プールが発行した 四つの値から、プールが実際に記録したシェアまでそれをたどり、ホストの他のサービスには触れません。各手順は比較できる答えを返し、印象を返しません。

プールが実際に発行したエンドポイントから始める

プールは契約全体をなす 四つの値を渡します。ホスト名かアドレス、ポート、プロトコルの種類、アカウント文字列です。これらはプールのダッシュボードか案内メッセージから取り、別のプール向けの解説から取らないでください。同じサービスにも地域シャードがあるため、古い手引きからコピーしたホスト名でも接続でき、意図していなかったアカウントに計上され得ます。四つの値はそのままマイナーの設定にコピーしてください。打ち直したアカウント文字列は区切り文字を失います。

ルーティングする流れは、Bitcoin 開発者ガイドが Stratum セッション と呼ぶものです。プールが作業を配り、マイナーがシェアを返す持続的な双方向 TCP 接続です。これはフルノードのピア接続やウォレットのチェーン同期とは同じ流れではなく、それらを 一つのトラフィッククラスに畳むことが混乱の大半の始まりです。このポリシーの対象は 一つ目だけです。

プールが TLS を提供する場所では、その文書が求めるサーバー検証を残してください。トンネルが暗号化するのは自分のマシンから VPN サーバーまでの区間で、そこで終わります。向こう側で誰が応答するかを保証はしません。セッションを侵害された出口でも維持したいなら、両端の検証を両方残してください。

トンネルは世帯ではなくプロセスに接続する

接続点は 二つあります。VPN クライアントをマイナーが使うネットワーク名前空間の内側で動かすか、その名前空間にトラフィックをトンネルへ運ぶゲートウェイを与えるかです。どちらもプールが見る前にセッションを経路へ載せます。よくある失敗は、ホストにクライアント、自前のブリッジを持つコンテナにマイナー、そしてコンテナが決して参照しないホスト経路です。クライアントの画面は健全に見えるのに、プールは自宅のアドレスを記録しています。

何かを絞る前に、トンネル自身の転送を確認してください。クライアントは下位層を通ってサーバーに届く必要があるため、すべてのパケットを捕まえるポリシーはトンネルを組み立てるパケットも捕まえます。するとトンネルは起動できず、ほかのものも出ていきません。クライアントの分割トンネル機能でトンネルに入るものを選んでください。既定経路を手で書き換えるのが、下位層が消えるやり方です。

ポリシーが入ったら、マイナーが属する名前空間でソケット表を読んでください。プールのポートへの流れはトンネルのインターフェースに載っているはずで、二つのコマンドがその問いに答えます。下のポートは例です。プールが発行したものに置き換えてください。

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

経路とリゾルバーをマイナー自身の文脈から読む

ルーティングと名前解決は名前空間ごとに働くため、通常のシェルで実行した確認は、マイナーがコンテナにあるときは常に別のマシンを説明します。まず名前空間に入り、どのインターフェースがパケットをプールのアドレスへ運ぶのか、どのリゾルバーがそのホスト名に答えるのかを尋ねてください。ホストの答えは引き継がれず、その差が誤った責任転嫁のよくある源です。

得られたインターフェースを名指ししてください。トンネルならセッションは意図した経路にあり、物理リンクなら想定より早く規則が一致したということです。まずプレフィックス長、次にメトリック、次にポリシー規則が決めるので、既定エントリが複数ある表はパケットを複製せず、ただ負けます。

リゾルバーは経路とは別に失敗します。/etc/resolv.conf を書き換えるトンネルは、名前空間をトンネルの内側からしか届かないリゾルバーへ向けたままにすることがあり、これは TCP のハンドシェイクが起きる前に失敗します。プールのホスト名を名前空間の内側で解決し、公開されたアドレスと比較してください。照会がタイムアウトするか別の値を返すなら、経路に触る前に解決を直してください。

プールのクライアントとノードのリスナーを分けておく

ポート 8333 は Bitcoin Core のピアポートで、フルノードが受信接続を待ち受ける場所です。プールマイナーが開けておく必要はなく、開けても外向きの不具合は直りません。受信リスナーと送信セッションは、逆向きの信頼前提を持つ逆向きの役割です。マイナーの設定のどこもそのポートを結び付けないので、閉じたポートは報告されるどのエラーも説明できません。ノードの到達性のために書かれた助言は、シェアを送るだけのホストに公開サービスを残しかねません。

一台のマシンが本当に両方を担うなら、各役割を独自のアクセス判断を持つ別サービスとして扱ってください。ノードのリスナーは公開サービスに適用するポリシーの後ろに属し、マイナーのセッションはトンネルを選ぶ送信ポリシーに属します。ホストがどの役割を担うかを記録し、それが変わったらもう一方の役割の規則を外してください。残った許可規則はその理由より長く生きるからです。

プールが作業を受け取ったことを証明する

ファンが回りハッシュレートが上がるのはマイナーが計算している証拠で、何かがプールに届いた証拠ではありません。証拠はクライアントの送信カウンターかプールのダッシュボードにあります。受理されたシェア、拒否されたシェア、そして各拒否に付された理由です。その数字は外から見ると同じに見える 三つの不具合を分けます。セッションがない、セッションはあるが計上がない、そして繰り返し再接続するセッションです。どの設定を変える前にもそれを読んでください。

詳細ログで 一回の接続試行を観察し、最後に成功した段階を書き留めてください。手順が止まる段階は、その周りのどんな単一メッセージよりも役に立ちます。

そのあとクライアントを一定の窓で動かし、ログから両方の結果を数えてください。カウンターごとに一回の grep で足り、同じ窓で比べれば遅いプールと壊れた経路を分けられ、経路はクライアントが書く場所に合わせてください、二つの数え方は場所に依存しないからです。

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

トンネルが落ちるたびにプールへの直接接続を禁じる規則があるなら、プールのエンドポイントに対する明示的な遮断として表してください。物理リンクで黙って再試行するクライアントは掘り続け、その規則を破り続けますが、状態表示はそれに触れません。トンネルを故意に落とし、プールのポートにまったく届かないことを確認して規則を試してください。