ポートとファイアウォール
Yagra がファイアウォールに必要とする穴は、ごくわずかです。
コアのホストが公開する TCP ポートは 2 つです。ポーラーの UDP リスナーは、有効にしたパッシブ受信の ぶんだけ開きます。それ以外 — 5 つのストアとバス — は、内部の Docker ネットワークから出ません。
外向きの接続は、機能ごとに厳密に分かれています。通知チャネルも転送先も AI プロバイダも設定して いない新規インストールは、外向きの通信を一切行いません（イメージの取得は除きます）。
インバウンド — コアホスト
Section titled “インバウンド — コアホスト”| ポート | プロトコル | サービス | 備考 |
|---|---|---|---|
8080 |
TCP (HTTP) | Core API | この 1 ポートで REST API（/api/v1）、Prometheus エンドポイント（/metrics）、ヘルスプローブ（/healthz、/readyz）、/mcp で MCP のツール群を提供します（既定で有効。YAGRA_ENABLE_MCP=false にすると外れ、このルートは 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 でその変数を空にしてください。
コンテナは 1024 以上のポートを開き、ホスト側の標準の小さい番号のポートへは 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.ca / 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 flows/s なら 4〜8 Mbit/s）。
WAN が落ちても、ポーラーの store-and-forward バッファがその場でのポーリングを続けます。つながり 直したときにメトリクスを埋め戻すので、リンクが不安定でも履歴は失われません。