# ピアリザベーションの使用

[ピアリザベーション](/ja/docs/concepts/networks-and-servers/peer-protocol#%E5%9B%BA%E5%AE%9A%E3%83%94%E3%82%A2%E3%81%A8%E3%83%94%E3%82%A2%E3%83%AA%E3%82%B6%E3%83%99%E3%83%BC%E3%82%B7%E3%83%A7%E3%83%B3)を使用すると、`rippled`サーバが予約とマッチしたピアからの通信を常に受け入れるように設定できます。このページでは、ピアリザベーションを使用して2台のサーバ間のピアツーピア通信を、各サーバの管理者の協力のもと一貫して維持する方法について説明します。

ピアリザベーションは、2台のサーバが異なる組織によって運用されていて、着信接続を受信するサーバが、多くのピアを持つ[ハブサーバ](/ja/docs/concepts/networks-and-servers/rippled-server-modes#%E5%85%AC%E9%96%8B%E3%83%8F%E3%83%96)である場合に特に便利です。分かりやすいように、これらの手順では次の用語を使用します。

- **ストックサーバ**は発信接続を行うサーバです。このサーバは、ハブサーバ上のピアリザベーションを *使用* します。
- **ハブサーバ**は着信接続を受信するサーバです。管理者は、このサーバにピアリザベーションを *追加* します。


ただし、一方または両方のサーバがハブ、バリデータ、ストックサーバのいずれあっても、これらの手順を使用してピアリザベーションを設定できます。また、よりビジーな状態にあるサーバから発信接続をする場合にもピアリザベーションを使用できますが、以下のプロセスではそのような構成については説明しません。

## 前提条件

これらの手順を実行するには、次の前提条件を満たしている必要があります。

- 両方のサーバの管理者が`rippled`を[インストール](/ja/docs/infrastructure/installation)して実行している。
- 両方のサーバの管理者が協力することに合意し、連絡が取り合える。秘密情報を共有する必要はないため、パブリックな通信チャネルを使用してもかまいません。
- ハブサーバが着信ピア接続を受信できる。ファイアウォールをそのように設定する手順については、[ピアリングのポート転送](/ja/docs/infrastructure/configuration/peering/forward-ports-for-peering)をご覧ください。
- 両方のサーバが、同じ[XRP Ledgerネットワーク](/ja/docs/concepts/networks-and-servers/parallel-networks)（本番XRP Ledger、Testnet、Devnetなど）と同期するように設定されている。


## 手順

ピアリザベーションを使用するには、以下の手順に従います。

### 1.（ストックサーバ）永続ノードキーペアを設定する

ストックサーバの管理者が、以下の手順を実行します。

永続ノードキーペア値をすでにサーバに設定している場合は、[ステップ2: ノード公開鍵をピアの管理者に連絡する](#2%E3%82%B9%E3%83%88%E3%83%83%E3%82%AF%E3%82%B5%E3%83%BC%E3%83%90%E3%81%AE%E3%83%8E%E3%83%BC%E3%83%89%E5%85%AC%E9%96%8B%E9%8D%B5%E3%82%92%E9%80%A3%E7%B5%A1%E3%81%99%E3%82%8B)に進んでください。（例えば、各サーバの永続ノードキーペアは[サーバクラスターの設定](/ja/docs/infrastructure/configuration/peering/cluster-rippled-servers)の一環として設定します。）

永続ノードキーペアの設定は省略可能ですが、この設定をしておけば、サーバのデータベースの消去や新規マシンへの移行が必要となった場合にピア接続の設定を容易に維持することができます。永続ノードキーペアを設定しない場合は、[server_infoメソッド](/ja/docs/references/http-websocket-apis/public-api-methods/server-info-methods/server_info)のレスポンスの`pubkey_node`フィールドに表示される、サーバが自動生成したノード公開鍵を使用できます。

1. [validation_createメソッド](/ja/docs/references/http-websocket-apis/admin-api-methods/key-generation-methods/validation_create)を使用して新しいランダムキーペアを生成します。（`secret`値を省略します。）
例:

```
rippled validation_create

Loading: "/etc/rippled.cfg"
Connecting to 127.0.0.1:5005
{
   "result" : {
      "status" : "success",
      "validation_key" : "FAWN JAVA JADE HEAL VARY HER REEL SHAW GAIL ARCH BEN IRMA",
      "validation_public_key" : "n9Mxf6qD4J55XeLSCEpqaePW4GjoCR5U1ZeGZGJUCNe3bQa4yQbG",
      "validation_seed" : "ssZkdwURFMBXenJPbrpE14b6noJSu"
   }
}
```
`validation_seed`（ノードシード値）と`validation_public_key`値（ノード公開鍵）を保存します。
2. `rippled`の構成ファイルを編集します。

```
vim /etc/opt/ripple/rippled.cfg
```

3. 前のステップで生成した`validation_seed`値を使用して、`[node_seed]`スタンザを追加します。
例:

```
[node_seed]
ssZkdwURFMBXenJPbrpE14b6noJSu
```
すべてのサーバの`[node_seed]`値が一意である必要があります。構成ファイルを別のサーバにコピーする場合は、`[node_seed]`値を削除するか、変更してください。`[node_seed]`は公開しないようにします。不正使用者がこの値にアクセスできた場合、それを使用してサーバを偽装し、XRP Ledgerのピアツーピア通信を行う可能性があります。
4. `rippled`サーバを再起動します。

```
systemctl restart rippled
```


### 2.ストックサーバのノード公開鍵を連絡する

ストックサーバの管理者が、ハブサーバの管理者にストックサーバのノード公開鍵を伝えます。（ステップ1の`validation_public_key`を使用します。）ハブサーバの管理者はこの値を以降のステップで使用する必要があります。

### 3.（ハブサーバ）ピアリザベーションを追加する

ハブサーバの管理者が、以下の手順を実行します。

[peer_reservations_addメソッド](/ja/docs/references/http-websocket-apis/admin-api-methods/peer-management-methods/peer_reservations_add)を使用し、前のステップで入手したノード公開鍵を使用して予約を追加します。例:


```sh
$ rippled peer_reservations_add n9Mxf6qD4J55XeLSCEpqaePW4GjoCR5U1ZeGZGJUCNe3bQa4yQbG "Description here"

Loading: "/etc/opt/ripple/rippled.cfg"
Connecting to 127.0.0.1:5005

{
  "result": {
    "status": "success"
  }
}
```

説明はオプションのフィールドです。この予約は誰のためにしたものかを人間が読み取れる形式のメモを追加できます。

### 4.ハブサーバの現在のIPアドレスとピアポートを連絡する

ハブサーバの管理者は、サーバの現在のIPアドレスとピアポートをストックサーバの管理者に伝える必要があります。ハブサーバが、ネットワークアドレス変換（NAT）を行なうファイアウォールの内側にある場合は、サーバの *外部* IPアドレスを使用します。デフォルトの構成ファイルは、ピアプロトコルにポート51235を使用します。

### 5.（ストックサーバ）ピアサーバに接続する

ストックサーバの管理者が、以下の手順を実行します。

[connectメソッド](/ja/docs/references/http-websocket-apis/admin-api-methods/peer-management-methods/connect)を使用して、サーバをハブサーバに接続します。例:

WebSocket

```
{
    "command": "connect",
    "ip": "169.54.2.151",
    "port": 51235
}
```

JSON-RPC

```
{
    "method": "connect",
    "params": [
        {
            "ip": "169.54.2.151",
            "port": 51235

        }
    ]
}
```

コマンドライン

```
rippled connect 169.54.2.151 51235
```

ハブサーバの管理者が上記の手順に従ってピアリザベーションを設定した場合、自動的に接続され、可能な限り接続が維持されます。

## 次のステップ

サーバの管理者は、サーバに設定された他のピアへの予約を管理できます。（他のサーバからの予約は確認できません。）次のことを実行できます。

- [peer_reservations_addメソッド](/ja/docs/references/http-websocket-apis/admin-api-methods/peer-management-methods/peer_reservations_add)を使用して、ピアリザベーションの追加や説明の更新を行う。
- [peer_reservations_listメソッド](/ja/docs/references/http-websocket-apis/admin-api-methods/peer-management-methods/peer_reservations_list)を使用して、予約先のサーバを確認する。
- [peer_reservations_delメソッド](/ja/docs/references/http-websocket-apis/admin-api-methods/peer-management-methods/peer_reservations_del)を使用して、予約を削除する。
- [peersメソッド](/ja/docs/references/http-websocket-apis/admin-api-methods/peer-management-methods/peers)を使用して、現在接続しているピアと使用している帯域幅の量を確認する。


不正なピアからの接続を即座に切断するAPIメソッドはありませんが、`firewalld`などのソフトウェアファイアウォールを使用すれば、不正なピアからのサーバへの接続をブロックできます。例については、コミュニティーによって作成された[rbhスクリプト](https://github.com/gnanderson/rbh)をご覧ください。

## 関連項目

- **コンセプト:**
  - [ピアプロトコル](/ja/docs/concepts/networks-and-servers/peer-protocol)
  - [コンセンサス](/ja/docs/concepts/consensus-protocol)
  - [並列ネットワーク](/ja/docs/concepts/networks-and-servers/parallel-networks)
- **チュートリアル:**
  - [容量の計画](/ja/docs/infrastructure/installation/capacity-planning)
  - [`rippled`のトラブルシューティング](/ja/docs/infrastructure/troubleshooting)
- **リファレンス:**
  - [peersメソッド](/ja/docs/references/http-websocket-apis/admin-api-methods/peer-management-methods/peers)
  - [peer_reservations_addメソッド](/ja/docs/references/http-websocket-apis/admin-api-methods/peer-management-methods/peer_reservations_add)
  - [peer_reservations_delメソッド](/ja/docs/references/http-websocket-apis/admin-api-methods/peer-management-methods/peer_reservations_del)
  - [peer_reservations_listメソッド](/ja/docs/references/http-websocket-apis/admin-api-methods/peer-management-methods/peer_reservations_list)
  - [connectメソッド](/ja/docs/references/http-websocket-apis/admin-api-methods/peer-management-methods/connect)
  - [fetch_infoメソッド](/ja/docs/references/http-websocket-apis/admin-api-methods/status-and-debugging-methods/fetch_info)
  - [ピアクローラー](/ja/docs/references/http-websocket-apis/peer-port-methods/peer-crawler)