VPN の背後にある Bitcoin ノードに着信ピアがない？

送信ピアと同期済みのチェーンは着信到達性を証明しません。VPN を疑う前に、マッピング、リスナー、inbound フラグを確認してください。

ノードは同期済みで、VPN は接続済みと報告しており、getpeerinfoは八個か十個のピアを表示しています。そのどれもinboundが true に設定されていません。この組み合わせは正常で、障害ではありません。送信接続はノードが他者に到達できることを証明しますが、そこから誰かがあなたに到達できることは何も証明しません。目標が VPN 経由で着信 P2P 接続を受け入れるノードなら、その方向を単独で検証する必要があります。

ピアからリスナーまでのパケットを追う

着信 P2P は四つの要素からなる鎖で、最も興味深い環ではなく最も弱い環で切れます。

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

Core のメインネットでの P2P の既定値は 8333 ですが、プロバイダーは別の公開ポートと別のクライアント側の宛先を割り当てることがあります。公開アドレス、外部ポート、そしてプロバイダーが実際にトラフィックを届ける場所を書き留めてください。そのうえで、プランとアカウントが着信接続をそもそも許可しているかを確認してください。専用の出口アドレスはポート転送の契約ではありません。

この区別は、到達性を期待して静的 IP を買う人を捕まえます。アドレスが安定していることは、プロバイダーが着信ポートをあなたのセッションへ転送しているかどうかについては何も語りません。

プロバイダーを確認する前にリスナーを確認する

Core はマッピングが届けるアドレスとポートで待ち受けている必要があり、ホストのファイアウォールがそれを許可している必要があります。ノードがコンテナ内や別の LAN マシンで動いているなら、次のホップとその戻り経路も鎖の一部です。

着信パケットを捨てるプロバイダー側では、ローカルのファイアウォール規則でマッピングを作ることはできません。また、プロバイダー側のマッピングは、loopback にしか束縛されていないプロセスには届きません。両者が同じタプルで一致している必要があり、だからこそ最初の手順はタプルを推測するのではなく書き留めることです。

公表しているエンドポイントを実際のマッピングと一致させておいてください。静的アドレスは、割り当てられたポートやそのリースを再接続をまたいで恒久的なものにはしません。数か月前に公開したエンドポイントが、いまは何も指していないかもしれません。再接続のたびにプロバイダーのページを読み直し、ノードが告知している内容と比べてください。ポートが動いたなら、古いエンドポイントはもはや誰のものでもないか、別の誰かのものです。

接続の総数ではなく着信フラグを読む

権限のあるローカル RPC のコンテキストから、この読み取り専用クエリでピアを一覧できます。

bitcoin-cli getpeerinfo

RPC リファレンスは、着信接続では inbound を true、発信接続では false と定義しています。そのフィールドを見てください。十を超える総数は方向について何も証明せず、総数や分類は設定とリリースによって変わるものです。

次に、実行を許可されている新たな到達性チェックで、マッピング済みエンドポイントを外部から試し、対応する着信ピアが現れるかどうかを見てください。サポートスレッドに貼る出力には注意してください。ピアのアドレスは他人の接続情報であり、質問に回答を得るために公開する必要はありません。

RPC を公開して解決しない

Bitcoin Core の RPC ドキュメントは、RPC インターフェースを公開インターネットに晒さないよう明示的に警告しています。ピア接続と認証済みの管理は別のサービスであり、RPC を公開して P2P を到達可能にするのは、接続性の問題をはるかに悪い問題と引き換えることになります。

着信 P2P にまったく依存したくないなら、文書化された代替は onion サービスで、それには独自の前提条件があります。Tor が利用可能であること、制御認証が設定されていること、そしてサービスを作成できる待ち受け設定です。VPN がたまたま動いているからといって現れるものではありません。

Core を VPN から除外するのは第三の設計で、一部の運用者には正当ですが、ピアのトラフィックを通常の回線に載せます。それは VPN 経由の着信アクセスではなく、ルーターや上流の NAT に独自の許可設定がなお必要かもしれません。ほかを変える前に、三つのうちどれを実際に検証しているのかを選んでください。

関連記事