転送

お使いの機器は、すでに syslog、トラップ、フローを Yagra へ送っています。転送機能は、そのデータをさらに先へ渡します。送り先は SIEM、コンプライアンス用のアーカイブ、別のコレクタなどです。

すべての機器に 2 つ目のエクスポート先を設定する必要はありません。Yagra 側が何かを手放すこともありません。

転送とは何か

転送は、受け取ったパッシブデータのフィルタ付きの分岐です。転送先は「このフィルタに一致したものは、そこへも送る」と宣言するだけです。Yagra はこれまでどおり取り込み、照合し、アラートを上げ、保存し続けます。

つまりこれは分岐したコピーであって、迂回ではありません。記録の正本は Yagra のままです。

転送先は、イベント ▸ 転送で設定します。送信の形は意図的に決めてあります。送信はすべてコアが行い、ポーラーは受け取ったバイト列をバス経由でコアへ運ぶだけです。

これで外向き通信の出口が 1 か所にまとまります。ファイアウォールで許可するアドレスは、ポーラーごとに 1 つではなく、全体で 1 つで済みます。本社側で転送先を足しても、リモート拠点のポーラーに新しい外向きのルールは要りません。

高可用性のペア構成では、送信するのは動いているほう（リーダー）のコアだけです。ですからコアが 2 台動いていても、出口は 1 か所のままです。

ソース

転送先が何を受け取るかは、3 つのソース種別で選択します。

ソース	運ぶもの
`syslog`	受信した syslog メッセージ — および Webhook で取り込まれたイベント。これらはこの種別に含まれます
`trap`	受信した SNMP トラップと inform
`flow`	受信したフローエクスポート（NetFlow v5/v9、IPFIX、sFlow）。データグラム丸ごとで中継されます

ポーラーは、元のバイト列を常にコアへ運びます。転送先が 1 つも設定されていなくても運びます。

これは意図的です。「元のバイト列を取っておくかどうか」のスイッチを設けてしまうと、転送の正確さがシステムの性質ではなく設定次第になってしまいます。転送先を足したその瞬間から、バイト単位で正確な出力がそのまま使えるべきです。

ただしリモート拠点では、バスの帯域を使う分の代償があります。外向き通信の要件を見てください。

転送先

転送先の種別は 6 つ。それぞれワイヤ上の挙動が定義されています。

種別	ワイヤ形式	受け付けるソース
Syslog over UDP	RFC 5424	syslog、trap
Syslog over TCP	RFC 6587 のオクテットカウントフレーミング（メッセージ境界が埋め込み改行に耐えます）	syslog、trap
Syslog over TLS	RFC 5425	syslog、trap
SNMP トラップの再送出	UDP 上の SNMPv2c トラップ PDU	trap のみ
フロー中継	元のデータグラムを原本のまま UDP で	flow のみ
BigQuery	ストリーミングインサートによる正規化済みの型付き行	すべて

中継の正確さ。 中継する転送先には、2 つのモードがあります。

原本（verbatim） は、元のデータグラムをバイト単位でそのまま送ります。ですからコレクタは、機器が送ったものをそのまま受け取ります。

復元品（rendered） は、解析済みのフィールドからメッセージを組み立て直したものです。syslog の転送先なら RFC 5424、トラップの転送先なら SNMPv2c のトラップ PDU になります。

組み合わせによっては、「元のもの」を送っても意味がありません。たとえばトラップを syslog の転送先へ中継する場合です。このときは復元品を使います。syslog のポートに届いたトラップ PDU は、そもそも解読できないからです。

上の対応表も、同じ理屈から決まっています。トラップ再送出の転送先が受け付けるのは、トラップだけです。syslog の 1 行から SNMP の PDU は組み立てられません。

syslog 系の転送先が syslog に加えてトラップも受け付けるのは、トラップがログの行へ自然に変換できるからです。実際、たいていの SIEM はトラップをその形で受け取りたがります。

フローの中継は、バイト単位で正確に送るか、送らないかのどちらかです。 フローのエクスポートはテンプレートに縛られたバイナリなので、復元品では代わりが務まりません。ですから API は、フローの転送先で復元品モードを指定すると拒否します。コレクタが解読できないものを、黙って送りつけないためです。

テンプレートのデータグラム（NetFlow v9 / IPFIX が定期的に送るテンプレートの更新）は、フィルタがあってもなくても常に通します。これが通らないと、フィルタ付きのコレクタは受け取ったレコードを永久に解読できなくなるからです。

BigQuery だけは、性質が違います。流れているデータをそのまま写すのではなく、正規化した型付きの行をテーブルへ流し込みます。イベント 1 件で 1 行、フローのレコード 1 件で 1 行です。ですから数か月ぶんの履歴を問い合わせられます。

テーブルは Yagra が作ります（日付でパーティションを切り、クラスタリングも設定します）。ただし データセットは、あらかじめ用意しておいてください。データセットのリージョンは後から変えられず、 Yagra があなたのデータの置き場所を黙って決めることはしないからです。

使う ID には、そのデータセットに対する BigQuery Data Editor ロールを付けてください。認証は 2 通りあります。サービスアカウントの JSON 鍵を貼り付ける（保存時に暗号化され、以後は表示されません）か、コアを Workload Identity 付きの Google Cloud 上で動かしているなら認証情報を空のままにします（この場合、認証情報は一切保存されません）。

有効にする前に、知っておくべきことが 2 つあります。

1 つは、ストリーミングインサートが Google の課金対象であることです。

もう 1 つは、元のバイト列を意図的に保存しないことです。中継したデータグラムは、自分で選んだコレクタを一度通り過ぎるだけです。しかしテーブルのほうは残り続けます。そして syslog の本文には、日常的に認証情報が入ります。バイト単位で正確なアーカイブも必要なら、BigQuery の転送先と中継系の転送先を組み合わせてください。

フィルタ

転送先には、フィルタを付けられます（任意）。中身は最大 32 個の型付き条件で、すべて一致 （match-all）かいずれか一致（match-any）を選びます。1 つの値は 512 文字までです。フィルタが空なら、選んだソースのすべてを転送します。

条件は、フィールド + 演算子 + 値の形です。

イベント側で使えるフィールドは、送信元 IP、ポーラープール、イベント種別、syslog のファシリティと重大度、ホスト名、アプリケーション名、メッセージ本文、トラップ OID、トラップの varbind です。

フロー側で使えるフィールドは、送信元と宛先のアドレス、プロトコル（tcp のような名前でも書けます）、送信元と宛先のポート、送信元と宛先の AS です。

演算子は 12 種類あります。等価、含む、前方一致、正規表現（およびそれぞれの否定）、リストに含まれる、 CIDR に含まれる、数値の範囲です。

どの演算子も、フィールドの型と合っているか検査されます。ポートに正規表現を使ったり、ホスト名に CIDR 判定を使ったりすると、保存の時点で 400 になります。送信のときに黙って無視されることはありません。

よくある使い方を 2 つ挙げます。SIEM 向けに本当に必要なものだけ送る転送先（severity が warning 以上、かつ hostname が拠点コードで始まる）。NetOps 向けに内部レンジだけのフローを残すアーカイブ（src_addr が 10.0.0.0/8 または dst_addr が 10.0.0.0/8）です。

フィルタの効き方は、データの形によって違います。この違いは重要です。

イベントのフィルタは、メッセージ 1 件ごとに厳密です。 syslog の 1 行やトラップは、一致するかしないかのどちらかです。
フローのフィルタは、レコード単位ではなくデータグラム単位です。 中継するフローのデータグラムは、その中のどれか 1 つのレコードが一致した時点で、丸ごと転送されます。一致しなかったレコードも一緒に届きます。

理由は、レコードを取り除くにはデータグラムを組み立て直すしかなく、組み立て直せばバイト単位で正確という約束が壊れるからです。求めたレコードを含む、それより広い集合が届くと考えてください。狭い集合になることはありません。
BigQuery のフローフィルタは、レコード単位で厳密です。 行は独立しているので、一致したレコードだけが行になります。フローを正確に選り分けたいなら、それができるのは BigQuery の転送先です。

安全のための決まりが 2 つあります。

1 つは、フィルタの判定のために見るのが、1 データグラムあたり最大 1,024 レコードまでであること。

もう 1 つは、まったく解読できなかったデータグラムの扱いです。フィルタ付きの転送先では、フィルタを無視して転送するのではなく、捨てて件数に数えます。素通しするフィルタは、閉じてしまうフィルタより悪いからです。

TLS

中継する種別のうち、通信路が守られるのは TLS の syslog 転送先（RFC 5425）だけです。UDP と TCP の syslog、トラップの再送出、フローの中継は、通信路では平文です。

ですからそれらは信頼できるネットワークの中に留めてください。コレクタまでの経路に自分の管理下にない区間があるなら、必ず TLS を選んでください。（BigQuery は性質上 HTTPS です。）

証明書の検証には、システムのトラストストアを使います。加えて、転送先ごとの CA 証明書（PEM）も指定できます。プライベート CA が署名したコレクタ向けです。

検証を無効にすることはできません。そのためのフラグは用意していません。ですから TLS を途中で覗くプロキシの後ろにある転送先へは、接続できません。代わりに、そのプロキシの CA を転送先に追加してください。

CA 証明書は秘密情報ではありません。他の転送先設定と同じように API を行き来します。TLS ではない転送先の種別に指定した場合は、意味を成さないので拒否されます。

信頼性と可視性

遅い転送先や死んだ転送先が Yagra の問題になってはいけません。すべての転送先は次の仕組みで隔離されています。

上限のあるキュー（4,096 メッセージ）。いっぱいになると、その転送先へ向かう新しいメッセージは捨てられ、件数に数えられます。追いつけない転送先のせいで、取り込み・照合・アラートが止まることは決してありません。
転送先ごとのレート制限（任意）。1 秒あたりのイベント数でライセンスやサイジングが決まっているコレクタ向けです。
サーキットブレーカー。送信が 5 回続けて失敗すると開きます。30 秒後に 1 回だけ試し、その送信が成功したときにだけ閉じ直します。死んだコレクタが生むのは、カウンタであって滞留ではありません。
タイムアウトと名前の再解決。接続と書き込みは 5 秒でタイムアウトします。転送先のホスト名は 5 分ごとに引き直すので、長く動き続ける中継もコレクタの引っ越しに追随します。

これらはすべて、転送先ごとに見える形になっています。見られるのは、送信した数、フィルタで除いた数、捨てた数（理由別に、キュー満杯・レート制限・サーキット開放・フィルタ不能・解読不能）、今のキューの深さ、サーキットの状態です。

確認できる場所は 3 つあります。イベント ▸ 転送の画面、GET /api/v1/forwarding/status、そしてコアの Prometheus メトリクスです（捨てた数は yagra_forward_dropped_total に理由別で入ります）。

正確さも同じように監視しています。バイト単位で正確な出力を約束していたのに、元のデータグラムなしで済ませざるを得なかった転送先は、それを数えます。元のバイト列を供給できないポーラーは、画面に名前が出ます。

転送は、黙って質を落とせないように作ってあります。出力が約束より劣るときは、画面がそう言います。

外向き通信の要件

送信はすべてコアが行うため、ファイアウォールの例外が必要なのはコアホストだけです。

転送先の種別	必要な外向き通信
中継（UDP / TCP / TLS の syslog、トラップ、フロー）	コレクタの `host:port`
BigQuery	HTTPS で `bigquery.googleapis.com` と `oauth2.googleapis.com` — 保存鍵の代わりに Workload Identity を使う場合は GCE メタデータサーバー（`169.254.169.254`）も

転送先を追加するまで、何も送信されません。転送先を 1 つも設定していないデプロイは、転送のための外向き通信を一切行いません。

ただし 1 つだけ、出口ではなくバス側で払う代償があります。転送機能が「機器が送ったとおりのもの」を中継できるよう、ポーラーは常に元のバイト列をコアへ運ぶからです。

量の目安は、生のイベント量のおよそ 1.45〜1.64 倍です。加えて、受け取ったフローのデータグラムすべてを、まとめたデータと並べて原本のまま運びます。

これは、リモート拠点のポーラーにとって実際の WAN トラフィックです。サイジングの考え方と外向き通信の一覧は、ポートとファイアウォールにあります。

転送

転送とは何か

ソース

転送先

フィルタ

TLS

信頼性と可視性

外向き通信の要件

関連ページ