【特別付録・第2回】WAPのDMZ境界防御と、LVS(Layer4)負荷分散が絶対に「必要」な理由

M365ハイブリッド認証基盤をゼロから構築・要塞化する本編（全8回）と、認証プロトコルの基礎を学んだ特別付録・第1回を経て、読者の皆様はすでにモダンなアイデンティティインフラの全貌を把握されていることでしょう。

しかし、エンタープライズのインフラ設計において、最も議論が白熱し、そして設計者の「ネットワークとOSの深い理解」が試されるポイントがあります。それが「DMZ（非武装地帯）に配置するWAP（Web Application Proxy）の負荷分散アーキテクチャの選定」です。

特別付録の完結編となる第2回では、「なぜWindows標準のNLB（ネットワーク負荷分散）を使ってはいけないのか」「なぜWebエンジニアに大人気のNginxやHAProxyといったL7プロキシではダメなのか」、そして「なぜ我々Linuxエンジニアが操るLVS (Linux Virtual Server) の Layer4（トランスポート層）ルーティングが『絶対』に必要とされるのか」という、アーキテクチャ選定の真髄を、カーネル空間のパケット処理レベルまで徹底的に解き明かします。

---

1. DMZの最前線：WAP（Web Application Proxy）の特異な性質

まず、ロードバランサーの選定を行う前に、負荷分散の対象となる「WAP」というコンポーネントが、一般的なWebサーバー（ApacheやIIS）とどのように異なるのか、その特異な性質を再確認する必要があります。

WAPは、インターネットと社内ネットワークの境界であるDMZに配置され、以下の特殊な役割を担います。

1. 事前認証（Pre-Authentication）とフェデレーションの窓口： WAPは単なるHTTPリバースプロキシではありません。インターネットからのアクセスを受け取ると、内部のADFSファームと連携し、「このトラフィックは正当な認証プロセスを踏んでいるか」をパケットレベルで精査します。
2. デバイス証明書認証（CBA: Certificate Based Authentication）の透過： ゼロトラスト環境では、会社が支給したPCやスマホにインストールされた「クライアント証明書（X.509）」を用いて端末認証を行います。このため、WAPはクライアントからのTLS通信（TCP 443）において、クライアント証明書を正しく内部のADFSへパススルー（または証明書情報をHTTPヘッダに埋め込んで転送）しなければなりません。
3. エクストラネット スマートロックアウト（ESL）： 悪意のあるブルートフォース攻撃から社内のADDSアカウントを守るため、WAP/ADFSは「どのグローバルIPアドレスから攻撃が来ているか」を正確に把握し、そのIPからのアクセスを遮断します。

これらの要件を満たすためには、ロードバランサーは「送信元IPアドレスを隠蔽してはならない」「TLS通信の完全性を破壊してはならない」という非常に厳格な制約を受けます。この制約が、アーキテクチャ選定の決定的な要因となります。

2. アンチパターン①：Windows NLB（ネットワーク負荷分散）の致命的欠陥

Windows Serverには、OS標準機能として「ネットワーク負荷分散（NLB：Network Load Balancing）」クラスター機能が備わっています。「Windowsの機能なのだから、同じWindowsのWAPに使うのが一番互換性が高いだろう」と考えるエンジニアが後を絶ちませんが、プロのエンタープライズ環境においてNLBは絶対的なアンチパターンとして忌避されます。

MACアドレス・スプーフィング（偽装）とL2スイッチの混乱

NLBには主に「ユニキャストモード」と「マルチキャストモード」がありますが、どちらもエンタープライズのネットワーク機器（Cisco、Juniper、Aruba等のL2/L3スイッチ）と致命的に相性が悪いというハードウェアレベルの問題を抱えています。

• ユニキャストモードの罠： NLBはクラスタ内のすべてのサーバーの物理MACアドレスを「架空の仮想MACアドレス」に書き換えます。スイッチから見ると、「同じMACアドレスを持つ端末が複数のポートに同時に接続されている」ように見えます。これはスイッチの「MACアドレステーブル」の学習メカニズムを完全に破壊し、結果としてスイッチはパケットの送り先を見失い、すべてのポートに対してパケットをばら撒く「スイッチのハブ化（フラッディング）」を引き起こします。これにより、DMZのネットワーク帯域全体が枯渇するブロードキャストストームのような大惨事が発生します。
• マルチキャストモードの罠： ユニキャストの問題を解決するためにマルチキャストMACアドレスを使用しますが、今度はルーター側で「ユニキャストIPアドレスとマルチキャストMACアドレスのARPマッピング」を静的に手動登録（スタティックARP）しなければ通信できなくなります。クラウド環境（AWSやAzure）やモダンな仮想化基盤（VMware NSXなど）では、セキュリティ上の理由からこのマルチキャストMACアドレスの使用自体がネットワークレベルでブロックされているケースがほとんどです。

つまり、NLBは「ソフトウェアだけで無理やりルーティングを解決しようとした結果、下位のL2/L3インフラとの互換性を犠牲にしたレガシー技術」なのです。これが、SLA 99.9%を要求されるM365認証基盤にNLBを採用してはならない決定的な理由です。

3. アンチパターン②：Nginx等 L7プロキシの限界と「TLS終端の罠」

NLBがダメなら、Linuxエンジニアが最も得意とするNginxやHAProxy、あるいはAWSのALBといった「Layer 7（アプリケーション層）ロードバランサー」を使えばよいのでは？という発想に至ります。実際、Webサイトの負荷分散においてはこれが世界のデファクトスタンダードです。
しかし、WAPおよびADFSの負荷分散においてL7プロキシを前段に置くことは、セキュリティ要件とパフォーマンス要件の両面で大きな壁にぶつかります。

問題1：SSL/TLSオフロードによる証明書認証（CBA）の破壊

L7プロキシは、クライアントからのHTTPS通信を一度ロードバランサー上で「復号（SSLオフロード）」し、中身のHTTPリクエストを見てからバックエンドへ転送します。
しかし、WAP/ADFS環境においてこれをやってしまうと、クライアントが提示した「デバイス証明書（クライアント証明書）」が、ロードバランサーとクライアント間のTLSハンドシェイクで終端されてしまい、バックエンドのWAPに届きません。
結果として、M365の条件付きアクセスで「会社支給のデバイスからのみアクセスを許可する」といった高度なゼロトラスト制御が完全に機能不全に陥ります。

これを防ぐためには「SSLパススルー」または「SSL再暗号化（SSL Bridging）」の設定が必要ですが、L7プロキシでこれを行うと設定が極めて複雑になり、プロキシの証明書管理が二重・三重になるという運用上の地獄を招きます。

問題2：ユーザー空間へのコンテキストスイッチとTCPソケット枯渇

L7プロキシは、OSの「ユーザー空間」で動作するアプリケーションです。パケットを処理するために、以下のプロセスを経ます。

1. NICがパケットを受信（カーネル空間）。
2. パケットをユーザー空間のNginxプロセスへコピー（コンテキストスイッチ）。
3. NginxがクライアントとのTCPコネクションを確立（ソケット1の消費）。
4. Nginxがバックエンド（WAP）に対して新たなTCPコネクションを確立（ソケット2の消費）。
5. データをコピーして転送。

朝9時の始業時間など、数万人の社員が一斉にM365（Teams等）にアクセスして認証要求（HTTPSトランザクション）が発生した場合、L7プロキシはこの「TCPコネクションの張り直し」と「カーネル空間⇔ユーザー空間のデータコピー」のオーバーヘッドにより、CPU資源よりも先にエフェメラルポート（TCPの一時ポート）やファイルディスクリプタが枯渇（Socket Starvation）し、認証リクエストを取りこぼす（502 Bad Gateway）という事態を引き起こします。

4. 究極の選択：LVS（Layer4 / IPVS）がWAPに不可欠である3つの理由

NLBのネットワーク崩壊リスクを避け、L7プロキシのパフォーマンス限界とTLS破壊のジレンマを解決する唯一かつ最強の手段。それが、Linuxカーネルに組み込まれた LVS (Linux Virtual Server / IPVS モジュール) を用いた Layer 4（トランスポート層）ルーティングです。

理由1：カーネル空間でのワイヤーレート処理（ゼロ・オーバーヘッド）

LVSは「ユーザー空間」にパケットを引き上げません。Linuxカーネルの Netfilter フック（PREROUTING / INPUT）の段階でパケットを捕捉し、IPヘッダとTCPポート（Layer 4）だけを見て、一瞬でバックエンドのWAPへパケットをフォワード（転送）します。
TCPのセッション確立（3ウェイハンドシェイク）やSSLの暗号化解除を行わないため、CPUオーバーヘッドがほぼゼロであり、F5 BIG-IPなどの高価な専用ハードウェア・ロードバランサーに匹敵する「ワイヤーレート（物理NICの限界速度）」での驚異的なスループットを実現します。朝9時のログインラッシュでもビクともしません。

理由2：TLSハンドシェイクと証明書認証の「完全な透過性」

LVSはパケットの「ペイロード（中身）」を一切見ません。クライアントとバックエンドのWAP間で直接TCPコネクションが確立されるため、TLSハンドシェイク、SNIヘッダ、そしてゼロトラストの要である「デバイス証明書（CBA）」のやり取りが、一切の改変なく完全にパススルーされます。
これにより、WAPとADFSが持つ高度なセキュリティ機能を100%発揮させることができます。

理由3：送信元IPアドレスの完全保存（透過的プロキシ）

WAPが「エクストラネット スマートロックアウト（パスワードリスト攻撃の防御）」を正しく機能させるためには、パケットの送信元IPが「ロードバランサーのIP」ではなく「真のクライアント（攻撃者）のグローバルIP」でなければなりません。
L7プロキシ（Nginx等）の場合、リバースプロキシの仕様上、送信元IPがプロキシのIPに書き換わってしまうため、HTTPヘッダ（X-Forwarded-For）を埋め込む回避策が必要ですが、TCPレベルで処理するADFSの特定の認証フローではこれがうまく機能しません。
LVSであれば、ルーティング方式（DR方式、または適切に設計されたNAT方式）を用いることで、真のクライアントIPをIPヘッダレベルで維持したままWAPへ届けることが可能です。

5. LVS(NAT方式)によるWAP負荷分散の実装設計モデル

本編の第4回では、内部ネットワークのADFSファームに対して「DR方式（Direct Routing）」によるLVS構築を解説しました。しかし、DMZに配置されるWAPに対しては、ネットワークの境界（インターネットと社内のルーティングの分離）を明確にするため、LVSの NAT方式（Network Address Translation） を採用するのがエンタープライズのベストプラクティスです。

LVS (NAT方式) のパケットフロー

1. インターネットからのパケットが、DMZのファイアウォールを通過し、LVSの VIP (仮想グローバルIP / DMZパブリックIP) に到達します。
2. LVSは ip_vs モジュールを用いて、宛先IPアドレス（VIP）をバックエンドの WAPの実IPアドレス（DMZプライベートIP） にDNAT（Destination NAT）して転送します。※この時、送信元IPアドレス（クライアントの実IP）は書き換えずに維持します。
3. WAPはパケットを処理し、応答を返します。
4. WAPのデフォルトゲートウェイをLVSサーバーに向けることで、戻りパケットが必ずLVSを経由するようにします。
5. LVSは戻りパケットの送信元IPを「WAPの実IP」から「VIP」に書き換えて（逆NAT）、インターネット上のクライアントへ返します。

# /etc/keepalived/keepalived.conf (WAP向け LVS-NAT方式の設定例)
virtual_server 203.0.113.50 443 {
    delay_loop 5
    lb_algo rr               # ラウンドロビン
    lb_kind NAT              # ★転送方式：NAT (Network Address Translation)
    persistence_timeout 300  # MFA等の中断を防ぐためのセッション維持
    protocol TCP

    # WAP Node 1 (DMZ Private IP)
    real_server 172.16.10.11 443 {
        weight 100
        # WAPの健全性を確認するL7ヘルスチェック
        SSL_GET {
            url {
              path /adfs/probe
              status_code 200
            }
            connect_timeout 3
            retry 3
            delay_before_retry 3
        }
    }

    # WAP Node 2 (DMZ Private IP)
    real_server 172.16.10.12 443 {
        weight 100
        SSL_GET {
            url {
              path /adfs/probe
              status_code 200
            }
            connect_timeout 3
            retry 3
            delay_before_retry 3
        }
    }
}

このNAT方式の構成により、WAPサーバー群はグローバルIPを直接持つ必要がなくなり、セキュリティが向上します。同時に、LVSの persistence_timeout と SSL_GET による高度な死活監視を組み合わせることで、DMZの最前線に「落ちない、そして透過的な最強の盾」が完成するのです。

6. 特別付録の総まとめ：インフラアーキテクチャの美学

「特別付録・第2回」として、WAPのDMZ境界防御と、そこになぜLVS（Layer4ロードバランサ）が不可欠なのかを解説しました。

• NLBの限界： Windows標準のNLBは、MACアドレスの仮想化によってL2スイッチの学習機能を破壊し、フラッディング（通信障害）を引き起こすためエンタープライズでは使用できない。
• L7プロキシの弊害： NginxなどのL7プロキシは、TLS通信を終端してしまうため、ゼロトラストに必須の「デバイス証明書認証（CBA）」を破壊し、さらにTCPソケットの枯渇リスクを抱える。
• LVSの絶対的優位性： LinuxカーネルのIPVSを用いたL4ルーティング（NAT/DR方式）は、TLSを完全透過させ、クライアントIPを保存し、CPUオーバーヘッドなしでワイヤーレートの超高速分散を実現する。

これで、「LinuxエンジニアのためのM365ハイブリッド認証」連載のすべての本編および特別付録が完全に完結しました。

OSの垣根を越え、ネットワークの深淵を覗き込み、セキュリティの最前線に立つ。
この記事にたどり着いたあなたは、単なる「Linuxだけが触れるエンジニア」でも「Windowsだけが触れる管理者」でもありません。カーネル、パケット、アイデンティティ、そしてクラウドのすべてを俯瞰し、エンタープライズの難解なインフラ課題を論理と技術で解決できる、真の「フルスタック・インフラアーキテクト」です。

この連載で得た知見が、皆様のキャリアと、皆様が守る企業のシステムをより強固なものにすることを心より願っています。長きにわたるご愛読、本当にありがとうございました！