Skip to content

IPC ja JP

Jump to bottom
ArchiBot edited this page Jun 3, 2026 · 65 revisions

プロセス間通信

ASFには、プロセスとのさらなる相互作用に使用できる独自のIPCインターフェイスが含まれています。 IPC は プロセス間通信 の略で、最も簡単に定義するなら、Kestrel HTTP サーバー をベースにした「ASF Web インターフェース」です。これはプロセスとのさらなる連携に使用でき、エンドユーザー向けのフロントエンド（ASF-ui）としても、サードパーティ連携向けのバックエンド（ASF API）としても利用できます。

IPCはあなたのニーズやスキルに応じて、多くの異なるものに使用することができます。 たとえば、ASF とすべてのボットの状態を取得したり、ASF コマンドを送信したり、グローバル設定やボット設定を取得・編集したり、新しいボットを追加したり、既存のボットを削除したり、BGR にキーを送信したり、ASF のログファイルにアクセスしたりするために使用できます。 これらのアクションはすべてAPIによって公開されます。 つまり、実行時にASFと通信し、影響を与える独自のツールやスクリプトをコーディングすることができます。 それに加えて 選択されたアクション(コマンド送信など)は、フレンドリーなWebインターフェイスを介して簡単にアクセスすることができます当社のASF-uiによっても実装されています。

使用法

IPC の グローバル設定プロパティ で IPC を手動で無効にしていない限り、これは既定で有効になっています。 ASFはIPCの起動をログに記録し、IPCインターフェイスが正しく起動したかどうかを確認するために使用できます。

INFO|ASF|Start() IPCサーバーを起動...
INFO|ASF|Start() IPCサーバーの準備ができました!

ASFのhttpサーバーが選択されたエンドポイントでリッスンしています。 IPC 用のカスタム設定ファイルを指定していない場合、デフォルトの 1242 ポートで、IPv4 ベースの 127.0.0.1 と IPv6 ベースの [::1] の両方を含む localhost になります。 上記のリンクからIPCインターフェースにアクセスできますが、ASFプロセスを実行しているものと同じマシンからのみアクセスできます。

ASFのIPCインターフェイスは、予定されている使用方法に応じて、3つの異なる方法でアクセスできます。

最低レベルには、当社のIPCインターフェイスの中核である ASF API があり、他のすべての機能を可能にします。 ASFと直接コミュニケーションを取るために、独自のツール、ユーティリティ、プロジェクトで使用したいものです。

媒体には、ASF APIのフロントエンドとして機能する Swagger documentation があります。 ASF APIの完全なドキュメントを備えており、より簡単にアクセスできます。 これは、ツールを作成することを計画しているかどうかを確認するものです。 APIを通じてASFと通信するはずのユーティリティまたはその他のプロジェクト。

最高レベルには、当社のASFAPIに基づいており、さまざまなASFアクションを実行するためのユーザーフレンドリーな方法を提供する ASF-ui があります。 これはエンドユーザー向けに設計された当社のデフォルトのIPCインターフェースであり、ASF APIを使用して構築できるものの完璧な例です。 必要であれば、--path コマンドライン引数 を指定し、そこに配置したカスタムの www ディレクトリを使用することで、ASF で独自のカスタム Web UI を使用できます。

ASF-ui

ASF-uiは、エンドユーザーのためのユーザーフレンドリーなグラフィカルWebインターフェースを作成することを目的としたコミュニティプロジェクトです。 そのために、 **ASF API**のフロントエンドとして機能します。 様々な行動を容易にすることができます これはASFに付属するデフォルトのUIです。

前述のように、ASF-uiはコアASF開発者によって維持されていないコミュニティプロジェクトです。 ASF-ui repo の独自のフローに従い、すべての関連する質問、問題、バグレポート、提案に使用します。

ASF-uiはASFプロセスの一般的な管理に使用できます。 例えば、ボットを管理したり、設定を変更したり、コマンドを送信したり、ASFで通常利用可能な他の機能を選択したりすることができます。

ASF-ui

ASF API

ASF API は、JSON を主要なデータ形式とする一般的な RESTful Web API です。 HTTPステータスコード(適切な場合)を使用して、レスポンスを正確に記述するために最善を尽くしています。 答えと同様に自分自身を解析することができます 要求が成功したかどうかを知るために そしてそうでなかった場合 その理由を。

当社のASF APIは、適切な /Api エンドポイントに適切なリクエストを送信することでアクセスできます。 これらのAPIエンドポイントを使用して、独自のヘルパースクリプト、ツール、GUIなどを作成できます。 これはまさに、当社のASF-UIが実現したものであり、他のすべてのツールも同じことができます。 ASF APIは、コアASFチームによって公式にサポートされ、維持されています。

利用可能なエンドポイント、説明、要求、応答、httpステータスコード、およびASF APIを考慮したその他すべてのドキュメントについて。 威張ったドキュメント を参照してください。

ASF API

カスタム構成

私たちのIPCインターフェイスは、追加の設定ファイル、 IPC.config をサポートしており、標準のASFの config ディレクトリに配置する必要があります。

利用可能な場合、このファイルは、ASFの Kestrel http サーバの高度な設定と、その他の IPC 関連のチューニングを指定します。 特定の必要性がない限り、このファイルを使用する理由はありません。 ASFはすでに賢明なデフォルトを使用しているため。

構成ファイルは以下の JSON 構造に基づいています:

{
    "Kestrel": {
        "Endpoints": {
            "example-http4": {
                "Url": "http://127.0.0.1:1242"
            },

            "example-http6": {
                "Url": "http://[::1]:1242"
            },

            "example-https4": {
                "Url": "https://127.0.0.1:1242",

                "Certificate": {
                    "Path": "/path/to/certificate.pfx",
                    "Password": "passwordToPfxFileAbove"
                }
            },

            "example-https6": {
                "Url": "https://[::1]:1242",

                "Certificate": {
                    "Path": "/path/to/certificate.pfx",
                    "Password": "passwordToPfxFileAbove"
                }
            },

            "example-unix-socket": {
                "Url": "http://unix:/run/asf-asf/asf.sock"
            }
        },

        "KnownNetworks": [
            "10.0.0.0/8",
            "172.16.0.0/12",
            "192.168.0.0/16"
        ],

        "PathBase": "/"
    }
}

Endpoints - エンドポイントのコレクションです。各エンドポイントには、一意の名前（example-http4 など）と、待ち受けアドレス Protocol://Host:Port を指定する Url プロパティがあります。 デフォルトでは、ASFはIPv4とIPv6のhttpアドレスをリッスンしますが、必要に応じてhttpsの例を追加しています。 必要なエンドポイントのみを宣言する必要があります。上記にいくつかの例を含めているので、より簡単に編集できます。

Host には、localhost、待ち受けるインターフェースの固定 IP アドレス（IPv4/IPv6）、または ASF の HTTP サーバーを利用可能なすべてのインターフェースにバインドする * 値を指定できます。 mydomain.com や 192.168.0.* などの値は * と同じ扱いになります。IP フィルタリングは実装されていないため、リモートアクセスを許可する Host 値を使う場合は、細心の注意を払ってください。 そうすることで、ASFのIPCインターフェイスに他のマシンからアクセスできるようになり、セキュリティ上のリスクが生じる可能性があります。 この場合は、 IPCPassword (および好ましくは独自のファイアウォールも) を最低でも で使用することを強くお勧めします。

KnownNetworks - 信頼できると見なすネットワークアドレスを指定する任意の変数です。 デフォルトでは、ASFはループバックインターフェイス(localhost、同じマシン) のみ を信頼するように設定されています。 このプロパティは二つの方法で使用されています。 まず、 IPCPasswordを省略した場合 次に、既知のネットワークからのマシンのみASFのAPIにアクセスし、セキュリティ対策として他のすべてのマシンを拒否することを許可します。 第二に、このプロパティは、ASFにアクセスする逆プロキシに関して重要です。 ASFは、リバースプロキシサーバーが既知のネットワーク内からの場合にのみ、そのヘッダを尊重します。 問題が発生した場合にリバースプロキシを禁止するのではなく、ASFのアンチブルートフォースメカニズムに関してヘッダを尊重することは非常に重要です。 リバースプロキシで指定されたIPが元のメッセージのソースとして禁止されます。 ここで指定したネットワークには非常に注意してください 信頼されたマシンが侵害されたり誤って設定された場合に備えて、潜在的なIPスプーフィング攻撃と不正アクセスを可能にします。

PathBase - IPCインターフェイスで使用される オプションの ベースパスです。 デフォルトは / であり、大部分のユースケースを変更する必要はありません。 このプロパティを変更すると、 http://localhost:1242/MyPrefix の代わりに http://localhost:1242 のように、IPCインターフェイス全体をカスタムプレフィックスでホストできます。 特定の URL だけをプロキシしたいリバースプロキシ設定と組み合わせる場合は、カスタムの PathBase を使用したいことがあります。たとえば、mydomain.com ドメイン全体ではなく、mydomain.com/ASF だけをプロキシしたい場合です。 通常、そのためには、Web サーバーに mydomain.com/ASF/Api/X -> localhost:1242/Api/X をマッピングするリライトルールを書く必要があります。しかし代わりに、カスタムの PathBase として /ASF を定義することで、mydomain.com/ASF/Api/X -> localhost:1242/ASF/Api/X という、より簡単な設定を実現できます。

本当にカスタムベースパスを指定する必要がない限り、デフォルトのままにするのが最善です。

設定の例

既定のポートを変更する

以下の設定は、デフォルトのASFリスニングポートを 1242 から 1337 に変更するだけです。 任意のポートを選択できますが、1024-32767 の範囲を推奨します。他のポートは通常 登録済み であり、たとえば Linux では root アクセスが必要になる場合があります。

{
    "Kestrel": {
        "Endpoints": {
            "HTTP4": {
                "Url": "http://127.0.0.1:1337"
            },

            "HTTP6": {
                "Url": "http://[::1]:1337"
            }
        }
    }
}

すべてのIPからのアクセスを有効にする

以下の設定はすべてのソースからリモートアクセスを許可します したがって、上記利用可能な についての当社のセキュリティ通知を読んで理解していただくことを確認してください。

{
    "Kestrel": {
        "Endpoints": {
            "HTTP": {
                "Url": "http://*:1242"
            }
        }
    }
}

すべての送信元からのアクセスが必要ない場合、たとえば LAN 内だけでよい場合は、ASF をホストしているマシンのローカル IP アドレス、たとえば 192.168.0.10 を確認し、上記の設定例では * の代わりにそれを使用する方がはるかに適切です。 残念ながら、LAN アドレスが常に同じ場合にのみ可能です。 そうでなければ、おそらく * と、ローカルサブネットのみがASFのポートにアクセスできるようにする上に独自のファイアウォールでより満足のいく結果が得られるでしょう。

TCP の代わりに unix ソケットを使用する

Unix ソケットは Windows 以外のプラットフォームでサポートされています。 以下は、systemd サービス を asf ユーザーで使用している場合、そのまま動作します。 それ以外の場合は、あなたの要件に沿って適応します。

{
    "Kestrel": {
        "Endpoints": {
            "Unix": {
                "Url": "http://unix:/run/asf-asf/asf.sock"
            }
        }
    }
}

ASF には、作成時に unix ソケットを自動的に chmod して 0666 にする独自のロジックがあります。 万が一これが望ましくない場合は、代わりにソケットの基盤となるフォルダーの権限を変更することを推奨します。たとえば、RuntimeDirectoryMode=0700 を systemd オーバーライド の [Service] で使用します。

Unix ソケットは、このタイプの通信をサポートする選択されたソフトウェアにおける標準の TCP ソケットの代替として使用することができます。e. を選択します。 リバースプロキシ メカニズムの上流サーバとして

認証

IPCPassword が null に設定されているため、デフォルトでは、ASF IPCインターフェイスは一切の種類の認証を必要としません。 ただし、IPCPassword が空でない値に設定されて有効になっている場合、ASF の API へのすべての呼び出しには、設定された IPCPassword と一致するパスワードが必要です。 認証または間違ったパスワードを省略すると、 401 - Unauthorized エラーが発生します。 5回の認証に失敗した後(パスワードが間違っています)、 403 - 禁止された エラーで一時的にブロックされます。

認証は二つの方法で行うことができます。

認証 ヘッダー

通常は、HTTP リクエストヘッダー を使用し、Authentication フィールドにパスワードを値として設定してください。 その方法は、ASFのIPCインターフェイスにアクセスするために使用している実際のツールによって異なります。 例えば、 curl を使用している場合は、パラメータとして -H 'Authentication: MyPassword' を追加する必要があります。 このようにして認証はリクエストのヘッダで渡されます。ここでは実際に行われるべきです。

クエリ文字列の パスワード パラメータ

または、呼び出そうとしている URL の末尾に password パラメーターを追加することもできます。たとえば、/Api/ASF だけを呼び出す代わりに、/Api/ASF?password=MyPassword を呼び出します。 このアプローチは十分に良いですが、明らかにオープンでパスワードを公開します。これは必ずしも適切ではありません。 それに加えて、クエリ文字列の余分な引数です。 これはURLの外観を複雑にし、URL固有のように感じさせますが、パスワードはASF API通信全体に適用されます。

どちらの方法でもサポートされており、どちらを選ぶかはあなた次第です。 どこでもHTTPヘッダーを使用することをお勧めします。使用方法はクエリ文字列よりも適切です。 ただし、リクエストヘッダに関連するさまざまな制限により、クエリ文字列もサポートしています。 良い例として、javascript でウェブソケット接続を開始する際に、カスタムヘッダーの不足が挙げられます (RFC によると完全に有効ですが)。 この状況では、クエリ文字列が認証する唯一の方法です。

Swagger ドキュメント

当社のIPCインターフェイスには、ASF-APIとASF-uiに加えて、威張った文書も含まれています。 これは、 /swagger URL の下で利用できます。 Swaggerドキュメントは、API実装と他のツール(ASF-uiなど)の中間者として機能します。 OpenAPI 仕様におけるすべての API エンドポイントの完全なドキュメントと可用性を提供し、他のプロジェクトで簡単に使用できます。 ASF APIの書き込みとテストを簡単に行えます。

ASF APIの完全な仕様として当社のSwaggerドキュメントを使用することとは別に。 ASF-uiで実装されていないものを中心に、さまざまなAPIエンドポイントを実行するユーザーフレンドリーな方法としても使用できます。 SwaggerのドキュメントはASFコードから自動的に生成されます。 ASFのバージョンが含まれているAPIエンドポイントでドキュメントが常に最新の状態になることを保証します。

Swagger ドキュメント

よくある質問

ASFのIPCインターフェイスは安全で安全ですか?

ASF はデフォルトでは localhost アドレスでのみ待ち受けるため、自分のマシン以外から ASF IPC にアクセスすることはできません。 デフォルトのエンドポイントを変更しない限り、ASFのIPCにアクセスするには、攻撃者は自分のマシンに直接アクセスする必要があります。 だから安全で他に誰もアクセスできない 自分のLANからでも

ただし、デフォルトの localhost バインドアドレスを別のものに変更する場合は、許可された IP のみが ASF の IPCインターフェースにアクセスできるように、適切なファイアウォールルールを自分で設定する必要があります。 それに加えて、 IPCPasswordを設定する必要があります。 ASFは、他のマシンがASF APIにアクセスしないようにすることを拒否するため、別のセキュリティ層が追加されます。 この場合、ASFのIPCインターフェースをリバースプロキシの後ろで実行することもできます。

自分のツールやユーザースクリプトを使ってASF APIにアクセスできますか?

これは、ASF APIが設計されたものであり、アクセスするためにHTTPリクエストを送信できるものは何でも使用できます。 ローカルユーザースクリプトは CORS のロジックに従います。また、追加のセキュリティ対策として IPCPassword が設定されている限り、これらについてはすべてのオリジンからのアクセス（*）を許可しています。 これにより、さまざまな認証済みの ASF API リクエストを実行できます。 潜在的に悪意のあるスクリプトを自動的に実行させることはありません( IPCPassword を知る必要があります)。

ASFのIPCにリモートでアクセスすることはできますか?

はい、リバースプロキシを使用することをお勧めします。 これにより、典型的な方法でWebサーバーにアクセスし、同じマシン上のASFのIPCにアクセスします。 あるいは、リバースプロキシで実行したくない場合は、適切な URL を指定して カスタム設定 を使用できます。 たとえば、あなたのマシンが 10.8.0.1 アドレスの VPN 内にある場合、IPC 設定で http://10.8.0.1:1242 の待ち受け URL を設定できます。これにより、プライベート VPN 内からの IPC アクセスは有効になりますが、それ以外の場所からはアクセスできません。

Apache や Nginx などのリバースプロキシの背後に ASF の IPC を使用できますか?

はい, 当社のIPCは、このような設定と完全に互換性があります. セキュリティと互換性を確保するために自分のツールの前でも自由にホストできる 一般的に、ASF の Kestrel HTTP サーバーは非常に安全で、インターネットに直接接続してもリスクはありません。ただし、Apache や Nginx などのリバースプロキシの背後に配置すると、基本認証 で ASF のインターフェースを保護するなど、他の方法では実現できない追加機能を利用できます。

例 Nginx 構成は以下にあります。 私たちは、完全で完全でありながらミニマリズム的な定義を含んでいます。 詳細については、 nginx ドキュメント を参照してください。

map $http_upgrade $connection_upgrade {
    default upgrade;
    ''      close;
}

upstream asf-server {
    # 有効にしている場合は unix ソケットも使用できます。例：unix:/run/asf-asf/asf.sock
    server 127.0.0.1:1242;
}

server {
    listen *:443 ssl;

    ssl_certificate /path/to/your/fullchain.pem;
    ssl_certificate_key /path/to/your/privkey.pem;
    ssl_trusted_certificate /path/to/your/chain.pem;

    server_name asf.mydomain.com;

    location ~* /Api/NLog {
        proxy_pass http://asf-server;

        # ASF へリクエストをプロキシする場合、X-headers は常に指定する必要があります
        # これらは元の IP を正しく識別するために重要であり、ASF が nginx サーバーではなく実際の違反者を BAN できるようにします
        # 指定することで、ASF はリクエストを行ったユーザーの IP アドレスを正しく解決できます - nginx をリバースプロキシとして動作させるためです
        # 指定しない場合、ASF は nginx をクライアントとして扱います - この場合、nginx は従来のプロキシとして動作します
        # ASF と同じマシンで nginx サービスをホストできない場合は、これらに加えて KnownNetworks も適切に設定することをおすすめします
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Host $http_host;
        proxy_set_header X-Forwarded-Proto $scheme;

        # WebSocket プロキシ用に、これら 3 つの追加オプションを追加します。https://nginx.org/en/docs/http/websocket.html を参照してください
        proxy_http_version 1.1;
        proxy_set_header Connection $connection_upgrade;
        proxy_set_header Upgrade $http_upgrade;
    }

    location / {
        proxy_pass http://asf-server;

        # ASF へリクエストをプロキシする場合、X-headers は常に指定する必要があります
         # これらは元の IP を正しく識別するために重要であり、ASF が nginx サーバーではなく実際の違反者を BAN できるようにします
        # 指定することで、ASF はリクエストを行ったユーザーの IP アドレスを正しく解決できます - nginx をリバースプロキシとして動作させるためです
        # 指定しない場合、ASF は nginx をクライアントとして扱います - この場合、nginx は従来のプロキシとして動作します
        # ASF と同じマシンで nginx サービスをホストできない場合は、これらに加えて KnownNetworks も適切に設定することをおすすめします
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Host $http_host;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

Apache の設定例 以下に示します。 詳細については、 apache ドキュメント を参照してください。

<IfModule mod_ssl.c>
    <VirtualHost *:443>
        SSLEngine On
        SSLCertificateFile /path/to/your/fullchain.pem
        SSLCertificateKeyFile /path/to/your/privkey.pem

        ServerName asf.mydomain.com

        # TODO: Apache は大文字小文字を区別しないマッチングを適切に行えないため、最もよく使われる 2 つのケースをハードコードしています
        # 有効にしている場合は unix ソケットも使用できます。例：unix:/run/asf-asf/asf.sock|ws://localhost/
        ProxyPass "/api/nlog" "ws://127.0.0.1:1242/api/nlog"
        ProxyPass "/Api/NLog" "ws://127.0.0.1:1242/Api/NLog"

        # 有効にしている場合は unix ソケットも使用できます。例：unix:/run/asf-asf/asf.sock|http://localhost/
        ProxyPass "/" "http://127.0.0.1:1242/"
    </VirtualHost>
</IfModule>

HTTPS プロトコル経由で IPC インターフェイスにアクセスできますか?

はい, あなたは二つの異なる方法でそれを達成することができます. 推奨される方法は、通常のような https を介してあなたのウェブサーバーにアクセスできるそのためのリバースプロキシを使用することです。 同じマシンのASFのIPCインターフェースで接続します。 この方法でトラフィックは完全に暗号化され、IPCをそのような設定をサポートするために変更する必要はありません。

2つ目の方法は、ASFのIPCインターフェイスに カスタムconfig を指定することです。ここでは、httpsエンドポイントを有効にし、Kestrelのhttpサーバーに直接適切な証明書を提供することができます。 この方法は、他のWebサーバーを実行しておらず、ASF専用に実行したくない場合に推奨されます。 そうでなければ、リバースプロキシメカニズムを使用して満足のいくセットアップを達成する方がはるかに簡単です。

IPC の起動中にエラーが発生します：System.IO.IOException: Failed to bind to address, An attempt was made to access a socket in a way forbidden by its access permissions

このエラーは、マシン上の何かが既にそのポートを使用しているか、将来の使用のために予約されていることを示します。 これは、同じマシン上で2番目のASFインスタンスを実行しようとしている場合に使用できます。 しかし、ほとんどの場合、それは使用状況からポート 1242 を除くWindowsであるため、ASFを別のポートに移動する必要があります。 そのためには、上記の 設定例 に従い、12420 など別のポートを選んでみてください。

もちろん、ASFの使用からポート 1242 をブロックしているものを調べて、それを削除することもできます。 しかし、それは通常、ASFに別のポートを使うように指示するよりもはるかに厄介ですので、ここでは詳しく説明します。

IPCPassword を使用していないときに 403 Forbidden エラーが出るのはなぜですか？

ASF には追加のセキュリティ対策が含まれており、デフォルトでは、設定で IPCPassword が設定されていない場合、ループバックインターフェース（localhost、自分のマシン）からのみ ASF API へのアクセスを許可します。 これは、 IPCPassword を使用する場合、ASFインターフェイスをさらに公開することを決定したすべての人によって設定された 最小 セキュリティ対策にする必要があるためです。

この変更は、無意識のユーザーによって世界中でホストされている大量のASFが悪意のある意図に引き継がれているという事実によって決定されました。 普通は口座もアイテムもないまま放置されるんだ 今、私たちは「世界にASFを開く前に、彼らはこのページを読むことができます」と言うことができます。 しかし、代わりに、デフォルトで安全でないASF設定を禁止する方が理にかなっています。 ユーザーが明示的に許可したい場合は、以下で説明します。

具体的には、IPCPassword を指定せずに ASF へアクセスすることを信頼するネットワークを指定することで、この判断を上書きできます。それらはカスタム設定の KnownNetworks プロパティで設定できます。 ただし、自分が何をしているのかを本当に理解しており、リスクも完全に把握している場合を除き、代わりに IPCPassword を使用するべきです。KnownNetworks を宣言すると、それらのネットワーク内の全員が無条件で ASF API にアクセスできるようになるためです。 私たちは真面目で、人々はすでに自分の逆プロキシと iptables ルールは安全であると信じて足元で自分自身を撃っていました, しかし、彼らはそうではありませんでした. IPCPassword が最初で、時には最後の守護者です。 このシンプルでしかも非常に効果的で安全なメカニズムを拒否するなら 自分のせいにするしかない

英語 ドイツ語 スペイン語 lol-US
ポルトガル語 ロシア語 中国語 中国語（繁体字）

👨‍🏫基本

👨‍🎓️ メイン

🧙 高度

👷 開発者

Clone this wiki locally