ログメッセージをSyslogサーバーへ転送する方法📡

はじめに (対象読者・この記事でわかること)

本記事は、Linux 系サーバーの運用・保守を担当するシステム管理者や、DevOps エンジニア、または自宅で VPS を利用している個人開発者を対象としています。
具体的には、ローカルで生成されたログメッセージを外部の Syslog サーバー（例: rsyslog, syslog-ng, Graylog など）へ安全に転送し、集中管理・可視化・長期保存を実現する方法が理解できるようになります。記事を読み終えると、以下ができるようになります。

• Syslog の基本概念と転送方式（UDP/TCP/TLS）の違いを説明できる
• rsyslog と syslog-ng のどちらかを選択し、設定ファイルを作成できる
• ファイアウォールや SELinux の設定を踏まえて、通信を確実に通す方法が分かる
• 転送失敗時のトラブルシューティング手順を実践できる

このテーマを取り上げた背景は、近年のコンテナ化・マイクロサービス化に伴い、ログの分散収集が不可欠となっている点です。単一サーバーで完結せず、集中型 Syslog サーバーへ集約することで、障害解析やセキュリティ監査が格段に楽になります。

前提知識

この記事を読み進める上で、以下の知識があるとスムーズです。

• Linux のシェル操作（bash）と基本的なファイル編集（vi, nano）
• ネットワークの基礎（IP アドレス、ポート、TCP/UDP の違い）
• rsyslog または syslog-ng のどちらかの基本的なインストール経験

ログ転送の概要と選択肢（背景・要件）

Syslog は、UNIX 系 OS が標準で提供するログ転送プロトコルで、UDP 514 がデフォルトのポートとして広く利用されています。しかし、UDP は信頼性が低く、パケットロスや改ざんのリスクがあります。そのため、重要なログを扱う環境では TCP や TLS（暗号化） を選択することが推奨されます。

転送方式を選ぶ際の主な要件は次の通りです。

要件	推奨プロトコル	理由
高速かつ軽量	UDP	オーバーヘッドが最小。軽微なログに適す
信頼性（再送・順序保証）	TCP	コネクション指向でパケットロス防止
セキュリティ（暗号化・認証）	TLS 上の TCP	データ暗号化＋クライアント認証で機密性確保
大規模環境でのスケーラビリティ	TCP/TLS + ロードバランサ	高負荷でも安定した転送が可能

本稿では、TLS を用いた TCP 転送 を例に、rsyslog を使用した実装手順を紹介します。TLS による暗号化は、外部ネットワークにログを流す場合の最低限のセキュリティ要件を満たすことができます。

具体的な手順と実装方法

1. 前提環境の準備

1‑1. サーバー構成例

役割	ホスト名	OS	主な役割
クライアント	app01	Ubuntu 22.04	アプリケーションログの生成
Syslog サーバー	log01	CentOS Stream 9	rsyslog (TLS) 受信、ログ保存

1‑2. 必要パッケージのインストール

クライアント側（Ubuntu）:

Bash

sudo apt update
sudo apt install -y rsyslog openssl

Syslog サーバー側（CentOS）:

Bash

sudo dnf install -y rsyslog rsyslog-gnutls
sudo systemctl enable rsyslog
sudo systemctl start rsyslog

2. TLS 用証明書の作成

Syslog サーバーが TLS 通信を受け付けるために自己署名証明書を作成します。実運用では社内 CA もしくは商用 CA の証明書を使用してください。

Bash

# 任意のディレクトリで作業
mkdir -p /etc/rsyslog/certs
cd /etc/rsyslog/certs

# 秘密鍵生成 (2048bit)
openssl genrsa -out rsyslog.key 2048

# CSR 作成（CN はサーバーの FQDN に合わせる）
openssl req -new -key rsyslog.key -out rsyslog.csr \
  -subj "/C=JP/ST=Tokyo/L=Chiyoda/O=ExampleInc/OU=IT/CN=log01.example.com"

# 自己署名証明書作成（有効期限 365 日）
openssl x509 -req -days 365 -in rsyslog.csr -signkey rsyslog.key -out rsyslog.crt

作成した rsyslog.key と rsyslog.crt は、/etc/rsyslog/certs/ に配置し、権限を以下のように設定します。

Bash

sudo chown root:root /etc/rsyslog/certs/rsyslog.key
sudo chmod 600 /etc/rsyslog/certs/rsyslog.key
sudo chmod 644 /etc/rsyslog/certs/rsyslog.crt

3. Syslog サーバー側の rsyslog 設定

/etc/rsyslog.d/tls.conf を新規作成し、TLS リスナーを有効化します。

Conf

# TLS 用ポート（514 はデフォルトだが、root 権限が必要なので 10514 に変更）
module(load="imtcp")          # TCP モジュール
module(load="gtls")           # GnuTLS モジュール

# 証明書・秘密鍵のパス
global(
  DefaultNetstreamDriverCAFile="/etc/rsyslog/certs/rsyslog.crt"
  DefaultNetstreamDriverCertFile="/etc/rsyslog/certs/rsyslog.crt"
  DefaultNetstreamDriverKeyFile="/etc/rsyslog/certs/rsyslog.key"
  DefaultNetstreamDriver="gtls"
)

# 10514 ポートで TLS リスニング
input(type="imtcp" port="10514" StreamDriver="gtls" StreamDriverMode="1" StreamDriverAuthMode="anon")

設定後、rsyslog を再起動します。

Bash

sudo systemctl restart rsyslog
sudo ss -ltnp | grep 10514   # リスニング確認

4. クライアント側（app01）の rsyslog 設定

クライアント側は、ローカルのログを TLS 経由でサーバーに転送します。/etc/rsyslog.d/remote.conf を作成。

Conf

# TLS 用モジュールロード
module(load="omfwd")          # Forward モジュール
module(load="gtls")           # GnuTLS

# サーバー証明書のコピー（信頼できる CA の証明書を配置するのがベスト）
# 例としてサーバーの自己署名証明書をそのまま使用
$DefaultNetstreamDriverCAFile /etc/rsyslog/certs/rsyslog.crt
$DefaultNetstreamDriver gtls
$DefaultNetstreamDriverMode 1   # 1 = TLS client mode
$DefaultNetstreamDriverAuthMode anon

# 送信先設定（IP アドレス or FQDN, ポート 10514）
*.* @@log01.example.com:10514

ポイント:

• @@ は TCP、@ は UDP を意味します。TLS で TCP を使うので @@ を使用。
• *.* は全てのファシリティとレベルを転送する意味です。実運用ではフィルタリングを推奨。

設定後、rsyslog を再起動し、ステータスを確認。

Bash

sudo systemctl restart rsyslog
sudo journalctl -u rsyslog -f   # ログが流れるか確認

5. ファイアウォールと SELinux の調整

5‑1. firewalld (CentOS)

Bash

sudo firewall-cmd --add-port=10514/tcp --permanent
sudo firewall-cmd --reload

5‑2. ufw (Ubuntu)

Bash

sudo ufw allow 10514/tcp

5‑3. SELinux（CentOS）

Bash

sudo setsebool -P rsyslogd_tcp_server 1
sudo setsebool -P rsyslogd_tcp_client 1

6. 動作確認

6‑1. ログの送信テスト

クライアント側でテストメッセージを送ります。

Bash

logger -p local0.info "テストメッセージ：Syslog TLS 送信確認"

6‑2. サーバー側で受信確認

Bash

sudo tail -f /var/log/syslog   # Ubuntu 系
sudo tail -f /var/log/messages # CentOS 系

テストメッセージが /var/log/messages に記録されていれば成功です。

7. ハマった点やエラー解決

7‑1. 「permission denied」エラー

原因: 証明書ファイルのパーミッションが緩すぎた。
対策: chmod 600 で鍵ファイルの権限を厳格化し、所有者を root:root に設定。

7‑2. 「failed to connect to remote server」エラー

原因: ファイアウォールでポートが閉じていた、または SELinux が通信をブロックしていた。
対策: firewall-cmd/ufw でポートを開放し、SELinux のブール値 rsyslogd_tcp_server/rsyslogd_tcp_client を有効化。

7‑3. 「certificate verification failed」エラー

原因: クライアント側がサーバー証明書を信頼できなかった。
対策: サーバーの自己署名証明書をクライアント側の caFile に配置し、パスを正しく設定した。

8. ログローテートと保管期間の設定

Syslog サーバーで長期間ログを保持したい場合、logrotate を利用します。/etc/logrotate.d/rsyslog の例:

Conf

/var/log/messages {
    weekly
    rotate 12
    compress
    delaycompress
    missingok
    notifempty
    create 0640 root adm
    postrotate
        /usr/bin/systemctl reload rsyslog > /dev/null 2>/dev/null || true
    endscript
}

この設定で、週次でローテートし、過去 12 週間分を圧縮保存します。

まとめ

本記事では、TLS 暗号化を利用した TCP 通信で Linux のログを外部 Syslog サーバーへ安全に転送する手順 を解説しました。主要なポイントは次の通りです。

• TLS + TCP を選択することで、信頼性とセキュリティを両立
• rsyslog のモジュール設定と証明書管理手順
• ファイアウォール／SELinux の適切な許可設定で通信障害を防止
• トラブルシューティング 例（権限、ポート、証明書検証）を把握

これにより、分散したサーバー群からのログを集中管理し、障害解析やコンプライアンス対応を効率化できます。次のステップとして、Elastic Stack（ELK）や Graylog への連携、または ログのリアルタイム分析 に挑戦してみてください。

参考資料

• rsyslog 公式ドキュメント – TLS 設定
• syslog-ng 公式マニュアル – Secure Transport
• OpenSSL コマンドリファレンス
• Red Hat Enterprise Linux 9 – rsyslog の設定例
• Ubuntu Server Guide – rsyslog を使用したリモートログ転送