linux mint でVPN接続-wireguard

2025/11/20
linux mint で wireguardでVPNを構築したので、覚書です。
antiXでwireguard記事はこちら

Linux Mint でVPN-WireGuard

mintのパッケージにはwireguardは入っていないようなので、手動インストール。
sudo apt update
sudo apt install wireguard wireguard-tools
# wireguard用鍵ペアの作成
# 専用ディレクトリの作成
mkdir -p ~/wireguard-keys

#鍵ペアの作成
wg genkey | tee ~/wireguard-keys/private.key | wg pubkey > ~/wireguard-keys/public.key

chmod 600 ~/wireguard-keys/private.key
sudo nano /etc/wireguard/wg0.conf
[Interface]
PrivateKey = (上で作成した秘密鍵)
Address = 10.200.0.10/32
DNS = 8.8.8.8
PostUp = echo "nameserver 8.8.8.8" > /etc/resolv.conf
PostUp = echo "nameserver 8.8.4.4" >> /etc/resolv.conf
PostDown = systemctl restart systemd-resolved

[Peer]
PublicKey = (中継サーバーの公開鍵)
AllowedIPs = 10.200.0.0/24
Endpoint = 160.xxx.xxx.185:5xxx0
PersistentKeepalive = 25
mintは、resolv.conf が再起動でデフォルト書き換わってしまうので、wireguardを起動するときに、resrlv.confのDNS設定を書き換えます。
wirreguard終了時には、systemd-resolved を再起動して、わざとデフォルトに書き換えさせます。
sudo chmod 600 /etc/wireguard/wg0.conf

手動起動

WireGuard を手動で起動・停止するには、wg-quick というコマンドラインツールを使用します。

1. 手動で接続を開始する

ターミナルを開き、以下のコマンドを実行します。
`wg0` の部分は、`/etc/wireguard/` に配置した設定ファイル名(例: `wg0.conf`)に合わせてください。
sudo wg-quick up wg0
2. 接続状態を確認する

接続が成功したか、現在の状態を確認するには、以下のコマンドを使用します。
ピア(接続先)の情報や、直近のハンドシェイク(通信確立)の時刻が表示されます。
sudo wg show
3. 手動で接続を停止する

接続を終了したい場合は、以下のコマンドを実行します。
sudo wg-quick down wg0

自動起動設定

# WireGuard自動起動を有効化
sudo systemctl enable wg-quick@wg0.service

# 状態確認
sudo systemctl status wg-quick@wg0.service
上記だけでうまくいかないときには、onlineサービスが立ち上がったあとにwireguardが起動するように設定。
# サービスに依存関係を追加
sudo systemctl edit wg-quick@wg0.service
以下を追加:
ini[Unit]
Wants=network-online.target
After=network-online.target
通常の自動起動を有効化
sudo systemctl enable wg-quick@wg0.service

フルトンネルにしたいとき

フルトンネルとは、すべての通信をVPN中継サーバーを通す方法です。
これで世界中のどこからでも、中継サーバー経由でアクセスすることができます。
プロキシですね。

クライアントのwirwguardの設定で以下のようにします。
[Peer]
PublicKey = (中継サーバーの公開鍵)
AllowedIPs = 0.0.0.0/0
Endpoint = 160.xxx.xxx.185:5xxx0
PersistentKeepalive = 25
AllowedIPs = 0.0.0.0/0
とするのがポイントです。

master.cf-Postfixの設定

2025/11/16

claude作

Postfix master.cf :メールサーバーのプロセス管理を理解する

はじめに

Postfixメールサーバーを運用する上で、main.cfと並んで重要な設定ファイルが/etc/postfix/master.cfです。このファイルは、Postfixのマスタープロセスが管理する各種サービスプロセスの動作を定義します。

本記事では、master.cfの構造から実践的な設定例まで、体系的に解説していきます。メールサーバー管理者の方や、Postfixの内部動作を深く理解したい方に向けた内容となっています。

master.cfとは何か

master.cfは、Postfixのマスターデーモン(master)が読み込む設定ファイルで、以下の役割を持ちます:

  • 各サービスプロセスの起動方法の定義
  • ネットワークポートのリスニング設定
  • プロセスの並列度とリソース制限
  • セキュリティ設定(chroot、権限など)
  • サービス間の連携設定

main.cfが「何をするか」を定義するのに対し、master.cfは「どのように実行するか」を定義すると理解できます。

ファイル構造の基本

8つのフィールド

master.cfの各行は、タブまたはスペースで区切られた8つのフィールドで構成されています:

# service type  private unpriv  chroot  wakeup  maxproc command + args
#               (yes)   (yes)    (no)    (never) (100)
# ==========================================================================
smtp      inet  n       -       n       -       -       smtpd

各フィールドの詳細を見ていきましょう。

1. Service(サービス名)フィールド

サービスの識別子またはリスニングアドレスを指定します。

ネットワークサービスの例:

  • smtp - 標準SMTPサービス(ポート25)
  • submission - メール投稿用サービス(ポート587)
  • smtps - SMTP over SSL/TLS(ポート465)
  • 10.0.0.1:smtp - 特定IPアドレスでリスニング
  • [::1]:smtp - IPv6アドレスでリスニング

内部サービスの例:

  • pickup - ローカルメール投入
  • cleanup - メールヘッダー処理
  • qmgr - キューマネージャー
  • rewrite - アドレス書き換え
  • bounce - バウンスメール処理
2. Type(タイプ)フィールド

サービスの接続方式を指定します。

  • inet - TCP/IPネットワーク接続

    smtp      inet  n       -       n       -       -       smtpd
    

    外部からの接続を受け付けるサービスで使用

  • unix - UNIXドメインソケット

    cleanup   unix  n       -       n       -       0       cleanup
    

    内部プロセス間通信で使用

  • fifo - 名前付きパイプ(先入れ先出し)

    pickup    fifo  n       -       n       60      1       pickup
    

    ローカルからのメール投入で使用

  • pass - パススルーサービス
    policy    unix  -       n       n       -       -       spawn
    
    外部プログラムへのパススルーで使用
3. Private(プライベート)フィールド

サービスへのアクセス制限を設定します。

  • y(yes) - Postfixサブシステムのみアクセス可能
  • n(no) - 外部からもアクセス可能
  • -(ハイフン) - デフォルト値(通常はyes)を使用
# プライベートサービス(内部処理用)
cleanup   unix  y       -       n       -       0       cleanup

# パブリックサービス(外部接続受付)
smtp      inet  n       -       n       -       -       smtpd
4. Unpriv(非特権)フィールド

非特権ユーザーでの実行を制御します。

  • y(yes) - postfixユーザーで実行(推奨)
  • n(no) - root権限で実行
  • -(ハイフン) - デフォルト値(通常はyes)を使用

セキュリティの観点から、可能な限りyに設定することが推奨されます。

5. Chroot(chroot)フィールド

chroot jail環境での実行を制御します。

  • y(yes) - $queue_directory内でchroot実行
  • n(no) - 通常環境で実行
  • -(ハイフン) - デフォルト値を使用
# chroot環境で実行(セキュリティ向上)
smtp      inet  n       -       y       -       -       smtpd

# 通常環境で実行(一部機能に必要)
virtual   unix  -       n       n       -       -       virtual

注意点:

  • chroot環境では、必要なライブラリやファイルへのアクセスが制限される
  • DNS解決、SSL証明書アクセスなどで問題が発生する可能性がある
6. Wakeup(起動間隔)フィールド

定期的なプロセス起動の間隔を秒単位で指定します。

  • 0 - ウェイクアップタイマーを使用しない
  • 数値 - 指定秒数ごとに起動
  • 数値? - 条件付き起動(メールがある場合のみ)
  • -(ハイフン) - ウェイクアップなし
# 60秒ごとにローカルメールをチェック
pickup    unix  n       -       n       60      1       pickup

# 300秒ごとにキューを処理
qmgr      unix  n       n       n       300     1       qmgr
7. Maxproc(最大プロセス数)フィールド

同時実行可能な最大プロセス数を制限します。

  • 数値 - 最大プロセス数
  • 0 - 無制限
  • -(ハイフン) - default_process_limit値を使用
# SMTP接続は最大100プロセスまで
smtp      inet  n       -       n       -       100     smtpd

# クリーンアップは無制限
cleanup   unix  n       -       n       -       0       cleanup
8. Command + Args(コマンドと引数)フィールド

実行するプログラムとオプション引数を指定します。

smtp      inet  n       -       n       -       -       smtpd
  -o content_filter=
  -o receive_override_options=no_header_body_checks

主要サービスの詳細解説

SMTP受信サービス(ポート25)

標準的なメール受信サービスの設定:

smtp      inet  n       -       n       -       -       smtpd
  -o content_filter=
  -o receive_override_options=no_header_body_checks
  -o smtpd_client_restrictions=
  -o smtpd_helo_restrictions=
  -o smtpd_sender_restrictions=
  -o smtpd_recipient_restrictions=permit_mynetworks,reject

設定のポイント:

  • 外部からのメール受信を処理
  • スパムフィルターなどのcontent_filterを適用可能
  • 各種制限(restrictions)でアクセス制御
Submissionサービス(ポート587)

認証付きメール送信用サービス:

submission inet n       -       n       -       -       smtpd
  -o syslog_name=postfix/submission
  -o smtpd_tls_security_level=encrypt
  -o smtpd_sasl_auth_enable=yes
  -o smtpd_tls_auth_only=yes
  -o smtpd_reject_unlisted_recipient=no
  -o smtpd_client_restrictions=$mua_client_restrictions
  -o smtpd_helo_restrictions=$mua_helo_restrictions
  -o smtpd_sender_restrictions=$mua_sender_restrictions
  -o smtpd_recipient_restrictions=permit_sasl_authenticated,reject
  -o milter_macro_daemon_name=ORIGINATING

重要な設定:

  • TLS暗号化を強制(smtpd_tls_security_level=encrypt
  • SASL認証を有効化(smtpd_sasl_auth_enable=yes
  • 認証済みユーザーのみ許可
SMTPSサービス(ポート465)

SSL/TLS暗号化SMTP(レガシー):

smtps     inet  n       -       n       -       -       smtpd
  -o syslog_name=postfix/smtps
  -o smtpd_tls_wrappermode=yes
  -o smtpd_sasl_auth_enable=yes
  -o smtpd_reject_unlisted_recipient=no
  -o smtpd_client_restrictions=$mua_client_restrictions
  -o smtpd_helo_restrictions=$mua_helo_restrictions
  -o smtpd_sender_restrictions=$mua_sender_restrictions
  -o smtpd_recipient_restrictions=permit_sasl_authenticated,reject
  -o milter_macro_daemon_name=ORIGINATING
内部処理サービス

Postfixの内部処理を担当するサービス群:

# ローカルメール投入
pickup    unix  n       -       n       60      1       pickup
  -o receive_override_options=no_header_body_checks

# メールクリーンアップ
cleanup   unix  n       -       n       -       0       cleanup

# キューマネージャー
qmgr      unix  n       n       n       300     1       qmgr

# 代替キューマネージャー(oqmgr)
#qmgr     unix  n       n       n       300     1       oqmgr

# TLSセッションキャッシュ管理
tlsmgr    unix  -       -       n       1000?   1       tlsmgr

# アドレス書き換え
rewrite   unix  -       -       n       -       -       trivial-rewrite

# バウンス処理
bounce    unix  -       -       n       -       0       bounce
defer     unix  -       -       n       -       0       bounce
trace     unix  -       -       n       -       0       bounce

# 検証サービス
verify    unix  -       -       n       -       1       verify

# フラッシュサービス
flush     unix  n       -       n       1000?   0       flush

# プロキシマップ
proxymap  unix  -       -       n       -       -       proxymap

# プロキシライト
proxywrite unix -       -       n       -       1       proxymap

配送エージェントの設定

SMTP配送

外部サーバーへのメール配送:

smtp      unix  -       -       n       -       -       smtp
# 高速配送用(並列数増加)
relay     unix  -       -       n       -       -       smtp
  -o smtp_fallback_relay=
ローカル配送

システムユーザーへの配送:

local     unix  -       n       n       -       -       local
仮想配送(Dovecot連携)

仮想ユーザーへの配送(Dovecot LDA使用):

dovecot   unix  -       n       n       -       -       pipe
  flags=DRhu user=vmail:vmail argv=/usr/lib/dovecot/deliver -f ${sender} -d ${user}@${nexthop}
仮想配送(Postfix内蔵)
virtual   unix  -       n       n       -       -       virtual

コンテンツフィルターの統合

SpamAssassin統合
# マスターフィルター設定
smtp      inet  n       -       n       -       -       smtpd
  -o content_filter=spamassassin

# SpamAssassinフィルター定義
spamassassin unix -     n       n       -       -       pipe
  flags=R user=spamd argv=/usr/bin/spamc -e /usr/sbin/sendmail -oi -f ${sender} ${recipient}
Amavisd-new統合
# コンテンツフィルター設定
smtp      inet  n       -       n       -       -       smtpd
  -o content_filter=smtp-amavis:[127.0.0.1]:10024

# Amavisからの戻り
127.0.0.1:10025 inet n  -       n       -       -       smtpd
  -o content_filter=
  -o local_recipient_maps=
  -o relay_recipient_maps=
  -o smtpd_restriction_classes=
  -o smtpd_delay_reject=no
  -o smtpd_client_restrictions=permit_mynetworks,reject
  -o smtpd_helo_restrictions=
  -o smtpd_sender_restrictions=
  -o smtpd_recipient_restrictions=permit_mynetworks,reject
  -o smtpd_data_restrictions=reject_unauth_pipelining
  -o smtpd_end_of_data_restrictions=
  -o mynetworks=127.0.0.0/8
  -o smtpd_error_sleep_time=0
  -o smtpd_soft_error_limit=1001
  -o smtpd_hard_error_limit=1000
  -o smtpd_client_connection_count_limit=0
  -o smtpd_client_connection_rate_limit=0
  -o receive_override_options=no_header_body_checks,no_unknown_recipient_checks,no_milters
Milterインターフェース
# OpenDKIM統合
smtpd     pass  -       -       n       -       -       smtpd
  -o smtpd_milters=inet:127.0.0.1:8891
  -o non_smtpd_milters=inet:127.0.0.1:8891

ポリシーサービスの実装

Postfix Policy Daemon
# ポリシーサービス定義
policy    unix  -       n       n       -       -       spawn
  user=nobody argv=/usr/bin/perl /usr/local/lib/policyd-weight

# SMTPDでの利用
smtpd_recipient_restrictions =
  ...
  check_policy_service unix:private/policy
  ...
Postgrey(グレイリスティング)
# Postgreyサービス
postgrey  unix  -       n       n       -       -       spawn
  user=postgrey argv=/usr/sbin/postgrey --unix=/var/spool/postfix/private/postgrey

パフォーマンスチューニング

並列処理の最適化
# 高トラフィックサイト向け設定
smtp      inet  n       -       n       -       200     smtpd
  -o smtpd_client_connection_count_limit=10
  -o smtpd_client_connection_rate_limit=30

# 配送プロセスの並列化
smtp      unix  -       -       n       -       20      smtp
  -o smtp_destination_concurrency_limit=2
  -o smtp_destination_rate_delay=1s
メモリ使用量の制御
# クリーンアッププロセスの制限
cleanup   unix  n       -       n       -       5       cleanup
  -o message_size_limit=10240000

# キューマネージャーの調整
qmgr      unix  n       n       n       300     1       qmgr
  -o qmgr_message_active_limit=20000
  -o qmgr_message_recipient_limit=20000
接続制限の実装
# レート制限付きSMTPD
smtp      inet  n       -       n       -       -       smtpd
  -o smtpd_client_connection_count_limit=10
  -o smtpd_client_connection_rate_limit=30
  -o smtpd_client_message_rate_limit=100
  -o smtpd_client_recipient_rate_limit=200
  -o anvil_rate_time_unit=60s

セキュリティベストプラクティス

1. Chroot環境の活用
# セキュアな設定例
smtp      inet  n       -       y       -       -       smtpd
submission inet n       -       y       -       -       smtpd

メリット:

  • ファイルシステムアクセスの制限
  • 攻撃時の被害範囲限定

デメリット:

  • 設定の複雑化
  • 一部機能の制限
2. 非特権実行の徹底
# 可能な限り非特権で実行
cleanup   unix  n       y       n       -       0       cleanup
bounce    unix  -       y       n       -       0       bounce
3. TLS/SSL暗号化の強制
# Submissionポートでの暗号化強制
submission inet n       -       n       -       -       smtpd
  -o smtpd_tls_security_level=encrypt
  -o smtpd_tls_mandatory_protocols=!SSLv2,!SSLv3,!TLSv1,!TLSv1.1
  -o smtpd_tls_mandatory_ciphers=high
  -o tls_high_cipherlist=ECDHE+AESGCM:ECDHE+AES256:ECDHE+AES128:DHE+AESGCM:DHE+AES256:DHE+AES128:!aNULL:!eNULL:!EXPORT:!DES:!MD5:!PSK:!RC4
4. 認証の実装
# SASL認証の設定
submission inet n       -       n       -       -       smtpd
  -o smtpd_sasl_auth_enable=yes
  -o smtpd_sasl_type=dovecot
  -o smtpd_sasl_path=private/auth
  -o smtpd_sasl_security_options=noanonymous
  -o smtpd_sasl_local_domain=$myhostname

トラブルシューティング

設定の検証
# 文法チェック
postfix check

# 設定の確認
postconf -n  # main.cfの非デフォルト値
postconf -M  # master.cfの設定

# 特定サービスの確認
postconf -M smtp/inet
設定の適用
# 設定の再読み込み(サービス継続)
postfix reload

# サービスの再起動(一時停止あり)
systemctl restart postfix

# 特定サービスのみ再起動
postfix reload smtp
ログの確認
# リアルタイムログ監視
tail -f /var/log/mail.log

# エラーログの抽出
grep "error\|warning\|fatal\|panic" /var/log/mail.log

# 特定サービスのログ
grep "postfix/smtpd" /var/log/mail.log
デバッグモードの活用
# デバッグ出力を有効化
smtp      inet  n       -       n       -       -       smtpd
  -o debug_peer_list=127.0.0.1
  -o debug_peer_level=3
よくある問題と対処

1. "Connection refused"エラー

# ポートのリスニング確認
netstat -tlnp | grep :25
ss -tlnp | grep :25

# サービスの起動確認
postfix status

2. Chroot関連の問題

# chroot環境に必要なファイルをコピー
mkdir -p /var/spool/postfix/etc
cp /etc/resolv.conf /var/spool/postfix/etc/
cp /etc/services /var/spool/postfix/etc/

3. 権限関連の問題

# 権限の確認と修正
postfix set-permissions
chown -R postfix:postfix /var/spool/postfix

実践的な設定例

小規模オフィス向け設定
# 基本的なメール送受信設定
smtp      inet  n       -       y       -       20      smtpd
submission inet n       -       y       -       20      smtpd
  -o syslog_name=postfix/submission
  -o smtpd_tls_security_level=encrypt
  -o smtpd_sasl_auth_enable=yes
  -o smtpd_recipient_restrictions=permit_sasl_authenticated,reject

pickup    unix  n       -       n       60      1       pickup
cleanup   unix  n       -       n       -       0       cleanup
qmgr      unix  n       n       n       300     1       qmgr
tlsmgr    unix  -       -       n       1000?   1       tlsmgr
rewrite   unix  -       -       n       -       -       trivial-rewrite
bounce    unix  -       -       n       -       0       bounce
defer     unix  -       -       n       -       0       bounce
trace     unix  -       -       n       -       0       bounce
verify    unix  -       -       n       -       1       verify
flush     unix  n       -       n       1000?   0       flush
proxymap  unix  -       -       n       -       -       proxymap
smtp      unix  -       -       n       -       5       smtp
relay     unix  -       -       n       -       -       smtp
showq     unix  n       -       n       -       -       showq
error     unix  -       -       n       -       -       error
retry     unix  -       -       n       -       -       error
discard   unix  -       -       n       -       -       discard
local     unix  -       n       n       -       -       local
virtual   unix  -       n       n       -       -       virtual
lmtp      unix  -       -       n       -       -       lmtp
anvil     unix  -       -       n       -       1       anvil
scache    unix  -       -       n       -       1       scache
高可用性設定
# 複数IPでのリスニング
10.0.0.1:smtp inet n   -       n       -       100     smtpd
10.0.0.2:smtp inet n   -       n       -       100     smtpd

# バックアップMX設定
smtp      inet  n       -       n       -       -       smtpd
  -o smtpd_recipient_restrictions=permit_mynetworks,reject_unauth_destination
  -o smtpd_relay_restrictions=permit_mynetworks,defer_unauth_destination
マルチインスタンス設定
# インスタンス1(社内メール)
smtp-internal inet n   -       n       -       50      smtpd
  -o myhostname=internal.example.com
  -o smtpd_banner=$myhostname ESMTP Internal

# インスタンス2(外部メール)
smtp-external inet n   -       n       -       100     smtpd
  -o myhostname=mx.example.com
  -o smtpd_banner=$myhostname ESMTP
  -o content_filter=amavis:[127.0.0.1]:10024

master.cfカスタマイズのヒント

1. サービス固有の設定オーバーライド

-oオプションを使用して、main.cfの設定を上書きできます:

submission inet n       -       n       -       -       smtpd
  -o smtpd_enforce_tls=yes                    # TLS強制
  -o smtpd_sasl_auth_enable=yes              # SASL認証有効
  -o smtpd_client_restrictions=permit_sasl_authenticated,reject
  -o smtpd_sender_restrictions=              # 送信者制限を無効化
  -o smtpd_recipient_restrictions=permit_sasl_authenticated,reject
  -o smtpd_relay_restrictions=permit_sasl_authenticated,reject
  -o milter_macro_daemon_name=ORIGINATING    # Milter用マクロ
2. カスタムサービスの追加

独自のサービスを追加する例:

# カスタムポリシーサーバー
mypolicy  unix  -       n       n       -       0       spawn
  user=nobody argv=/usr/local/bin/mypolicy-server

# カスタムフィルター
myfilter  unix  -       n       n       -       10      pipe
  flags=Rq user=filter argv=/usr/local/bin/myfilter -f ${sender} -- ${recipient}
3. 条件付き設定の実装

環境変数やmain.cfの変数を参照:

# main.cfで定義された変数を使用
submission inet n       -       n       -       -       smtpd
  -o smtpd_client_restrictions=$submission_client_restrictions
  -o smtpd_sender_restrictions=$submission_sender_restrictions
  -o smtpd_recipient_restrictions=$submission_recipient_restrictions

まとめ

master.cfは、Postfixの心臓部とも言える重要な設定ファイルです。適切に設定することで、以下のメリットが得られます:

  1. セキュリティの向上 - chroot、非特権実行、TLS強制など
  2. パフォーマンスの最適化 - 並列処理、リソース制限の調整
  3. 柔軟な機能拡張 - フィルター統合、カスタムサービスの追加
  4. 細かい制御 - サービスごとの個別設定

設定変更時は必ず以下を実行しましょう:

# 1. 設定の文法チェック
postfix check

# 2. 設定の適用
postfix reload

# 3. ログの確認
tail -f /var/log/mail.log

# 4. 動作テスト
echo "Test mail" | mail -s "Test" user@example.com

メールサーバーの運用は複雑ですが、master.cfの仕組みを理解することで、トラブルシューティングが容易になり、より安全で効率的なメールシステムを構築できます。

参考リンク


本記事は定期的に更新されます。最新のPostfixバージョンでは、一部設定が異なる場合があります。

バーチャルドメインとは

2025/11/16

claudeに書いてもらいました。

なぜ「バーチャル」メールボックスと呼ぶのか? ― Postfixの仮想ドメインの本当の意味

はじめに:素朴な疑問

Postfixの設定を学んでいると、必ず出会う「virtual_mailbox」や「virtual_alias」という用語。なぜわざわざ「バーチャル(仮想)」という言葉が付いているのでしょうか?

メールボックスは実際に存在してメールを受信しているのに、何が「仮想」なのか。この疑問を解くには、メールシステムの歴史を少し振り返る必要があります。

1980年代:メールシステムの原風景

すべてが「実在」だった時代

インターネット黎明期のメールサーバーは、実にシンプルな構造でした。

mail.company.com サーバー
    ↓
UNIXユーザー「john」が存在
    ↓
john@company.com のメール
    ↓
/var/mail/john に保存

この時代、メールアドレスを持つ = UNIXアカウントを持つことと同義でした。johnさんは、メールを読むだけでなく、SSHでサーバーにログインし、プログラムを実行することもできました。これが「実在」メールボックスの原型です。

「実在」の具体的な意味

「実在」とは、文字通りシステムに実在するユーザーアカウントを指します:

# johnというユーザーが「実在」する証拠
$ grep john /etc/passwd
john:x:1001:1001:John Smith:/home/john:/bin/bash

$ ls -la /home/john
drwxr-xr-x 5 john john 4096 Nov 16 10:00 .

$ ls -la /var/mail/john
-rw-rw---- 1 john mail 24576 Nov 16 10:00 /var/mail/john

メールアドレスjohn@company.comは、UNIXユーザーjohnと完全に一体化していました。

1990年代:インターネットビジネスの勃興

問題の発生:1台のサーバーで複数の会社をホストしたい

インターネットの商用化が進むと、ホスティング事業者は難題に直面しました。

【要求】
A社: john@company-a.com が欲しい
B社: john@company-b.com が欲しい

【従来の方法では...】
john@company-a.com → UNIXユーザー「john」
john@company-b.com → UNIXユーザー「john」...あれ?

同じ名前のUNIXユーザーは作れない!

さらに深刻な問題もありました:

  1. セキュリティリスク:メールユーザー全員にシェルアクセス権限を与えるのは危険
  2. 管理の複雑さ:1000社のクライアント = 数万のUNIXアカウント?
  3. リソースの無駄:メールしか使わないのにフルアカウント

解決策:「仮想化」という発想の転換

バーチャルメールボックスの誕生

そこで生まれたのが「バーチャル(仮想)」メールボックスという概念です。

【従来:実在メールボックス】
john@company.com
    ↓
UNIXユーザー「john」(必須)
    ↓
/var/mail/john

【新案:バーチャルメールボックス】
john@company-a.com
    ↓
UNIXユーザー不要!(ここが「仮想」)
    ↓
/var/vmail/company-a.com/john/
なぜ「バーチャル」と呼ぶのか

「バーチャル」という名称は、以下の特徴を端的に表現しています:

1. OSから見えない存在

# 実在ユーザーの場合
$ id john
uid=1001(john) gid=1001(john) groups=1001(john)

# バーチャルユーザーの場合
$ id john@company-a.com
id: 'john@company-a.com': no such user
# → OSレベルでは存在しない「仮想的」な存在

2. 物理リソースとの分離

実在ユーザーは物理的なリソース(UID、ホームディレクトリ、プロセス)と1:1で対応しますが、バーチャルユーザーはPostfixの中にだけ存在する論理的な概念です。

3. 抽象化レイヤーの追加

アプリケーション層:john@company-a.com(仮想的に存在)
        ↓ マッピング
  OS層:vmail ユーザー(実際のファイル操作はこのユーザー)

現代的な理解:仮想化技術との類似性

仮想マシンとの類推

現代のエンジニアにとって、「バーチャル」という概念は仮想マシンやコンテナを通じて馴染み深いものとなりました。

【仮想マシン】
物理サーバー1台
  ├── VM: Webサーバー(仮想)
  ├── VM: DBサーバー(仮想)
  └── VM: アプリサーバー(仮想)

【バーチャルメールボックス】
メールサーバー1台
  ├── company-a.com のメール環境(仮想)
  ├── company-b.com のメール環境(仮想)
  └── company-c.com のメール環境(仮想)

どちらも1つの物理リソースを論理的に分割して、あたかも独立した環境のように見せる技術です。

クラウド時代の視点

現在、私たちが日常的に使うメールサービスを考えてみましょう:

  • Gmail:Googleのサーバーのどこかにある「仮想的」なメールボックス
  • Office 365:Microsoftのクラウド上の「仮想的」なメールボックス
  • 企業メール:ほぼすべてが「仮想的」なメールボックス

実は、現代のメールは、ほぼすべてが「バーチャル」なのです。

実在 vs バーチャル:それぞれの使いどころ

実在メールボックスが適している場面

今でも実在メールボックス(mydestination)には存在意義があります:

  • サーバー管理者用:rootやpostmasterなどのシステムメール
  • 小規模環境:10人以下の固定メンバー
  • 開発環境:シンプルさが優先される場面
バーチャルメールボックスが必須な場面
  • メールホスティング:複数顧客へのサービス提供
  • 大規模組織:数百〜数千のメールアカウント管理
  • セキュリティ重視:メールとシステムアクセスの分離

用語の変遷と現在

時代とともに変わる認識
1980年代:「メールボックス」= 実在が当たり前
    ↓
1990年代:「バーチャル」= 革新的な新技術
    ↓
2000年代:「バーチャル」= 業界標準
    ↓
2020年代:「バーチャル」= もはや意識されない当たり前

興味深いことに、「バーチャル」という修飾語は歴史的な名残として残っていますが、現代ではむしろ「バーチャルじゃない」メールボックスの方が特殊になりました。

言葉の背後にある本質

「バーチャル」という言葉が教えてくれるのは、技術の抽象化の歴史です:

  1. 物理からの解放:ハードウェアの制約から自由に
  2. 論理的な設計:ビジネスロジックに最適化
  3. スケーラビリティ:1から100,000まで同じ仕組みで

まとめ:「バーチャル」は進化の証

Postfixにおける「バーチャル」という名称は、メールシステムが物理的な制約から解放され、論理的で柔軟な設計へと進化した証です。

  • 実在= OSと一体化した原始的なメールボックス
  • バーチャル= OSから独立した、アプリケーション層での論理的な存在

この「仮想化」という発想は、その後のIT業界全体のトレンドを先取りしていました。仮想マシン、コンテナ、クラウド...すべては「物理から論理への抽象化」という同じ流れの中にあります。

次にPostfixの設定でvirtual_mailbox_domainsを見かけたら、それが単なる設定項目ではなく、メールシステムの進化の歴史を体現する言葉だということを思い出してみてください。


補足:設定例で見る「実在」と「バーチャル」の違い

最後に、実際の設定例で両者の違いを確認してみましょう:

実在メールボックスの設定
# main.cf
mydestination = example.com

# 結果
admin@example.com → /var/mail/admin (UNIXユーザー「admin」が必要)
john@example.com  → /var/mail/john  (UNIXユーザー「john」が必要)

# 必要な作業
$ useradd admin
$ useradd john
バーチャルメールボックスの設定
# main.cf
virtual_mailbox_domains = client-a.com, client-b.com
virtual_mailbox_base = /var/vmail
virtual_uid_maps = static:5000
virtual_gid_maps = static:5000

# vmailbox
admin@client-a.com    client-a.com/admin/
admin@client-b.com    client-b.com/admin/

# 結果
admin@client-a.com → /var/vmail/client-a.com/admin/ (vmailユーザーで統一)
admin@client-b.com → /var/vmail/client-b.com/admin/ (vmailユーザーで統一)

# 必要な作業
$ useradd -u 5000 vmail  # 1ユーザーだけ作ればOK!

この差が、まさに「実在」と「バーチャル」の本質的な違いを物語っています。

Postfixのバーチャルメールボックス

2025/11/16

Postfixで複数ドメインを運用する:4つの方式を理解する

バーチャルドメインの説明

バーチャルドメイン(仮想ドメイン)とは、1台のメールサーバーで複数のドメインのメールを処理する技術です。物理的には1つのPostfixサーバーでありながら、あたかも複数の独立したメールサーバーが存在するかのように動作させることができます。

例えば、以下のような複数のドメインを1台のサーバーで運用できます:

  • company-a.com
  • company-b.jp
  • subsidiary.net
  • old-domain.org

また、同じドメインのサブドメインでメール運用する場合にも必須の技術となります。
バーチャルドメイン、バーチャルメールボックスの歴史は、バーチャルドメインとは にて。

バーチャルドメインの有用性

1. コスト削減

  • サーバー台数を削減し、ハードウェアコストを抑制
  • 管理工数の削減による人件費の節約
  • 電力消費やデータセンター費用の削減

2. 管理の効率化

  • 一元的な管理による運用負荷の軽減
  • バックアップやセキュリティ対策の統合
  • 監視システムの簡素化

3. リソースの有効活用

  • サーバーリソースを複数ドメインで共有
  • 負荷分散の最適化
  • スケーラビリティの向上

4. 柔軟なサービス提供

  • ドメイン単位での細かな設定が可能
  • 企業の合併・分割への迅速な対応
  • マルチテナント環境の実現

Postfixにおける4種類のドメイン運用方式

Postfixでは、複数ドメインを運用するために4つの方式が用意されています。それぞれに明確な役割と用途があり、適切に使い分けることで効率的なメールシステムを構築できます。

4つの方式の比較と優先順位

使い分けまとめ表

優先順位 方式 メールの最終目的地 UNIXアカウント 主な用途 設定の複雑さ
1 mydestination このサーバー(ローカル配送) 必須 サーバー自身のメール ★☆☆
2 virtual_alias_domains 転送先アドレス 不要 エイリアス・転送専用 ★★☆
3 virtual_mailbox_domains このサーバー(仮想メールボックス) 不要 ホスティング・企業メール ★★★
4 relay_domains 別のメールサーバー 不要 ゲートウェイ・中継 ★★☆

重要: Postfixは上記の優先順位で評価を行います。同一ドメインが複数の方式に設定されている場合、優先順位の高い方のみが適用されます。

各方式の詳細解説

1. mydestination方式

概要

最も基本的な方式で、Postfixがローカル配送として扱うドメインを指定します。システムのUNIXアカウント(/etc/passwd)と直接対応し、メールは/var/mail/配下に保存されます。

適用場面
  • メールサーバー自身のホスト名ドメイン
  • 管理者用のシステムメール受信
  • 小規模な社内メールサーバー(10人以下)
  • 開発・テスト環境
メリット・デメリット

メリット:

  • 設定が最もシンプルで理解しやすい
  • システムツール(procmail、mail等)との連携が容易
  • メール配送が高速

デメリット:

  • UNIXアカウントが必須(セキュリティリスク)
  • ユーザー名がメールアドレスの一部になる制約
  • ユーザー名が同じであれば、別ドメインでも同一メールボックスに入ってしまう。
  • 大規模運用には不向き
設定例
# /etc/postfix/main.cf
myhostname = mail.example.com
mydomain = example.com
myorigin = $mydomain
mydestination = $myhostname, localhost.$mydomain, localhost, example.com

# メールアドレス例:
# root@example.com → /var/mail/root
# john@example.com → /var/mail/john (UNIXユーザー「john」が必要)

2. virtual_alias_domains方式

概要

メールアドレスを別のアドレスに転送・エイリアス化する方式です。実際のメールボックスは持たず、転送専用として機能します。

適用場面
  • info@、support@などの共有メールアドレス
  • 部署やグループへの一斉転送
  • ドメイン移行時の旧アドレスから新アドレスへの転送
  • キャッチオールアドレスの設定
メリット・デメリット

メリット:

  • UNIXアカウント不要でセキュア
  • 柔軟な転送ルール設定が可能
  • 複数の転送先を指定可能

デメリット:

  • 独立したメールボックスを持てない
  • 必ず転送先が必要
  • SPF/DKIM/DMARCの考慮が必要
設定例
# /etc/postfix/main.cf
virtual_alias_domains = virtual1.com, virtual2.com, old-company.jp
virtual_alias_maps = hash:/etc/postfix/virtual

# /etc/postfix/virtual
# 個別転送
info@virtual1.com         admin@example.com
support@virtual1.com      team@example.com, leader@example.com

# 部署への転送
sales@virtual2.com        sales-team@example.com
tech@virtual2.com         dev-team@example.com

# キャッチオール(その他全て)
@old-company.jp           archive@new-company.jp

# 設定反映
$ sudo postmap /etc/postfix/virtual
$ sudo systemctl reload postfix

3. virtual_mailbox_domains方式

概要

完全な仮想メールボックスシステムで、UNIXアカウントと独立したメールアカウント管理を実現します。大規模なメールホスティングに最適です。

適用場面
  • メールホスティングサービス
  • 複数企業のメール環境提供
  • 大規模組織のメールシステム
  • SaaSアプリケーションのメール機能
メリット・デメリット

メリット:

  • 完全に独立したメール環境
  • データベース(MySQL/PostgreSQL)連携可能
  • 柔軟なユーザー管理とクォータ設定
  • マルチテナント対応

デメリット:

  • 設定が最も複雑
  • Dovecot等のIMAPサーバーとの連携必須
  • 管理ツールが必要な場合が多い
設定例
# /etc/postfix/main.cf
virtual_mailbox_domains = client1.com, client2.com, hosting.jp
virtual_mailbox_base = /var/mail/vhosts
virtual_mailbox_maps = hash:/etc/postfix/vmailbox
virtual_minimum_uid = 100
virtual_uid_maps = static:5000
virtual_gid_maps = static:5000

# メールボックス用ユーザー作成
$ sudo groupadd -g 5000 vmail
$ sudo useradd -g vmail -u 5000 vmail -d /var/mail/vhosts -m

# /etc/postfix/vmailbox
# メールアドレス → メールボックスパス
admin@client1.com          client1.com/admin/
user1@client1.com          client1.com/user1/
info@client2.com           client2.com/info/
sales@hosting.jp           hosting.jp/sales/

# ディレクトリ作成と権限設定
$ sudo mkdir -p /var/mail/vhosts/client1.com
$ sudo mkdir -p /var/mail/vhosts/client2.com
$ sudo mkdir -p /var/mail/vhosts/hosting.jp
$ sudo chown -R vmail:vmail /var/mail/vhosts

# 設定反映
$ sudo postmap /etc/postfix/vmailbox
$ sudo systemctl reload postfix
データベース連携の例(MySQL)
# /etc/postfix/main.cf(MySQL連携版)
virtual_mailbox_domains = proxy:mysql:/etc/postfix/mysql-virtual-domains.cf
virtual_mailbox_maps = proxy:mysql:/etc/postfix/mysql-virtual-mailbox.cf

# /etc/postfix/mysql-virtual-domains.cf
user = mailuser
password = mailpassword
hosts = 127.0.0.1
dbname = mailserver
query = SELECT 1 FROM virtual_domains WHERE name='%s'

# /etc/postfix/mysql-virtual-mailbox.cf
user = mailuser
password = mailpassword
hosts = 127.0.0.1
dbname = mailserver
query = SELECT maildir FROM virtual_users WHERE email='%s'

4. relay_domains方式

概要

メールを別のサーバーへ中継(リレー)する方式です。このサーバーは最終的な配送先ではなく、中継点として機能します。

適用場面
  • メールセキュリティゲートウェイ
  • バックアップMXサーバー
  • 支社や関連会社への中継サーバー
  • DMZ配置の中継サーバー
メリット・デメリット

メリット:

  • セキュリティ層の追加が可能
  • 負荷分散とフェイルオーバー対応
  • 内部ネットワークの隠蔽

デメリット:

  • 設定ミスによるオープンリレーのリスク
  • 配送遅延の可能性
  • トラブルシューティングが複雑
設定例
# /etc/postfix/main.cf
# メールゲートウェイとしての設定
relay_domains = protected-company.com, subsidiary.jp
relay_recipient_maps = hash:/etc/postfix/relay_recipients
transport_maps = hash:/etc/postfix/transport

# セキュリティ設定
smtpd_recipient_restrictions = 
    permit_mynetworks,
    reject_unauth_destination,
    reject_unknown_recipient_domain

# /etc/postfix/relay_recipients
# 実在するアドレスのみを登録(バックスキャッター対策)
ceo@protected-company.com         OK
staff@protected-company.com       OK
all@subsidiary.jp                 OK

# /etc/postfix/transport
# 転送先の指定
protected-company.com    smtp:[192.168.1.10]:25
subsidiary.jp           smtp:[mail.subsidiary.jp]:25

# 設定反映
$ sudo postmap /etc/postfix/relay_recipients
$ sudo postmap /etc/postfix/transport
$ sudo systemctl reload postfix

実践的な組み合わせ例

実際の運用では、これらの方式を組み合わせて使用することが一般的です。以下に、典型的な企業環境での設定例を示します。

中規模企業の統合メールサーバー設定例

# /etc/postfix/main.cf
# ========================================
# 基本設定
# ========================================
myhostname = mail.company.com
mydomain = company.com
myorigin = $mydomain
inet_interfaces = all
inet_protocols = ipv4

# ========================================
# 1. ローカル配送(サーバー管理用)
# ========================================
mydestination = $myhostname, localhost.$mydomain, localhost

# ========================================
# 2. 転送・エイリアス用ドメイン
# ========================================
virtual_alias_domains = 
    old-company.com,
    info-domain.jp,
    support-domain.net
    
virtual_alias_maps = hash:/etc/postfix/virtual

# ========================================
# 3. 仮想メールボックスドメイン(メイン)
# ========================================
virtual_mailbox_domains = 
    main-company.com,
    subsidiary-a.jp,
    subsidiary-b.jp
    
virtual_mailbox_base = /var/mail/vhosts
virtual_mailbox_maps = hash:/etc/postfix/vmailbox
virtual_uid_maps = static:5000
virtual_gid_maps = static:5000

# Dovecot連携
virtual_transport = lmtp:unix:private/dovecot-lmtp

# ========================================
# 4. 中継ドメイン(関連会社)
# ========================================
relay_domains = 
    partner-company.com,
    affiliated-org.jp
    
relay_recipient_maps = hash:/etc/postfix/relay_recipients
transport_maps = hash:/etc/postfix/transport

# ========================================
# セキュリティ設定
# ========================================
smtpd_recipient_restrictions =
    permit_mynetworks,
    permit_sasl_authenticated,
    reject_unauth_destination,
    reject_unknown_recipient_domain,
    reject_unverified_recipient

# SPF/DKIM/DMARC対応
smtpd_milters = inet:127.0.0.1:8891
non_smtpd_milters = $smtpd_milters
milter_default_action = accept

# レート制限
smtpd_client_connection_rate_limit = 10
smtpd_client_message_rate_limit = 30

設定ファイルの詳細例

# /etc/postfix/virtual(転送設定)
# ========================================
# 旧ドメインからの転送
@old-company.com           @main-company.com

# サポート窓口
support@info-domain.jp     ticket-system@main-company.com
info@info-domain.jp        sales@main-company.com, marketing@main-company.com

# 部署共有アドレス
helpdesk@support-domain.net    it-team@main-company.com
sales@support-domain.net       sales-all@main-company.com

# /etc/postfix/vmailbox(メールボックス設定)
# ========================================
# メインドメイン
admin@main-company.com         main-company.com/admin/
john.doe@main-company.com      main-company.com/john.doe/
jane.smith@main-company.com    main-company.com/jane.smith/

# 子会社A
president@subsidiary-a.jp      subsidiary-a.jp/president/
staff01@subsidiary-a.jp        subsidiary-a.jp/staff01/

# 子会社B  
manager@subsidiary-b.jp        subsidiary-b.jp/manager/
support@subsidiary-b.jp        subsidiary-b.jp/support/

# /etc/postfix/transport(中継設定)
# ========================================
partner-company.com     smtp:[mail.partner-company.com]:25
affiliated-org.jp       smtp:[192.168.100.50]:25

セキュリティと運用の推奨事項

1. 基本的なセキュリティ設定

# 不正中継の防止
smtpd_relay_restrictions =
    permit_mynetworks,
    permit_sasl_authenticated,
    defer_unauth_destination

# 送信者検証
smtpd_sender_restrictions =
    permit_mynetworks,
    reject_non_fqdn_sender,
    reject_unknown_sender_domain

# SASL認証の設定
smtpd_sasl_auth_enable = yes
smtpd_sasl_security_options = noanonymous
smtpd_sasl_local_domain = $myhostname

2. ドメイン設定のベストプラクティス

優先順位の考慮

  • 同一ドメインを複数の方式に設定しない
  • 設定前に優先順位を理解し、意図した動作を確認

最小権限の原則

  • mydestinationは最小限に留める
  • 不要なUNIXアカウントは作成しない
  • virtual_mailboxでは専用ユーザー(vmail)を使用

監査とログ

# 詳細なログ設定
maillog_file = /var/log/mail.log
debug_peer_level = 2
debug_peer_list = 127.0.0.1

# 定期的な監査コマンド
$ sudo postconf -n  # 設定確認
$ sudo postmap -q "test@domain.com" hash:/etc/postfix/virtual  # マップ確認

3. パフォーマンスチューニング

# 接続数の最適化
default_process_limit = 100
smtpd_client_connection_count_limit = 10
smtpd_client_connection_rate_limit = 30

# キューの管理
maximal_queue_lifetime = 5d
bounce_queue_lifetime = 5d
maximal_backoff_time = 4000s
minimal_backoff_time = 300s
queue_run_delay = 300s

4. バックアップとリカバリー

# 設定ファイルのバックアップ
$ sudo tar -czf /backup/postfix-config-$(date +%Y%m%d).tar.gz /etc/postfix/

# メールボックスのバックアップ
$ sudo rsync -av /var/mail/vhosts/ /backup/mailboxes/

# キューのバックアップ
$ sudo postsuper -h ALL  # キューをホールド
$ sudo tar -czf /backup/queue-$(date +%Y%m%d).tar.gz /var/spool/postfix/
$ sudo postsuper -H ALL  # ホールド解除

補足情報

トラブルシューティングのヒント

1. 配送先の確認方法
# アドレスがどの方式で処理されるか確認
$ postmap -q "user@domain.com" hash:/etc/postfix/virtual
$ postmap -q "user@domain.com" hash:/etc/postfix/vmailbox

# 配送経路のテスト
$ sendmail -bv user@domain.com
2. よくあるエラーと対処法

"Relay access denied"

  • relay_domainsまたは承認済みネットワークの設定確認
  • SASL認証の設定確認

"User unknown in virtual mailbox table"

  • vmailboxマップの更新忘れ(postmap実行)
  • ディレクトリの作成と権限設定の確認

"mail for domain.com loops back to myself"

  • mydestinationとvirtual_*_domainsの重複確認
  • DNSのMXレコード確認

Dovecotとの連携設定例

# /etc/dovecot/conf.d/10-auth.conf
auth_mechanisms = plain login
!include auth-sql.conf.ext

# /etc/dovecot/conf.d/10-mail.conf
mail_location = maildir:/var/mail/vhosts/%d/%n
mail_uid = vmail
mail_gid = vmail

# /etc/dovecot/conf.d/10-master.conf
service lmtp {
  unix_listener /var/spool/postfix/private/dovecot-lmtp {
    mode = 0600
    user = postfix
    group = postfix
  }
}

移行時の注意点

  1. 段階的な移行

    • まずvirtual_aliasで旧ドメインから転送
    • 動作確認後、virtual_mailboxへ移行
    • 最後に旧設定を削除
  2. DNSの考慮

    • TTLを事前に短縮
    • MXレコードの優先度を活用
    • SPF/DKIM/DMARCレコードの更新
  3. ユーザーへの通知
    • 移行スケジュールの事前通知
    • 新しい設定情報の配布
    • サポート窓口の準備

まとめ

Postfixの複数ドメイン運用は、4つの方式を適切に組み合わせることで、柔軟かつ安全なメールシステムを構築できます。各方式の特徴と優先順位を理解し、要件に応じて最適な設定を選択することが重要です。

特に重要なポイント:

  • mydestination:サーバー自身のメール処理に限定
  • virtual_alias_domains:転送やエイリアスが必要な場合
  • virtual_mailbox_domains:本格的なメールホスティング
  • relay_domains:中継やゲートウェイ機能

セキュリティを常に意識し、定期的な監査とメンテナンスを行うことで、安定した複数ドメイン運用が実現できます。

fstabとは

2025/11/16

Linuxにおけるfstabの役割

fstabとは

/etc/fstab(file systems table)は、Linuxシステムにおいてファイルシステムのマウント情報を定義する重要な設定ファイルです。システム起動時に自動的にマウントするファイルシステムや、その際のオプションを指定します。

主な役割

自動マウントの管理
  • システム起動時に必要なファイルシステムを自動的にマウント
  • ルートファイルシステム、swap領域、追加ストレージなどの設定を一元管理
マウントオプションの指定
  • 各ファイルシステムに対する詳細な動作設定
  • セキュリティ、パフォーマンス、互換性の調整
システム管理の簡素化
  • mountコマンドでデバイス名のみでマウント可能に
  • 一貫性のあるマウント設定を維持

fstabの書式

各行は6つのフィールドで構成されます:

<device> <mount point> <fs type> <options> <dump> <pass>

各フィールドの詳細

第1フィールド:デバイス

デバイスの指定方法には複数あります:

  • デバイスファイル:/dev/sda1
  • UUID:UUID=550e8400-e29b-41d4-a716-446655440000
  • ラベル:LABEL=ROOT
  • ネットワークファイルシステム:server:/export/home

UUIDを使用する利点は、デバイス名が変更されても影響を受けないことです。

第2フィールド:マウントポイント

ファイルシステムをマウントするディレクトリパスを指定します。swapの場合はnoneを指定。

第3フィールド:ファイルシステムタイプ
  • ext4:Linux標準ファイルシステム
  • xfs:高性能ファイルシステム
  • btrfs:次世代ファイルシステム
  • vfat:FAT32(USBメモリなど)
  • ntfs:Windows NTFS
  • nfs:ネットワークファイルシステム
  • swap:スワップ領域
  • auto:自動検出
第4フィールド:マウントオプション

カンマ区切りで複数指定可能:

基本オプション
  • defaults:標準オプション(rw,suid,dev,exec,auto,nouser,async)
  • ro/rw:読み取り専用/読み書き可能
  • noauto:起動時に自動マウントしない
  • user/nouser:一般ユーザのマウント許可/禁止
セキュリティ関連
  • nosuid:SUIDビットを無効化
  • nodev:デバイスファイルを無効化
  • noexec:実行ファイルの実行を禁止
パフォーマンス関連
  • async/sync:非同期/同期I/O
  • noatime:アクセス時刻を更新しない(パフォーマンス向上)
  • nodiratime:ディレクトリのアクセス時刻を更新しない
  • relatime:アクセス時刻の更新を制限
第5フィールド:dump
  • 0:バックアップ不要
  • 1:dumpコマンドでバックアップ対象
第6フィールド:pass(fsckの順序)
  • 0:チェックしない
  • 1:ルートファイルシステム(最優先)
  • 2:その他のファイルシステム

設定例

典型的なfstabの例:

# <device>                                <mount point>  <type>  <options>           <dump> <pass>
UUID=8f2d4c6a-9b1e-4d8a-b3c5-1a2b3c4d5e6f /              ext4    defaults            1      1
UUID=a1b2c3d4-e5f6-7890-abcd-ef1234567890 /boot          ext4    defaults            1      2
UUID=12345678-90ab-cdef-1234-567890abcdef swap           swap    defaults            0      0
UUID=fedcba98-7654-3210-fedc-ba9876543210 /home          ext4    defaults,noatime    1      2

# 外部ストレージ
/dev/sdb1                                 /mnt/backup    ext4    noauto,user         0      0

# ネットワークドライブ
192.168.1.100:/share                      /mnt/nfs       nfs     defaults,_netdev    0      0

# Windows共有
//192.168.1.101/share                     /mnt/smb       cifs    credentials=/home/user/.smbcreds,uid=1000,gid=1000,iocharset=utf8 0 0

# tmpfs(メモリ上のファイルシステム)
tmpfs                                      /tmp           tmpfs   defaults,noatime,mode=1777,size=2G 0 0

実用的な設定のポイント

UUIDの確認方法
blkid
# または
lsblk -f
fstab編集時の注意点
  1. 編集前にバックアップを作成
  2. 編集後はmount -aで構文エラーをチェック
  3. ルートファイルシステムの設定は特に慎重に
トラブルシューティング
  • 起動時にエラーが発生した場合、シングルユーザーモードまたはレスキューモードで修正
  • systemctl statusでマウント失敗の詳細を確認
  • _netdevオプションでネットワークドライブの起動順序を制御
セキュリティ考慮事項
  • 外部メディアにはnosuid,nodev,noexecを設定
  • 機密データを含むパーティションには適切な権限設定
  • NFSやCIFSの認証情報は別ファイルで管理

まとめ

fstabは、Linuxシステムの起動と運用において中核的な役割を果たす設定ファイルです.