ある月曜日の朝のことだった。sysadminチームから報告が届いた：3台の社員の個人用ノートPCが3階のスイッチを通じて社内VLANに接続されており、誰も気づいていなかったというのだ。当時のネットワークはVLANによるセグメント分離のみを行っており、接続するデバイスが信頼できるものかどうかを確認する仕組みが何もなかった。
私は50人規模のオフィスと小規模なデータセンターのネットワークを管理している。この問題がきっかけでNetwork Access Controlについて調べるようになり、いくつかのソリューションを比較検討した末に、PacketFenceを選ぶことにした。
NACとは何か、そしてなぜあなたのネットワークに必要なのか
シンプルに考えてみよう：社内ネットワークはオフィスビルのようなものだ。今の状態はドアが開けっぱなし——ケーブルを差し込めば誰でも入れる。NAC（Network Access Control）とは入退室管理システムのようなもので、デバイスは社内リソースにアクセスする前に「身分証明書を提示」しなければならない。
PacketFenceは2006年に誕生し、現在バージョン13.x——その機能一覧はほぼあらゆる実際のシナリオに対応できるほど充実している：
- 802.1X認証 — スイッチがアクセス権を付与する前にRADIUSでデバイス認証を行う
- キャプティブポータル — ゲストWi-FiやBYOD向けのWebログインページ
- MACベースの検出 — MACアドレスによるデバイスの識別と分類
- VLAN隔離 — 未知のデバイスを自動的に隔離VLANへ移動
- コンプライアンスチェック — アクセス権付与前にNessus/OpenVASでデバイスを検査
私が最も必要としていたのはこれだ：誰かが個人のノートPCをスイッチに接続したり、オフィスのWi-Fiに繋げたりした際に、システムが未登録デバイスを自動的に検出し、専用のVLANに隔離する——社内サーバーには一切アクセスできない状態にする機能だ。
Ubuntu 22.04へのPacketFenceのインストール
PacketFenceは専用サーバーが必要で、他のサービスとの共存はできない。最低要件：CPU 4コア、RAM 8GB、ネットワークインターフェース2枚（1枚は管理用、1枚はスイッチ/APへの接続用）。
ステップ1：リポジトリの追加とインストール
# PacketFenceリポジトリを追加
wget https://inverse.ca/downloads/PacketFence/ubuntu/PacketFence.list \
-O /etc/apt/sources.list.d/PacketFence.list
# GPGキーを追加
wget -O - https://inverse.ca/downloads/PacketFence/ubuntu/key.gpg | apt-key add -
# 更新とインストール
apt-get update
apt-get install packetfence -yステップ2：Webコンフィグレーターの起動
# コンフィグレーターサービスを有効化
systemctl start packetfence-config
systemctl enable packetfence-config
# ステータスを確認
systemctl status packetfence-configサービスが起動したら、ブラウザで https://<IP-server>:1443 を開く。ウィザードは非常に使いやすく、ネットワークトポロジーについて順番に質問しながら対応する設定を自動生成してくれる。初回セットアップには約15〜20分かかる。
ステップ3：ネットワークインターフェースの定義
PacketFenceはどのインターフェースでトラフィックを「リッスン」するかを知る必要がある。/usr/local/pf/conf/pf.conf の基本設定：
[interface eth1]
ip=192.168.10.1
mask=255.255.255.0
type=management
[interface eth2]
ip=10.0.0.1
mask=255.255.255.0
type=internal実際のところ、この部分の設定にはWebUIを使うことが多い——入力が即座にバリデーションされるため、ミスが少なくて済む。
RADIUSの設定と802.1Xの統合
FreeRADIUSはPacketFenceに同梱されているため、追加インストールは不要だ。次のステップは、スイッチが認証リクエストを正しいRADIUSサーバーのアドレスに送信するよう設定することだ。
PacketFenceへのスイッチの登録
Admin UIから Configuration → Network Devices → Switches に移動し、各スイッチを以下のパラメータで追加する：
- IP：スイッチのIPアドレス
- Type：ベンダーを正確に選択（Cisco、HP、Dell、Aruba…）
- RADIUS Secret：スイッチとRADIUSサーバー間の共有パスワード
- Roles：ロールをVLANにマッピング（登録VLAN、隔離VLAN、本番VLAN）
Ciscoスイッチ側の設定
! RADIUSサーバーを定義
radius server PACKETFENCE
address ipv4 192.168.10.1 auth-port 1812 acct-port 1813
key MySecretKey123
! 802.1Xをグローバルに有効化
aaa new-model
aaa authentication dot1x default group radius
aaa authorization network default group radius
dot1x system-auth-control
! ユーザーポートに適用
interface GigabitEthernet1/0/5
switchport mode access
authentication port-control auto
dot1x pae authenticator
spanning-tree portfastユーザー認証のためのActive Directory統合
AD統合はオフィス環境ではほぼ必須だ——社員はWindowsアカウントで認証でき、NAC専用の別アカウントを作成する必要がない。Configuration → Policies and Access Control → Authentication Sources に移動し、Add → Active Directoryを選択する。
設定前に、PacketFenceサーバーからLDAP接続をテストしておこう：
ldapsearch -H ldap://192.168.1.10 \
-D "CN=pf-bind,OU=ServiceAccounts,DC=company,DC=local" \
-w "BindPassword" \
-b "DC=company,DC=local" \
"(sAMAccountName=testuser)"私はAD内に読み取り専用権限のみを持つ専用サービスアカウントを作成した——この用途にドメイン管理者アカウントは絶対に使ってはいけない。
デバイスグループごとのセキュリティポリシーの定義
これがVLANのみの運用に対するPacketFenceの強みだ：デバイスの種類やユーザーグループごとにポリシーを定義できる。
接続プロファイル
Configuration → Policies and Access Control → Connection Profiles を開く。オフィスの実態に合わせて3つのプロファイルを作成した：
- Corporate-Wired：会社支給ノートPC、ADを通じた802.1X認証 → 本番VLAN
- BYOD-WiFi：社員の個人デバイス、キャプティブポータルで登録 → BYOD VLAN（インターネットのみ）
- Guest-WiFi：来訪者、シンプルなキャプティブポータル → ゲストVLAN（インターネットのみ、ダウンロード10 Mbps制限）
802.1Xに非対応のデバイスへの対応
プリンター、IPカメラ、スマートTV——これらのデバイスは802.1X認証を行えない。対処法：MACアドレスのホワイトリスト登録か、専用のVLANへの配置だ。
私は「IoT」というVLANと対応するConnection Profileを作成し、IoTデバイスが接続するスイッチポートに適用した。シンプルだが効果的だ。
動作確認とモニタリング
接続中のデバイス一覧の確認
私はAdmin UIの Nodes タブをブックマークしている——毎朝最初に開くのがここで、登録済み・オンライン・隔離中のすべてのデバイスを一覧で確認できる。
# レポートが必要な場合にデータベースを直接クエリ
mysql -u pf -p pf -e "
SELECT mac, computername, status, last_seen, role
FROM node
WHERE status = 'reg'
ORDER BY last_seen DESC
LIMIT 20;"RADIUS認証ログの監視
# 認証ログをリアルタイムで確認
tail -f /usr/local/pf/logs/radius.log
# 特定のMACアドレスでフィルタリング
grep "aa:bb:cc:dd:ee:ff" /usr/local/pf/logs/radius.log | tail -50
# 最近の認証失敗を確認
grep "Access-Reject" /usr/local/pf/logs/radius.log | tail -20VLANアサインのデバッグ
「ケーブルを挿してもネットワークに繋がらない」という報告が来た際に私がよく使うデバッグ手順：
# RADIUSを直接テスト
radtest testuser TestPassword 127.0.0.1 1812 testing123
# システム全体の確認
pfcmd checkup
# ノードの現在の状態とVLANを確認
pfcmd node view aa:bb:cc:dd:ee:ff
# 必要に応じてRADIUSを再起動
systemctl restart packetfence-radiusd-auth未知のデバイス検出時のアラート設定
アラートは見落とされがちな機能だが、非常に価値がある。Configuration → Integration → Alerts に移動し、業務時間外に新しいデバイスが登録されるたびにメールを送信するよう設定した——実際に、夜9〜10時頃に社員が個人デバイスを接続していたことを何度か検知した。
# メールアラートを手動でテスト送信
pfcmd emailreport type=node action=new6ヶ月の運用から学んだこと
段階的にロールアウトし、最初からEnforcementを有効にしない： まずdetection-onlyモードで開始する——PacketFenceにデバイスを記録させるが、誰もブロックしない。1〜2週間後には、Enforcementを有効にする前にホワイトリスト登録すべき正当なデバイスの完全なリストが得られる。このステップを省くと、初日に何十件ものサポートチケットを受け取ることになるだろう。
MACスプーフィングという既知の弱点： MACアドレスベースのNACは鉄壁ではない——攻撃者は正当なデバイスのMACをクローンできる。証明書ベース認証（EAP-TLS）を使用した802.1Xこそが真に信頼できる方法だが、内部PKIが必要で展開の複雑さが大幅に増す。私の場合、IoT用のMAC検出とノートPC用の802.1Xの組み合わせで、現在の規模では十分に安心して運用できている。
すべてをドキュメント化する： 新しいデバイスをホワイトリストに追加するたびに、メモを残す：何のデバイスか、誰のものか、ホワイトリスト登録の理由。6ヶ月後に振り返ると、そのリストは手動で作っていたどのスプレッドシートのインベントリよりも正確だった。
PacketFenceは簡単なソリューションではない——初期セットアップには1〜2日の作業が必要だ。しかしその後は、ネットワークに接続しているすべてのデバイスを明確に把握できる。それは通常のスイッチやファイアウォールでは決して得られない視点だ。
