ログが来ない原因はログサーバではなかった #11｜FortiGate・Ubiquiti・ESXi・NASのSyslog集約

lucky_una

2026年10月11日 20:32

この記事で分かること

FortiGate / Ubiquiti / ESXi / QNAP / SynologyのLogを一か所へ集めた理由
rsyslogが正常でもLogが届かない時に何を見るか
Policy Based Routingが内部Syslogまで上流へ送ってしまった例
Ubiquiti用TemplateがあるのにFileへ出なかった理由
ESXi Syslogの設定と確認方法

⏪ 前の記事：サーバからInternetへ自由に出さない #10｜内部SquidでOutbound通信を制御する

⏪ 前の記事：侵入の気配に、どこで気づく？｜自宅ネットワークのSyslog・Fluentd・Elasticsearch・ElastAlert監視【番外編】

FirewallもProxyも置いた。

でも障害が起きた時に「どこで止まったか」が分からなければ、多段化した分だけ調査箇所が増える。

そこで次に必要になったのが、同じ時間軸で全部のLogを見ることだった。

そこで、

FortiGate
UCG-Fiber
UniFi Switch
AP
ESXi
QNAP
Synology

などのLogをRHEL8のrsyslogへ集めることにした。

最終的には機器ごとのFileへ分離して保存できた。

だが、最初は全然来なかった。

まずLog Server自身を疑った

最初に見るのは受信側だ。

設定Syntax。

rsyslogd -N1

実際の確認では、Validationは正常終了した。

次にListener。

ss -lunp | grep ':514'
ss -ltnp | grep ':514'

UDP/514でrsyslogdが待っていることも確認できた。

つまり、

rsyslogは待っている。

それでもLogが来ない。

ここで「rsyslogの設定が悪い」と決めつけると沼に入る。

原因の一つはFortiGateのPBRだった

FortiGateには、各VLANからInternetへ出すためのPolicy Based Routingがある。

Catch-allに近いPBRを置くと、

このVLANから来た通信
→ 上流Gatewayへ

と簡単に書ける。

だが、内部のSyslog Server宛通信までそのRuleに乗ると困る。

本来LAN内に残るべき514/TCP・UDPが、上流へ向かってしまう。

実際、Storage系や別SegmentからLog Serverへ送る通信がPBRに拾われる問題があった。

そこで、

内部Log Server宛を先にPBR対象外へする

除外Ruleを追加した。

これは#4のRouting記事で書いた、

「PBRは送るRuleより、乗せないRuleが重要」

の実例でもある。

UbiquitiはTemplateだけ作ってもFileに出ない

rsyslog側には、Ubiquiti機器ごとの出力先Templateを用意していた。

例えば概念的には、

/var/log/syslog/ubiquiti/ucg/...
/var/log/syslog/ubiquiti/aggregation/...
/var/log/syslog/ubiquiti/switch/...
/var/log/syslog/ubiquiti/ap/...

のように分ける。

しかし、Templateを定義しただけではLogはそこへ行かない。

初期状態ではFortiGateの送信元だけがRouting Ruleへ入っており、Ubiquiti側をTemplateへ振り分けるRuleが不足していた。

受信はしていても、期待するFileへ出ない。

ここも、

受信設定と振り分け設定は別

だった。

ESXiは実IPの思い込みでもハマった

ESXi側もSyslogを飛ばす。

設定例はこう。

esxcli system syslog config set --loghost='tcp://<LOG-SERVER>:514'
esxcli system syslog reload

Firewall Rulesetも確認する。

esxcli network firewall ruleset list | grep -i syslog

必要なら有効化する。

ここで別の問題もあった。

「このESXiはこのIPだろう」と思っていた値と、実際のManagement IPが違っていた。

Log集約では送信元IPで振り分けるため、この思い込みがそのまま分類ミスになる。

結局、実機のIPを確認し直し、Ruleを合わせた。

最後は「全部来た」

Routing。

Firewall。

rsyslog Listener。

Template。

送信元判定。

ESXi設定。

一つずつ直した結果、

FortiGate
QNAP
Synology
Ubiquiti
ESXi

からLogが集まり、機器ごとのFileへ分離できた。

派手な仕組みではない。

でも、これがあると後で強い。

「通信できない」

ではなく、

送信元は出したか
↓
FortiGateを通ったか
↓
514へ到達したか
↓
rsyslogが受けたか
↓
どのTemplateへ入ったか

まで追える。

集約すると「ネットワーク全体」が見える

機器ごとにGUIを開いている時は、

それぞれの世界しか見えない。

Logを一か所へ集めると、

Network、Server、Storage、Hypervisorが同じ時間軸で見られる。

この後、k3sやProxy、Security Logまで同じ考え方で扱える。

そして、k3sにはもう一つ別の境界がある。

Pod Networkの中と、物理LANの外。

次回はそこを整理する。

⏩ 次回：#12 k3sと物理ネットワークの境界｜Ingress・VIP・NFSをどうつないだか