ARCHIVE/xrpl-dev-portal
1
0
Fork 0
mirror of https://github.com/XRPLF/xrpl-dev-portal.git synced 2025-11-20 11:45:50 +00:00
Code Issues Packages Projects Releases Wiki Activity
Files
4911c25c9c55499716603b6959b7d4108016a3f6
xrpl-dev-portal/@i18n/ja/docs/infrastructure/configuration/peering/configure-a-private-server.md
mDuo13 7645140477 Re-levelization: move non-docs content, rename content→docs 
For better URLs, the content folder has been renamed 'docs' and all
other files have been moved up a level. Also, non-docs images have been
moved to the static folder at the top level where they belong.

Many relative paths had to be fixed to make this work.
2024-01-31 17:53:52 -08:00

6.7 KiB
Raw Blame History

html, parent, seo, labels
html parent seo labels
configure-a-private-server.html configure-peering.html
description
サーバーが特定の信頼できるピアのみに接続するように設定します。
コアサーバー
セキュリティ

プライベートサーバーの設定

プライベートサーバーは、オープンなピアツーピアネットワーク内の検出されたピアに直接接続するのではなく、特定の信頼できるピアのみを通じてネットワークに接続するrippledサーバーです。この種の構成は、バリデータに一般的に推奨される任意の対策ですが、その他の特定の目的でも役立ちます。

前提条件

プライベートサーバーを使用するには、次の前提条件を満たしている必要があります。

  • rippledをインストールして最新バージョンにアップデートし、まだ実行していない状態である必要があります。
  • 自社で運用しているプロキシを通じて接続するか、公開ハブを通じて接続するかを決める必要があります。これらの選択肢の違いについては、ピアリング構成のメリットとデメリットを参照してください。
    • プロキシを使用している場合、rippledがインストールされていてプロキシとして使用し実行される別のマシンが必要です。これらのサーバーは、外部のネットワークとプライベートサーバーに接続できる必要があります。
    • どちらの構成でも、接続先のピアのIPアドレスとポートを把握しておく必要があります。

手順

特定のサーバーをプライベートピアとして設定するには、次の手順を実行します。

  1. rippledの構成ファイルを編集します。

    vim /etc/opt/ripple/rippled.cfg

    {% partial file="/docs/_snippets/conf-file-location.md" /%}

  2. プライベートピアリングを有効にします。

    構成ファイルに以下のスタンザを追加するか、コメントを解除します。

    [peer_private]
1

  3. 固定数のピアを追加します。

    構成ファイルに[ips_fixed]スタンザを追加するか、コメントを解除します。このスタンザの各行は、接続先のピアのホスト名またはIPアドレス、1個の空白文字、このピアがピアプロトコル接続を受け付けるポートの順に記載されている必要があります。

    例えば、公開ハブを使用して接続する場合は、以下のスタンザを使用できます。

    [ips_fixed]
r.ripple.com 51235
zaphod.alloy.ee 51235

    サーバーがプロキシを使用して接続している場合は、IPアドレスとポートが、プロキシとして使用しているrippledサーバーの構成と一致している必要があります。これらの各サーバーについては、ポート番号が、サーバーの構成ファイルに記載されているprotocol = peerポート（通常は51235）と一致している必要があります。例えば、構成は次のようになります。

    [ips_fixed]
192.168.0.1 51235
192.168.0.2 51235

  4. プロキシを使用している場合、プロキシをプライベートピアと互いを含めてクラスター化します。

    公開ハブを使用している場合は、このステップをスキップします。

    プロキシを使用している場合、プライベートピアを含むクラスターとしてプロキシを構成します。クラスターの各メンバーは、クラスターの_他の_各メンバーをリストにした[ips_fixed]スタンザを持っている必要があります。ただし、[peer_private]スタンザを持つのはプライベートサーバーのみとします。

    各プロキシでrippledを再起動します。各プロキシサーバーで、次のようにします。

    sudo service systemctl restart rippled

  5. プライベートサーバーでrippledを起動します。

    sudo service systemctl start rippled

  6. [peersメソッド][]を使用して、プライベートサーバーが自身のピアに のみ 接続していることを確認します。

    レスポンスのpeers配列に、構成済みのピアのいずれでもないaddressを持つオブジェクトが含まれていてはなりません。含まれている場合は、構成ファイルを再度確認して、プライベートサーバーを再起動します。

次のステップ

追加の予防対策として、自身のピアでないサーバーからプライベートサーバーへの着信接続をブロックするようにファイアウォールを設定する必要があります。プロキシサーバーを実行している場合は、ファイヤーウォールを通じてプロキシにピアポートを転送するようにします。ただし、プライベートピアでないものに転送します。この設定方法の具体的な手順は、使用するファイアウォールによって異なります。

ファイアウォールがポート80で発信HTTP接続をブロックしないことを確認します。デフォルトの設定では、このポートを使用してvl.ripple.comから最新の推奨バリデータリストをダウンロードします。バリデータリストがないと、サーバーはどのバリデータを信頼してよいかわからず、ネットワークが、いつコンセンサスに至ったかを認識できません。

関連項目

{% raw-partial file="/docs/_snippets/common-links.md" /%}