想定外のPoppler更新で大混乱:登記情報変換の再構築記

弊所ではこれまで,登記情報等の PDF を変換する手段として,Fedora に含まれる Poppler の「pdftohtml」を利用していました。
しかし,変換時の不具合が発生したため,「pdftotext」へ切り替えることにしました。

この変更により,PDF→html に変換したうえで bash で文字操作を行っていた従来の仕組みを,PDF→テキスト(平文)へ変換してから処理する方式に改めました。

html とテキストでは性質が大きく異なります。
タグがなく,レイアウトの概念もないため,テキストの並び順や内容,さらには PDF の線の位置などから判断して精査する必要があります。

実際に確認してみると,土地や一般建物については情報の位置がほぼ一定で,それほど手間はかかりません。
一方,区分建物と会社登記はレイアウトや内容が多様であり,土地・一般建物に比べて複数のパターンに対応しなければならず,処理が複雑になりました。

さらに,テキスト精査は html を扱う場合よりも文字位置が安定せず,どうしても内容を逐一確認しながら処理する形となります。
そのため,bash の cut などの単純な文字操作では対応しきれず,変数展開を多用することになり,結果として処理速度も低下しました。

こうした調整を重ね,ようやく新しい登記情報変換システムが形になりました。
今後は,変換後のデータに誤りがないか確認しつつ,業務で安定して使えるよう整えていこうと思います。

登記情報から文字を抽出するソフトによる不具合

Fedora42 から 43 にアップデートした際,「pdftohtml」を含む Poppler が同時に 24.x から 25.x へ更新されました。
通常であれば特に問題は生じませんが,登記情報の PDF を html に変換したところ,書式が大きく変わってしまいました。

アップデート前

┏━━━━━━━━━┯━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓&#160;<br/>   ┃専有部分の家屋番号│710-1 ~ 710-44                                ┃&#160;<br/>   ┠─────────┴─────────────┬──┬───────────┬─────┬───────────┨&#160;<br/>   ┃ 表  題  部  (一棟の建物の表示)   │調製│平成8年7月11日  │所在図番号│        ┃&#160;<br/>

アップデート後

┏━━━━━━━━━┯━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓<br/>   ┃専有部分の家屋番号│710-1 ~ 710-44                                ┃<br/>   ┠─────────┴─────────────┬──┬───────────┬─────┬───────────┨<br/>   ┃ 表  題  部  (一棟の建物の表示)   │調製│平成8年7月11日  │所在図番号│        ┃<br/>
   

レイアウトが変わっただけでなく,アンダーバーを含む文字が取り込めなくなるなど,変換精度に影響が出ています。

これにより,申請書・委任状・各種物件データや役員データの管理で使用していた自作の変換ソフトが,文字数やタグ構造の変更にまったく対応できなくなりました。
仕様変更は避けられず,作業全体の見直しを迫られています。

そこで,変換手段を「pdftohtml」から「pdftotext」に切り替えることにしました。
ただ,「pdftotext」では登記情報特有の全角スペースがうまく変換されず,従来の「文字数で位置を特定する方法」が使えなくなりました。結果として,線やレイアウトを手がかりに判定する方式へ移行せざるを得ません。

一日でも早く状況に対応し,システムを復旧させたいところです。

Fedora42→Fedora43

2025年10月28日に Fedora 43 がリリースされたため,メインサーバー(クローズド環境)を早速アップデートしました。

手順は次のとおりです。

#事前準備
dnf upgrade --refresh
reboot -n

#ダウンロード
dnf system-upgrade download --releasever=43 --allowerasing
#(Fingerprintを確認)

#アップグレード実行
dnf system-upgrade reboot

アップグレード後,いつもどおり eFAX サーバーと Nextcloud の設定を再投入する必要がありましたが,
今回は dovecot(IMAP メール受信サーバー)で問題が発生しました。

dovecot が 2.3 から 2.4 にバージョンアップしたことにより,設定記述の方式が一部変更されています。
特に メールのパス指定 が変更されており,元の設定に戻す必要があります。

vi /etc/dovecot/dovecot.conf
mail_path = ~/mail

本来のメールパス

また,「/etc/dovecot/conf.d」以下の 「10-mail.conf」 などの設定ファイルが削除または無効化されていました。
そのため,必要に応じて設定を再作成・再有効化する必要があります。
再作成する場合には,記述方法がver2.3とは異なっているので注意が必要です。
(参考 Dovecot CE「Upgrading Dovecot CE from 2.3 to 2.4」)

テキスト処理で一行目だけエラー?──原因は「BOM付きUTF-8」でした

先日,あるテキストファイルを使ってコマンド処理をしようとしたところ,一行目だけがどうしてもエラーになってしまうという現象に直面しました。

リストファイルの各行をもとにコマンドを生成し,コピペで実行しても一行目だけが動かない
不思議に思い,最終的には一文字ずつ文字コードを調査して原因を特定するに至りました。


原因は「FEFF」──UTF-8のBOM

調査の結果,一行目の先頭に「FEFF」という不可視の文字コード(BOM: Byte Order Mark)が入っていることがわかりました。
この「FEFF」は,UTF-8でBOMありとして保存されたファイルの先頭に付く特殊なコードで,Linux系OS(Fedoraなど)では扱いに注意が必要です。


なぜBOMが入っていたのか?

使用していたクラウドソフトが,スマホ表示に対応するため標準でBOM付きUTF-8形式でテキストを記憶しなければならない仕様になっていたため,Windows側のテキストアプリケーションの設定で「BOMあり」ファイルを作ってしまっていたからです。

その結果,テキスト処理スクリプトやシェルコマンドなどが,一行目を正しく認識できなくなっていたというわけです。


対処法と今後の教訓

テキストエディタで保存形式を確認

・UTF-8(BOMなし)で保存できるようにエディタの設定を見直す

最後に

一見ただの文字列ファイルでも,見えないバイト列が処理を妨げていることがあるという良い教訓になりました。
今後も,テキスト処理を行う際には,BOMの有無や文字コードの確認を忘れずに対応していきたいと思います。


同じように「なぜか1行目だけエラーになる」などの不可解な現象でお悩みの方がいれば,ぜひBOM付きファイルでないか確認してみてください。

Fedora41→42 のリリースとアップグレード

昨日,Fedora42が正式リリースされたようでしたので(参考 fedora MAGAGINE 「What’s New in Fedora Workstation 42」),メインサーバー等をFedora41から42にアップデートしました。
方法は以下のとおりです。

1.いつも通り,現状バージョンの最終アップデート

dnf upgrade --refresh
reboot -n

2.DNFアップグレードパッケージのインストール

dnf install dnf-plugin-system-upgrade

3.Fedoraの新バージョンのダウンロード

dnf system-upgrade download --releasever=42

4.GPG キーを検証します。(識別子が下記サイトと同じかを確認します)OKなら[y]を入力してenterを押します。

場所: Fedora はあなたの安全を守ります

OpenPGP キー ● をインポート中:
UserID: "Fedora (42) <fedora-42-primary@fedoraproject.org>"
識別子: ●
提供元: file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-42-x86_64

Is this ok [y/N]: y

5.ダウンロード後,リブートして更新

dnf system-upgrade reboot

6.各パッケージの正常性を確認します

更新後,1点問題点がありました。postfixが起動していませんでした。よって以下の設定をしています。

#古いパッケージを消す
dnf install remove-retired-packages
remove-retired-packages 41

#コンフィグファイルの更新
dnf install rpmconf
rpmconf -a
#何回かenterを求められる

「/etc/postfix/mail.cf」などが更新されて,加工前のものが「main.cf.proto」に入れられます。

そして,postfixのサービスが停止しているため,改めてスタートさせます。

systemctl start postfix

メールの送信を確認します。

#メールの送信
mail root

以下のエラーが出るため,mtaを変更

s-nail: Cannot start /usr/sbin/sendmail: executable not found (adjust *mta* variable)
alternatives --config mta

再度 mail rootを実行時メール

#メールの送信
mail root

#メールの受信
#→メールクライアントを使用

※追記 postfixの起動だけではメールの送信ができませんでしたので,alternativesを追加しました。

WordPressのアップデートができない!?SELinuxによる書き込み制限

SELinux を運用しながら WordPress を更新する際に,FTP 接続情報の入力画面が表示される 問題についての解決策をまとめました。


問題の原因

SELinux により,WordPress のディレクトリ./wordpress に対して 書き込み権限が制限されている ため,WordPress が通常の 直接更新 を行えず、FTP 接続を求めてきます。

エラーログ(ausearch の出力)からも,httpd_sys_content_t のコンテキストでは 書き込みが許可されていない ことが確認できます。

type=AVC msg=audit(xxxxxxxxx.xxx:xxxxx): avc: denied { write } for pid=xxxx comm="php-fpm" name="wordpress" dev="dm-0" ino=xxxxxxxxx scontext=system_u:system_r:httpd_t:s0 tcontext=unconfined_u:object_r:httpd_sys_content_t:s0 tclass=dir permissive=0

解決策

① SELinux のコンテキストを一時的に変更

以下のコマンドで,WordPress のディレクトリに書き込み権限を付与 する。

sudo chcon -R -t httpd_sys_rw_content_t .(どこか)/wordpress/

この操作で,WordPress が更新ファイルをダウンロードし,直接適用できるようになります。


② WordPress の更新を実施

管理画面から WordPress の更新 を実行する。
FTP 接続画面が表示されずに,直接更新ができるようになります。


③ 更新後、元の SELinux コンテキストに戻す

更新完了後に、本来の SELinux の設定に戻す ことで、余計な書き込み権限を解除します。

sudo restorecon -R -v .(どこか)/wordpress

これにより,WordPress ディレクトリの SELinux コンテキストがデフォルトに戻り,セキュリティが保たれます。


④ 永続的に書き込みを許可する場合(オプション)

頻繁に WordPress を更新する場合は,SELinux の設定を変更して 永続的に書き込みを許可 することもできます。(セキュリティ的にはやや劣後します)

sudo semanage fcontext -a -t httpd_sys_rw_content_t ".(どこか)/
wordpress(/.*)?"
sudo restorecon -R -v .(どこか)/wordpress

まとめ

方法SELinux の設定更新後に戻す必要
chcon で一時的に変更httpd_sys_rw_content_t を適用必要restorecon
semanage fcontext で永続的に許可.(どこか)/wordpress/ のコンテキストを変更不要

どの方法が適切か?

🔹 厳格なセキュリティ管理が必要な場合
 ✅ chcon を使って一時的に変更し,更新後 restorecon で戻す
🔹 他のアプリケーションの影響を最小限にしたい場合
 ✅ semanage fcontext.(どこか)/wordpress のみ書き込み許可

また,「setsebool -P httpd_unified 1」 を有効化する方法もあるようですが,セキュリティ的にさらに劣後することになります。これについては,他サイトを参照してください。(未検証)

これらの方法で,SELinux を有効に保ちつつ,WordPress の更新をスムーズに行えるようになるでしょう。

SELinuxの導入には検証が必要

Fedoraでは,Fedora core 2からSELinuxが導入されています。FedoraサーバーはSELinuxの設定が難しいため,長年当方の業務サーバーでもOFF(disable)にしていました。システムのセキュリティを高めるSELinuxは,強力な機能を持つ一方で,初めて導入する際には設定や運用が複雑で戸惑うこともあります。ここでは,SELinuxの初期設定から運用までのポイントを具体例とともに解説します。


  1. 初期設定:SELinuxを「Permissiveモード」で開始する

SELinuxを導入する際には,まず「Permissiveモード」で動作させ,エラーや警告を監視できる状態に設定するのが良い方法です。

  • カーネルパラメータの設定変更
    SELinuxを完全に無効化(disable)するのではなく,監査モードでエラーを検出できるようにします。
grubby --update-kernel ALL --remove-args selinux

vi /etc/selinux/config

SELINUX=permissive

上記の設定変更後,システムをリブートします。

  1. エラー確認コマンド
    SELinux関連のエラーは以下のコマンドで確認できます。
#直近10分前のエラー
ausearch -m AVC,USER_AVC,SELINUX_ERR -ts recent

#今日発生したエラー
ausearch -m AVC,USER_AVC,SELINUX_ERR -ts today

#昨日と今日のエラー
ausearch -m AVC,USER_AVC,SELINUX_ERR -ts yesterday

各アプリケーションごとの設定例

SELinuxでは,アプリケーションごとに必要な権限を付与する必要があります。以下に具体例を示します。


  1. Samba(ファイルサーバー)

Windowsからファイル共有する場合,以下の設定を行います。

setsebool -P samba_export_all_ro=1 samba_export_all_rw=1
  1. OpenVPN(VPNサーバー)

使用するポートを指定してSELinuxに許可を与えます。

semanage port -a -t openvpn_port_t -p tcp 利用ポート
  1. Apache(Webサーバー)

Apacheでファイル出力やCGI実行を行う場合の設定例です。

  • ファイル出力用ディレクトリ
chcon -R -t httpd_sys_rw_content_t /var/www/cgi-bin/tmp
  • CGIファイルの実行権限
chcon -t -R httpd_sys_script_exec_t /var/www/cgi-bin/tmp/*.cgi
  • (例)特に昔のPukiWikiについては,以下の設定でうまくいました。
chcon -R -t httpd_sys_rw_content_t /var/www/cgi-bin/Pukiwiki
chcon -t httpd_sys_script_exec_t /var/www/cgi-bin/Pukiwiki/
chcon -R -t httpd_sys_script_exec_t /var/www/cgi-bin/Pukiwiki/plugin
  1. WordPress(CMS)

WordPressは複数の設定が必要です。以下に代表的な例を示します。

  • ネットワーク接続の許可
setsebool -P httpd_can_network_connect_db 1
setsebool -P httpd_can_network_connect=on
  • ディレクトリごとの権限設定
#wordpressディレクトリのファイル権限の設定
semanage fcontext -a -t httpd_sys_content_t "/var/www/cgi-bin/wordpress(/.)?"
semanage fcontext -a -t httpd_sys_script_exec_t "/var/www/cgi-bin/wordpress/..php"
restorecon -R -v /var/www/cgi-bin/wordpress

#wordpressのcontentディレクトリのファイル権限の設定
semanage fcontext -a -t httpd_sys_rw_content_t "/var/www/wordpress/wp-content(/.*)?"
restorecon -R -v /var/www/cgi-bin/wp-content

#wordpressのincludesディレクトリのファイル権限の設定
semanage fcontext -a -t httpd_sys_script_exec_t "var/www/cgi-bin/wordpress/wp-includes/.*.php"
restorecon -R -v /var/www/cgi-bin/wordpress/wp-includes/
  • プラグインやメール配信(例:MW WP Formプラグイン)

setsebool -P httpd_can_sendmail 1

任意のアプリーケーション

アプリケーションの動作でエラーが発生する場合,SELinuxログを基にカスタムルールを作成します。以下はルール作成の手順です。

  1. エラーログを確認とポリシーの作成
ausearch -m AVC --start '11/29/24' --end now

(出力例)
time->Tue Dec 3 xx:xx:xx 2024
type=PROCTITLE msg=audit(xxxxxxxxxxxx.xxx:xxxxx): proctitle=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
type=SYSCALL msg=audit((xxxxxxxxxxxx.xxx:xxxxx): arch=x00000xx syscall=xxx success=no exit=-13 a0=ffffffxx a1=xxxxxxxxxxxxxxxxx a2=0 a3=0 items=0 ppid=xxxxx pid=xxxxx auid=xxxxxxxxxxx uid=xx gid=xx euid=xx suid=xx fsuid=xx egid=xx sgid=xx fsgid=xx tty=(none) ses=xxxxxxxxxxx comm=”xxxx” exe=”/usr/sbin/xxxxxxxxx” subj=system_u:system_r:httpd_t:s0 key=(null)
type=AVC msg=audit(xxxxxxxxxxxxxxx.xxx:xxxxx): avc: denied { read } for pid=xxxxx comm=”xxxx” name=”xxxx.xxxx” dev=”dm-0″ ino=xxxxxxxxx scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:object_r:postfix_etc_t:s0 tclass=file permissive=0

tmp_ruleがルール名としてアプリケーション実行日と開始時間を下記に入れて,実行後,素早く実行します。

#下記の例 '月/日/年(2桁)' '時:分:秒' 
ausearch -m AVC --start '11/29/24' '20:39:40' --end now | audit2allow -a -M tmp_rule

これにより,tmp_rule.pp(ポリシーファイル)が生成されます。

  1. ポリシーの適用
semodule -i tmp_rule.pp
  1. ルールを適用してauditaのエラーが出なくなるかを確認します。
ausearch -m AVC,USER_AVC,SELINUX_ERR -ts recent

この方法により,faxやefaxというFAXサーバーについても問題なく運用できるようになりました。


・SELinuxの有効化

1日2日「SELINUX=permissive」のまま

ausearch -m AVC,USER_AVC,SELINUX_ERR -ts yesterday

を入力してログを確認して以下のようにエラーが出なくなることを確認します。

<no matches>

これにより,SELinuxを起動させます。

setenforce 1
vi /etc/selinux/config

SELINUX=enforcing

これによって晴れてSELinuxが運用できるようになりました。


運用上の注意点

  • SELinuxは強力なセキュリティを提供しますが,設定ミスやエラーが原因でアプリケーションが動作しないことがあります。そのため,導入時は「Permissiveモード」で充分に検証してください。
  • 運用中に発生する問題は,適宜ログを確認し,必要に応じてカスタムルールを作成します。

SELinuxの導入と運用には一定の時間と手間がかかりますが,正しく設定すれば堅牢なセキュリティを実現できます。ぜひ,計画的に導入を進めてみてください。

Fedoraサーバーでの頻発するリブートとjournalのエラーへの対処方法

最近,Fedora38からFedora41へとアップデートを行ったサーバーで,3~5時間に1回程度,勝手にリブートがかかるという問題が発生しました。この問題の原因を調査し,最終的に解決した方法について記録します。

問題の概要

はじめに,リブートのタイミングがcrontabで実行されるジョブの時間と一致していたため,定期実行されるプログラムが原因と考えました。しかし,問題を掘り下げるうちに,以下の状況が判明しました。

  1. SELinuxをPermissiveモードに設定すると,さらにリブート頻発時間が短くなる
  2. リブート直前のログが不完全で,途中で切れている/var/log/messages
  3. journalctl --verifyコマンドでジャーナルログの破損を検出

エラーログの確認

リブート直前のログは以下のように記録されていました:

Nov 14 06:40:11 server audit[1]: SERVICE_STOP pid=1 uid=0 auid=xxxx ses=xxxx msg='unit=user-runtime-dir@0 comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Nov 14 06:40:11 server systemd[1]: Removed slice user-0.slice - User Slice of UID 0.
Nov 14 06:40:11 server systemd-logind[748]: Removed session 548.
Nov 5 15:13:30 server su[1540]: (to root) user on pts/0
Nov 5 15:19:00 server smbd[2128]: [2024/11/05 15:19:00.003114, 0] ../../source3/smbd/msdfs.c:97(parse_dfs_path_strict)

journalctl --verifyを実行すると,次のエラーが確認されました:

71ce810: Data object references invalid entry at 10598418
File corruption detected at /var/log/journal/xxxx/system.journal:274295040 (of 276824064 bytes, 99%).
FAIL: /var/log/journal/xxxx/system.journal (不正なメッセージです)
PASS: /var/log/journal/xxxx/user-1000.journal

どうやら,ジャーナルログが破損しており,これが原因でjournaldrsyslogの動作に影響を与えている可能性が高いことがわかりました。


試行錯誤と対策

ログの破損を防ぐため,以下の対応を試みました。

  1. 過去のジャーナルログを削除
journalctl --rotate
journalctl --vacuum-time=1s
  1. ジャーナルログのサイズ制限
    /etc/systemd/journald.confを編集して以下の設定を追加:
SystemMaxUse=2G
SystemMaxFileSize=500M

設定変更後にサービスを再起動:

systemctl restart systemd-journald
  1. ハードウェア検査
    メモリーテスト(Memtest)やSSDのSMART情報をチェック(smartctl -x /dev/sda など)しましたが,特に異常はありませんでした。
  2. Fedoraの再インストール
    上記の対応を行っても,症状が改善されることはありませんでした。そのため,Fedoraを再インストールしました。再インストール後も同様の症状があり,解決しませんでした。

最終的な解決策:サーバー本体(メインボード)の交換

上記の対応を行っても,症状が改善されることはありませんでした。そのため、最終的にメインボードの交換をしました。サーバーの交換後,以下を確認しました:

  • journalctl --verifyでログ破損なし
  • リブートが発生しない

これにより,ハードウェア自体に何らかの故障があった可能性が高いと結論付けました。


再発防止のための設定

再インストール後は,以下のポイントを守ることで,再発を防ぐ体制を整えました。

  1. ジャーナルログの定期チェック
journalctl --verify
  1. バックアップの確保
    システムの変更前に設定ファイルや重要なデータをバックアップ
  2. ハードウェア診断の定期実施
    定期的にメモリやディスクの健全性を確認

まとめ

今回の問題では,サーバー本体の交換が最終的な解決策となりました。おそらく,SSDやメモリー以外のメインボード等のハードウェアが故障した可能性が高いと推測されます。同様の問題に遭遇した際には,まずジャーナルログの破損を疑い,ハードウェアの状態を慎重に確認することも視野に入れる必要がありそうです。

SELinuxのPermissiveの検証でサーバーにリブートし続ける症状が発生

FedoraサーバーでSELinuxを有効にした際の検証プロセスについて,以下の手順と注意点をまとめました。

SELinuxの有効化とモードの設定

内部サーバーのセキュリティ強化のため,SELinuxを有効にしてPermissiveモードでの検証を行いましたが,今回発生した不具合と対処方法を示します。

SELinuxの有効化手順

1.grubbyコマンドを使用してSELinuxを有効化
SELinuxを有効化したい場合,以下のコマンドを使用します。

grubby --update-kernel ALL --remove-args selinux

2.SELinuxのPermissiveモードへの切り替え
SELinuxを有効にしてもいきなりファイルアクセスが制限されないよう,Permissiveモードで動作検証します。これはSELinuxの設定ファイルを編集することで行います。

vi /etc/selinux/config
SELINUX=enforcing

SELINUX=permissive

予期せぬリブートの問題

SELinuxの初回有効化時,ファイルの再ラベリングが自動的に行われるため,その影響でシステムがリブートを繰り返す現象が発生しました。ログによると,/dev 以下でのエラーや,一部の手動で作成したサービスがリブート時に問題を引き起こしていたようです。

対処方法:手動での再ラベリング

1.レスキューモードでの起動
ブートローダーのメニュー画面でレスキューモードの位置で「e」キーを押し,編集画面から「F10」でブートを開始します。

2.手動ラベリングの実行
root権限でログインし,次のコマンドを使って手動で再ラベリングを行います。

/sbin/fixfiles -f -F relabel
reboot

3.再起動後の確認
正常に起動できることを確認し,Permissiveモードでの検証を続けます。

結果と考察

手動の再ラベリングによって,Permissiveモードでのシステムの安定起動が確認できました。なお、手動で作成したサービスや/dev以下のファイルに起因するSELinux関連のエラーが発生する場合には,上記の再ラベリングの作業をする必要があると考えられます。

SELinuxの設定はかなり難しいと感じていますが,今後いつか設定方法をご報告できたらと思います。



Linux(Fedora)サーバーでVPN利用時のVoipとNAT変換の動作

Fedoraサーバーへのセキュリティ向上のため、ファイアウォール設定を従来のiptablesからFirewalldへ移行しましたが、移行後に内線電話で利用しているSIPサーバーが正常に動作しない事態が発生しました。このようなケースにおける検証結果と解決策についてご紹介します。

SIPサーバーは以下のとおりで使っています。

業務ネットワークイメージ

問題の発生状況

Fedoraサーバー上では,SIPサーバーを通じて業務ネットワーク内のWiFi接続(192.168.0.xおよび192.168.1.x)でSIPクライアントを利用しています。SIPクライアント(iphoneアプリ)として使用しているのはAGEPhoneで,VPN経由で接続しています。

移行後,SIPクライアントが「403 Forbidden」エラーを返し,通信ができなくなっていることが判明しました。
パケットキャプチャを使用して詳細を調べたところ,IPマスカレード(NAT変換)の動作により,SIPプロトコルが正しく機能しなくなっていたことがわかりました。

検証結果と原因

以下のように,Firewalldによる設定ではVPNのホスト名に変換され,SIPサーバーが要求するIPアドレス認証に一致しないため,403エラーが発生していました。

すると,iptablesでは,ipアドレスでSIPサーバーにアクセスしていましたが,Firewalldでは,NAT変換されてしました。(「tcpdump host 192.168.0.3」で検証)

iptablesの設定:

192.168.1.x > 192.168.0.3 (SIPのIPアドレスで通信)

Firewalldの設定(IPマスカレード設定時):

vpn.example.com > 192.168.0.3 (ホスト名に変換され通信不可)

この問題の原因は,SIPが発信元IPアドレスの一貫性を必要とする仕様により,NAT変換されたアドレスを受け入れないことにありました。

解決策

Firewalldの設定を見直し,IPマスカレード(NAT変換)を解除することで,SIPサーバーが元のIPアドレスで通信できるようにしました。具体的には,以下のコマンドを使用しました。

firewall-cmd --zone=internal --remove-masquerade --permanent
firewall-cmd --reload

この設定変更により,異なるローカルネットワークでも直接IPアドレスがやり取りされ、SIP通信が可能になりました。パケットキャプチャ上でも発信元のIPアドレスが確認できるようになりますが、SIPの仕様に従うための対応です。

SIPとNAT変換のドキュメントがなかなかありませんでしたが,学会論文誌に掲載がありました。
【情報処理学会論文誌:「ファイアウォールや NAT を通過できる IP 電話の提案と評価」 伊藤将志氏, 鹿間敏弘氏,渡邊晃氏】

他のサービスでの影響

SIPサーバー以外のサービス(Samba,Web,RDP,Ping,SSH等)は,IPマスカレードを使っていても問題なく動作しているため,通常はマスカレードを導入したほうが利便性が向上します。しかし,SIPサーバーを使用する場合は,IPマスカレード解除の設定を行うことが推奨されます。

まとめ

SIPサーバーの設定には,ファイアウォールの詳細設定が関わってきます。Firewalldに移行した際には,各サービスごとの通信要件を確認し,必要に応じてマスカレードの有無を調整することが重要なようです。今後も,安全かつ効率的なネットワーク運用を目指して設定の改善に取り組んでまいります。