L2NACの偽装ARP問題を、L3SWの隠しコマンドで解決した話

Network

L2NACの偽装ARP問題を、L3SWの隠しコマンドで解決した話

はじめに

社内ネットワークに不正な端末が接続されないようにするための装置として、L2 NAC（Network Access Control）装置と呼ばれるカテゴリの製品があります。国内シェアの高いL2Blockerをはじめ、いくつかの製品が「偽装ARP方式」と呼ばれる方式で不正端末を遮断します。

この偽装ARP方式は、スイッチ側の機能に依存せずに導入できるという大きなメリットがある一方で、特定のL3スイッチと組み合わせると、ネットワーク全体に断続的な通信障害を引き起こすことがあります。

今回、ある検証環境でこのトラブルに遭遇し、最終的にスイッチベンダーから提示された「隠しコマンド」で解決に至った経緯を、技術解説としてまとめておきます。同じ症状で困っている方の助けになれば幸いです。

結論

先に解決策を書いておきます。

事象：偽装ARP方式のL2 NAC装置を「保留モード（ブロックモード）」で接続したら、同一VLAN内で2〜3分に1回、数秒間の通信切断が発生する。L3スイッチ側ではDuplicate
Address Detection（重複IPアドレス検知）のログが多発。

解決策：Juniper EXシリーズのL3スイッチであれば、以下の隠しコマンドで解消します。

set switch-options no-arp-trap
commit

このコマンドは公式ドキュメントには記載がなく、ベンダーのテクニカルサポート経由で初めて提示されたものです。詳細は記事後半で解説します。

L2 NACの偽装ARP方式とは

まず、偽装ARP方式のL2
NAC装置がどう動作しているのかを整理しておきます。

L2
NAC装置は、ネットワーク内に「センサー」と呼ばれる監視端末を1台置くだけで、同一セグメント内の全端末のMACアドレスを監視できます。未登録の端末を検知すると、その端末に対して偽装ARPパケットを送りつけて通信を妨害します。

具体的には、不正端末から見て、

  • 「自分が通信したいゲートウェイ（192.0.2.254）のMACアドレスは、NACセンサーのMACアドレス（00:06:A5:XX:XX:XX）ですよ」

という嘘のARP応答を、NACセンサーが代わりに返します。不正端末はそれを信じて、ゲートウェイ宛のパケットをNACセンサーに送るため、結果として外部に通信が出ていかなくなる──というのが偽装ARP方式の仕組みです。

この方式の最大のメリットは、スイッチ側に802.1Xや認証機能を持たせる必要がないことです。アンマネージドスイッチしか無い環境でも、センサーを1台繋ぐだけで未登録端末を遮断できます。

発生した事象

問題は、この偽装ARPを「他の機器が誤って受け取ってしまう」ときに起こります。

ネットワーク機器のリプレイス後、L2 NAC装置のセンサーを保留モード（ブロックモード）で接続したところ、以下のような事象が発生しました。

  • VLAN内の全端末で断続的な通信切断（2〜3分に一度、数秒間）
  • ネットワーク側でDNS問い合わせが異常に増加
  • L3スイッチ上で「Duplicate Address Detection」のログが多数記録
  • センサーを「MACアドレス収集モード」（偽装ARPを送らないモード）にすると症状が消える

ピンとくる方もいるかもしれませんが、本来1台の不正端末だけに影響するはずの偽装ARPが、なぜかネットワーク全体を不安定にしているわけです。

L3SW側で何が起きているのか

原因は、L3スイッチが偽装ARPを「真に受けてしまっている」ことでした。

L2 NAC装置のセンサーは、不正端末を遮断する際、

  • Source IP：ゲートウェイのIPアドレス（192.0.2.254）
  • Source MAC：センサー自身のMACアドレス（00:06:A5から始まる）

という偽装ARPを送出します。これがL3スイッチに届くと、L3スイッチは「自分のIPアドレス（192.0.2.254）が、自分以外のMACアドレスから名乗られている」と認識し、IPアドレス重複（Duplicate Address）として検知してしまいます。

L3スイッチは通常、IRBインターフェース（VLANに紐づくL3インターフェース）でARPテーブルを管理しています。偽装ARPを受信するたびにARPテーブルが書き換わったり、Duplicate検知でインターフェースの動作に影響が出たりすることで、結果的にゲートウェイへの通信が一時的に遮断される、という連鎖反応が起きていました。

これがDNS問い合わせ多発（名前解決リトライの嵐）として観測されていた、というわけです。

試したけれどうまくいかなかった対策

切り分けの過程で、以下のような対策を試しましたが、いずれも完全な解消には至りませんでした。

1. 偽装ARP送信間隔の延長

L2 NAC装置側では、偽装ARPの送信間隔をデフォルト2秒から最大180秒まで延長できます。80秒程度に延ばしたところ通信は大きく改善しましたが、Duplicate検知のログは引き続き1分間隔で出続け、根本解決には至りませんでした。

2. Static ARP/MACの設定

L3スイッチ側でゲートウェイの正しいMACアドレスを静的に登録する案も検討しました。Juniper
EXシリーズの場合、「L3スイッチが自分自身のIPに対してStatic ARPを設定する」ことは仕様上できないため、Static
MACで代替を試しましたが、Duplicate検知は止まりませんでした。

3. センサー管理IPの変更

タグVLAN版センサーの管理IPに、実在しないネットワークのIPアドレスを設定するという対処も試しました。これも症状改善にはつながらず。

4. ネットワーク構成の変更

L3スイッチを偽装ARPが経由しない構成にする、という案も出ましたが、フロア跨ぎのセグメント設計の都合上、物理的に実現困難でした。

このあたりで「これは偽装ARP方式そのものとL3スイッチの実装の問題で、運用設定だけでは抜本対処できない」ということが見えてきました。

他ベンダーの公開事例

ここで興味深い情報を一つ。

実は、同種の事象は他ベンダーの製品でも過去に発生しており、ファームウェア改修で解決した事例があります。

ある無線APベンダーのリリースノートには、こんな記述があります（公開情報からの引用）。

AP may change the gateway’s MAC address when it receives a spoofed
unicast ARP request

「APが偽装されたユニキャストARPリクエストを受信すると、ゲートウェイのMACアドレスを書き換えてしまうことがある」という不具合で、ファームウェアアップデートにより修正されています。

つまり、

  • L2 NAC装置の偽装ARPによってGW MACが書き換わる問題は、業界横断的に存在する
  • ベンダーの実装次第で、これに反応してしまう機器と反応しない機器がある

ということです。今回のJuniper EXシリーズも、同じパターンの問題に該当していたと考えられます。

解決策の核心：隠しコマンド set switch-options no-arp-trap

ベンダーサポートにエスカレーションを続けたところ、最終的に次のコマンドの適用を提案されました。

set switch-options no-arp-trap
commit

このコマンドを投入したところ、Duplicate検知は完全に止まり、ネットワークの断続切断も解消しました。

このコマンドは何をしているのか

switch-options 階層は、Junos OSにおいてスイッチ全体の動作を制御する設定階層です。no-arp-trap
は名前のとおり、受信したARPパケットをCPUにトラップして処理する動作を抑止する設定と推定されます。

通常、Junipersスイッチは受信したARPパケットの一部（自分宛、Duplicate検知用、ARP学習用など）をCPUに上げて処理します。L2 NAC装置の偽装ARPがこのトラップ処理に拾われ、ARPテーブル書き換えやDuplicate検知を引き起こしていたため、トラップ自体を抑止することで根本回避を実現した、という構造です。

なお、このコマンドは**Junos
OSの公式ドキュメントには記載されていない、いわゆる「隠しコマンド（hidden command）」**に分類されます。CLI上でTAB補完しても出てきません。?
を打ってもヘルプに表示されません。ベンダーのテクニカルサポートやJTACが、特定の事象に対応するために内部的に使用するコマンドです。

このコマンドの注意点

事象は解決したものの、隠しコマンドを使う以上、いくつか留意すべき点があります。

1. 公式サポート保証の範囲が不明瞭

ドキュメントに無いコマンドであるため、将来のJunos OSバージョンアップで予告なく削除・変更される可能性があります。実際、Junos OSには「以前は使えたが、特定バージョン以降で削除された隠しコマンド」が複数存在します。

2. 副作用の可能性

ARPトラップを抑止する以上、Junos
OSが本来行うはずだったARP関連の機能の一部が無効化されている可能性があります。具体的には、

  • 正規のIPアドレス重複検知（DAD）が動作しなくなる可能性
  • ARP学習挙動の変化
  • GARPによるMAC移動検知が機能しない可能性

つまり、L2 NAC装置の偽装ARPは無視されるようになりますが、正規のARP問題（本物のIP重複など）もスイッチ側で検知されなくなる可能性があります。トレードオフの理解が必要です。

3. バージョンアップ時の確認必須

Junos OSをアップグレードする際は、必ず事前に以下をベンダーサポートに確認すべきです。

  • 該当バージョンで本コマンドが動作継続するか
  • 仕様に変更がないか
  • 削除予定がないか

4. 設定意図のドキュメント化

隠しコマンドは公開情報が乏しいため、社内ドキュメントに「なぜこの設定を入れているか」「どのケース番号・サポート回答に基づくか」を必ず記録しておくことを強く推奨します。後任のネットワーク管理者が設定意図を読み解けず、安易に削除してしまうリスクを避けるためです。

まとめ

今回の事例から得られた教訓を整理します。

  • 偽装ARP方式のL2 NAC装置は、スイッチ側の実装によって相性問題が起きる
  • 切り分けの過程で「他ベンダーで同種の事例がファームウェア改修で解決されている」という公開情報は強力なヒントになる
  • ベンダーサポートには、公式ドキュメントに無い「隠しコマンド」での解決策が存在することがある
  • 隠しコマンドを採用する場合は、バージョンアップ時のリスクと副作用を理解した上で、ドキュメント化を徹底する

NACの方式論としては、業界全体の流れは「偽装ARP方式」から「802.1X認証ベース」「ゼロトラスト型」へ移行しつつあります。とはいえ、既存の偽装ARP方式の製品を運用している組織は依然として多く、すぐに刷新できない事情を抱えているケースも珍しくありません。そうした環境で本記事の事例が役立てば幸いです。

同じ症状で困っている方がいらっしゃれば、まずは
set switch-options no-arp-trap
をベンダーサポート経由で照会してみる、というのが現時点で最短の解決策だと思います。

タイトルとURLをコピーしました