ポートとファイアウォール
Yagra がファイアウォールに必要とする穴はごくわずかです。コアホストが公開する TCP ポートは 2 つ、ポーラーの UDP リスナーは有効化したパッシブ受信機能のぶんだけ開き、それ以外 — 5 つの ストアすべてとバス — は内部の Docker ネットワークに留まります。外向き接続は厳密に機能単位です。 通知チャネルも転送先も AI プロバイダも設定していない新規インストールは、（イメージの取得を除き） 外向き通信を一切行いません。
インバウンド — コアホスト
Section titled “インバウンド — コアホスト”| ポート | プロトコル | サービス | 備考 |
|---|---|---|---|
8080 |
TCP (HTTP) | Core API | この 1 ポートで REST API（/api/v1）、Prometheus エンドポイント（/metrics）、ヘルスプローブ（/healthz、/readyz）を提供し、YAGRA_ENABLE_MCP が有効なときは /mcp で MCP のツール群も提供します（既定は無効で、このルートは 404 を返します）。ホスト側ポートは YAGRA_API_PORT（compose）または YAGRA_API_ADDR（ネイティブ実行）で変更します。 |
443 |
TCP (HTTPS) | WebUI | nginx（rootless、コンテナポート 8080）がフロントエンドを TLS で配信します。/api と /mcp はコアへプロキシされるため、ブラウザが必要とするのはこのポートだけです。ホスト側ポートは YAGRA_WEB_PORT で変更します — deploy 構成では 443、ソースからビルドする単一ノード構成では 8443。YAGRA_WEB_TLS=off を設定しない限り、平文のリスナーはありません。 |
8081 |
TCP (HTTP) | 2 台目のコア（HA オーバーレイのみ） | 2 コア構成の高可用性オーバーレイは、スタンバイコアの API を別のホストポートにマップします。/readyz はリーダーでのみ 200 を返す（スタンバイは 503）ため、ロードバランサはこれを基準にルーティングできます。 |
UI と API は、ログインパスワード、Bearer トークン、（暗号化前の）デバイス認証情報を運びます。
WebUI のポートは既定で HTTPS なので、前段に何かを置く必要はありません。コアの API ポートは
今も平文です — 8080 を信頼できる LAN の外へ公開せず、機械クライアントを TLS エッジへ移し
終えたら YAGRA_API_BIND=127.0.0.1 で完全に閉じてください。
インバウンド — ポーラー
Section titled “インバウンド — ポーラー”ポーラーのリスナーはすべてオプトインです。各リスナーは対応する *_BIND 変数が設定されて
いるときにだけ存在します（compose ファイルは既定で先頭の 3 つを設定します。無効化するには
.env でその変数を空にしてください）。コンテナは非特権ポートにバインドし、ホスト側の標準
低番号ポートへは compose がマップします。
| コンテナポート | ホスト既定 | プロトコル | サービス | 有効化 / 無効化 |
|---|---|---|---|---|
1514 |
514（YAGRA_SYSLOG_PORT） |
UDP | syslog 受信 | YAGRA_SYSLOG_BIND |
1162 |
162（YAGRA_TRAP_PORT） |
UDP | SNMP トラップ受信（v1/v2c + inform） | YAGRA_TRAP_BIND |
2055 |
2055（YAGRA_FLOW_PORT） |
UDP | NetFlow v5/v9 / IPFIX 受信 | YAGRA_FLOW_BIND |
6343 |
6343（YAGRA_SFLOW_PORT） |
UDP | sFlow v5 受信 | YAGRA_SFLOW_BIND — 既定で無効。ホスト側マッピングは存在しますが、バインドを設定するまで何も待ち受けません |
9100 |
— | TCP (HTTP) | ポーラーの Prometheus /metrics（0.0.0.0:9100 固定） |
compose のポートマッピングでは公開されません。ポーラーをホストネットワーキング（リモート拠点構成）またはネイティブで実行したときに到達できます |
対応するホストポートは、機器がデータを送ってくるネットワークセグメントに対してのみ開けて ください。イベントとノードの突き合わせはデータグラムの送信元 IP をキーに行われるため、 これを書き換えるもの（機器とポーラーの間の NAT）があると対応付けが壊れます — ポーラーは機器の 近くに配置してください。
これらのサービスは内部の Docker ネットワークに留めなければなりません。どの compose ファイル もこれらを公開しておらず、スタックの外からこれらに到達する必要も一切ありません — そのままに してください。
| ポート | サービス | 役割 |
|---|---|---|
5432 |
PostgreSQL | メタデータストア（ノード、設定、ユーザー、アラート履歴） |
6379 |
Redis | ポーラーの死活・割当の一時ミラー（再構築可能） |
4222 |
NATS | コア⇄ポーラーのバス。ジョブメッセージは平文のデバイス認証情報を運ぶため、このポートを公開してよいのは TLS + 認証の設定を整えた場合 — かつリモート拠点ポーラーを運用する場合に限られます。 |
8428 |
VictoriaMetrics | メトリクスの時系列ストア |
9428 |
VictoriaLogs | パッシブイベントのログストア（オプション） |
8123 |
ClickHouse | トラフィックフローストア（オプション） |
機能別のアウトバウンド（egress）
Section titled “機能別のアウトバウンド（egress）”Yagra が行いうるすべての外向き接続と、どのプロセスがそれを行うかの一覧です。ここに挙げた 接続は、いずれも機能を設定するまで発生しません。
| 機能 | 宛先 | プロトコル | 発信元 |
|---|---|---|---|
| Webhook 通知 | 設定した Webhook URL | HTTP/HTTPS | コア |
| メール通知 | YAGRA_SMTP_HOST（既定ポート 465、implicit TLS） |
SMTP | コア |
| PagerDuty 通知 | events.pagerduty.com（EU アカウントは events.eu.pagerduty.com — チャネルの API URL で指定） |
HTTPS | コア |
| Jira Service Management 通知 | api.atlassian.com |
HTTPS | コア |
| 転送 — 中継先 | 設定したコレクタの host:port |
UDP、TCP、または TLS | コア（アクティブ／リーダーのコア — ポーラーではありません） |
| 転送 — BigQuery 転送先 | bigquery.googleapis.com と oauth2.googleapis.com。保存鍵の代わりに Workload Identity を使う場合は GCE メタデータサーバー 169.254.169.254 も |
HTTPS | コア |
| AI 根本原因分析 | 設定した 1 プロバイダのみ: api.anthropic.com（Claude）、generativelanguage.googleapis.com（Gemini）、または {location}-aiplatform.googleapis.com（Vertex AI — 自分の GCP プロジェクト内に留まります）。既定は無効 — プロバイダ未設定なら外向き通信はゼロです。 |
HTTPS | コア |
| シングルサインオン（OIDC） | お使いの ID プロバイダの issuer URL | HTTPS | コア |
| Cisco Meraki 監視 | api.meraki.com（またはリージョナルの api.meraki.cn / api.gov-meraki.com） |
HTTPS | Meraki ジョブを実行するポーラープール |
| 分散トレーシング | OTLP コレクタ（YAGRA_OTEL_ENDPOINT、例: :4318） |
OTLP/HTTP | コアとポーラー |
| IP→ASN 補完データセット | iptoasn.com（週次取得） |
HTTPS | ipasn-updater サイドカー — この機能で外向き通信を必要とする唯一のコンテナ |
ロックダウンしたコアホストのために、繰り返しておく価値のある点が 2 つあります。
- 転送の外向き通信はポーラーではなくコアから発生します。 ポーラーは受信したバイト列を バス経由でコアへ運び、中継も BigQuery へのストリーミングもすべてコアが行います。 転送先へのファイアウォール例外が必要なのはコアホストだけです。
- TLS の中継先では、コレクタの証明書をシステムのトラストストア（および任意でオペレーター 指定の CA 証明書）に対して検証します。検証を無効化するフラグはないため、傍受プロキシの 背後にある TLS 転送先には接続できません。
リモート拠点とファイアウォール
Section titled “リモート拠点とファイアウォール”リモート拠点のポーラーは、アウトバウンドルール 1 本だけ、中央側のインバウンドルールはなしで 済むように設計されています。
- ポーラーは中央の NATS バス（
tls://…:4222）へダイヤルアウトします。中央のファイア ウォールが公開するのは TLS + 認証付きバスのちょうど 1 ポート（YAGRA_NATS_PORT、既定4222）だけで、それ以外は何も公開しません。ポーラーへ向けた穴は開けず、ジョブ割当・結果・ イベント・フローバッチのすべてがこの 1 本の外向き接続の上を流れます。この接続は拠点側の ポートフォワーディングなしで NAT も越えます。 - リモートポーラーの構成はホストネットワーキングを使うため、パッシブリスナーはホストの ポートに直接バインドし、イベントの突き合わせに使う機器の実際の送信元 IP が保たれます （Docker ブリッジはこれを書き換えてしまいます）。
- ポーラーは非 root で動作するため（ファイルケーパビリティは
NET_RAWのみ）、1024 未満の ポートにはバインドできません。既定の高番号ポート（1514、1162）を使い、機器から直接 そこへ送信させるか、拠点のファイアウォールで標準ポートをリダイレクトしてください。
# Redirect the standard syslog/trap ports to the poller's unprivileged listenersiptables -t nat -A PREROUTING -p udp --dport 514 -j REDIRECT --to-ports 1514iptables -t nat -A PREROUTING -p udp --dport 162 -j REDIRECT --to-ports 1162拠点リンクの WAN 帯域
Section titled “拠点リンクの WAN 帯域”転送機能が「機器が送ったとおりのもの」を中継できるよう、ポーラーは常に元のバイト列をコアへ 運びます。パッシブイベントはバス上で生の syslog/トラップ量のおよそ 1.5–1.6 倍になり、 受信したフローデータグラムはすべて、集約ストリームと並行して原本のまま中継されます。中継 フローには 1,000 flows/s あたり 0.4–0.8 Mbit/s — 密にパックするエクスポーターでは最大 ~1 Mbit/s（10,000 では ≈4–8 Mbit/s）— を見込んでください。WAN が落ちても、ポーラーの store-and-forward バッファがローカルでのポーリングを継続し、再接続時にメトリクスを後追いで 補完するため、リンクがフラッピングしても履歴は失われません。