一般企業であまり前例がない「認証VLAN」を導入した、その後の学び

こんにちは。サービスインフラ-Bグループの宮本・高野です。
今回はManabiCon第3回で発表した「梅田オフィスで認証VLANを導入したプロジェクト」について紹介します。

自己紹介

宮本: 2021年8月に中途入社しました。前職ではネットワークエンジニアでしたが、現在はインフラエンジニアとして、社内ネットワークだけではなく、サーバやクラウドも触る機会が多いです。梅田オフィスのネットワーク構築運用を担ったり、猪名川にある倉庫のイントラサーバ構築を行ったりしました。

高野: 2017年に新卒入社しました。社内のヘルプデスクを経て、現在は社内ネットワークやサーバ構築・保守を行っています。人の顔と名前を覚えることが得意であり好きです。入社以降一貫して、様々な社員と関わる業務に従事できており楽しく働いています。社内ユーザーサポートに行くと、~~餌付けされて~~よく現地でお菓子をもらっていました。

梅田オフィス構築後に発生した問題

前提

梅田オフィスはコロナ禍のソーシャルディスタンス確保のため、本社に出社する人数を分散させるために構築されました。梅田オフィスの構築時に求められたことは以下の2点です。

フリーアドレス

部門の垣根を超えコラボレーションを生むため、フリーアドレスの形式を取りました。また、コロナ禍での「新しい働き方」が前提となっているオフィス構築を行いました。出社と在宅勤務をミックスして働くため、オフィスに在籍している従業員の数よりも座席数を少なく設計し、これが固定席を作らないことにつながりました。

通信品質の安定

どこにいても安定した通信環境で業務を行えるようにするため、すべての座席に有線LANケーブルを配備しました。利便性を考え、ドッキングステーションの機能を持つモニターを購入して、USB Type-Cケーブル一本で電源供給/映像出力/有線LAN接続を実施できるようにしました。

なお、アクセスポイントを天井に十分な数を設置して無線環境も手厚く配備しています。

これまでのオフィスでもフリーアドレスは実施していましたが、無線環境のみでした。
有線LAN環境でネットワークに接続する必要がある従業員は座席を固定とし、「LANケーブルの先にある、ネットワーク機器(スイッチングハブ/L2スイッチ)のポート」と「PC」を1対1対応させてネットワーク制御を行っていました。
この1対1対応をネットワークの用語で「ポートベースVLAN」といいます。

本題

フリーアドレスと有線LAN環境を両立することで、困ったことが発生しました。
それまではMACアドレスベースでDHCPサーバにPCの情報登録を行っていたため、「ポートベースVLAN」でのネットワーク制御ができず、従来の方法では有線LAN環境へ接続することが不可能となりました。従業員が席を自由に選択できるがゆえに、ネットワーク機器のポートとPCが1対1で対応しなくなったからです。

また、梅田オフィスの構築当初はネットワーク接続を可能にすることを優先したため、DHCPサーバでIPアドレスフリーリースの設定を行いました。しかしその結果、外部から持ってきたPC(例: 在宅勤務用PC)でも社内ネットワークに繋がってしまうセキュリティインシデントが発生しました。これは早急に改善するべき問題でした。

この困った問題の解決策として、梅田オフィスのネットワークに「認証VLAN」を導入することを決定しました。利用する技術は「IEEE802.1X」です。

そもそもVLANとは何なのか？

先にポートベースVLANについて記載しましたが、ネットワークインフラに携わっていない方からすると「VLANとは何だろう？」という疑問が浮かぶと思います。

「VLAN」とは「Virtual LAN」の略称です。1つのネットワーク機器の中で、仮想的にネットワークを分割する技術を指します。
VLANを導入することによって、「ネットワーク機器の台数を最小限にできる」、「障害をVLAN内で抑えることができ、他のネットワークに影響を及ぼしにくくできる」等のメリットが得られます。

このため企業のような大きなネットワーク構築には必須の技術です。

じゃあ認証VLANとは何なのか？

VLANがわかったところで、記事のメインテーマである「認証VLAN」について解説します。
認証VLANとは、「ユーザーとVLANを紐づけ、認証することで正規ユーザーが利用するPCに適切なネットワークが割り当てられるようにする技術」を指します。モノタロウでは認証VLANと呼称していますが、「Dynamic VLAN」とも呼ばれます。
「Dynamic VLAN」の語義は「接続する機器によって所属させるVLANを動的に割り当てる技術」であり、認証VLANは「Dynamic VLAN」の手法のうちの1つです。

「Dynamic VLAN」の対義語として「Static VLAN」があります。「Static VLAN」はVLANの紐づけをケーブルの差し口ごとに決める方法であり、前述の「ポートベースVLAN」は「Static VLAN」の手法のうちの1つです。

今回のMonotaRO環境梅田オフィス内では「Dynamic VLAN」を実現させるために「認証VLAN」の手法を取ることとしました。

認証VLANのキーワード「IEEE802.1X」とは？

「IEEE802.1X」とは、ネットワーク機器でユーザーを認証する技術を指します。

PCのことを「サプリカント」(認証を受けるもの)、ネットワーク機器のことを「オーセンティケータ」(認証をするもの)と呼びます。実際に認証するのは、後述のRADIUSサーバであり、オーセンティケータは仲介を行っています。「RADIUS」とは認証のためのプロトコルであり、RADIUSサーバは当社環境でActive Directory(以下ADと略す)と連携しユーザー情報を得ています。

プロジェクト概要

プロジェクト体制

モノタロウ社内では初の事例であるため、下記4つの会社で協業して進めました。

モノタロウ社内メンバー: 宮本・高野(+上長)
ネットワーク機器のベンダー
RADIUSサーバのベンダー
ベンダーを統括する窓口の会社

プロジェクトの予定期間

2021/12~2022/04

実現したいこと

下記3点を実現させるために、プロジェクトをスタートさせました。

ADに参加しているPCのみ、社内ネットワーク接続を許可する
ユーザに紐づいたVLANがアサインされ、PCにIPアドレスが割り当てられること
有線LAN・無線LAN接続どちらでも、ユーザーは同じネットワークに接続できること

検証時の苦労

苦労したことその1: 必要機材とテストパターンの洗い出し

検証するために必要な機材やPC、アカウントの準備が大変でした。ネットワーク機器が多段構成になっている場合も考えて、L2スイッチは2台分準備しました。PCについては、Windowsでは社内用PC、在宅勤務用PCの2台を準備しました。

また、ADアカウントにVLAN IDの情報を付与してRADIUSサーバに情報連携を行うため、ADアカウントを複数用意し、さまざまなパターンの検証を出来るようにしました。

ユーザー目線で考えたテストパターンを洗い出すことも苦労しました。「座席を移動した場合、有線→無線→有線と環境が切り替わるがVLANは即時割り振りされるのか？」「PCを再起動した時にはどうなる？」等、業務中のさまざまなユースケースからテストパターンを考えました。

苦労したことその2:検証環境の構築

現環境に影響を及ぼさないよう、テスト用のL2スイッチと検証用PCを準備しました。pingコマンドによる疎通確認を長時間行い、送信したパケットに欠損が発生しないかのテストを実施しました。

また、検証環境はサーバーラックの中に構築したため、必然的に宮本・高野両名もサーバーラックの前に張り付きになりました。サーバーラックの前にはデスクや椅子はないため、地べたに座りながらああでもない、こうでもないと試行錯誤しました。

苦労したことその3:VLAN設計変更

既存のVLAN設計では部署ごとにVLANを割り当てていました。今回の認証VLANでは部署ではなく社員の役割を定義し、その役割ごとにVLANを割り当てました。たとえば、「アプリ開発者」「インフラ担当」「ビジネス担当」のような形です。

既存の設計では1つのVLANあたり、サブネットマスク/24のネットワークセグメントを割り当てる設計をしていましたが、これでは問題が発生しました。割り振り可能なIPアドレスの枯渇です。

/24のネットワークセグメントは、IPアドレスを255個割り振ることができます。ネットワークアドレスが1つ、ブロードキャストアドレスが1つ、デフォルトゲートウェイアドレスが1つあることを考えると、PCに割り当てられるIPアドレスは255-3=252です。

認証VLANではユーザーの役割ごとにVLANを割り当てるため、有線LAN接続でも無線LAN接続でも同じVLANに所属することになります。有線LANと無線LANでIPアドレスを別々に持つことになるため、1つのPCで2つIPアドレスを消費することになります。

/24 のネットワークセグメントでは、最大で252個のIPアドレスを割り振ることができますが、若干の余裕を持たせて240個まで利用可能にするよう設計しました。 1ユーザが有線LAN接続&無線LAN接続でIPアドレスを2つ消費する可能性を考えると、最大で120ユーザ(IPアドレス配布数:240)まで、/24のネットワークセグメントで収容可能です。しかし「アプリ開発者」は120名以上いるため、/24では収容することができません。

/24より大きなネットワークセグメントはモノタロウのオフィス環境では運用していません。たとえば/23など、より大きなネットワークセグメントではブロードキャストの範囲が広がります。ブロードキャストの範囲が広がると、障害発生時に影響を受けるPCが増えてしまうため今回の設計でも採用しませんでした。

逆に「インフラ担当」は、120ユーザを収容できる /24のネットワークセグメントに割り振ると、IPアドレスが余ってしまうため大きすぎます。

「余っているIPアドレス領域について、/26のネットワークセグメントに縮小する」「アプリ開発者用ネットワークは/24のネットワークセグメントを複数確保する」といった全体的なネットワークセグメント再設計を行った結果、役割ごとに必要なIPアドレス領域を確保することができました。

※補足情報: 役割ごとのVLANアサイン方法
「役割が異なる従業員をそれぞれどのネットワークセグメントにアサインするか？」という課題については、AD上のユーザアカウントにVLAN ID情報を追加することで、ユーザによってアサインするVLAN IDを変更できるように対応しました。

苦労したことその4:有線LAN接続時、通信が不安定になる

元も子もない問題が発生してしまいました。

有線LAN接続直後はVLANがアサインされるのですが、しばらく監視していると通信が途切れ途切れになってしまいます。その後10分もすると疎通不能となる現象が発生しました。

この問題については、丁寧に調査を行い、機器の公式マニュアルとサポートセンターに当たって解決まで至りました。原因としては、コマンドの解釈を誤ったために、スイッチの設定も想定していないものになってしまいました。

コマンドのオプションを外し、一つずつ追加して検証をした結果、問題となるコマンドが明らかになりました。

authentication timer inactivity 1

コマンドの解釈:

誤: 認証失敗時に1秒後に再リトライする。
正: 無通信が1秒あれば認証セッションを終了させる。→この設定では当然有線ネットワークが不安定になってしまう

苦労したことその5:認証VLANを利用しているPCへリモートデスクトップ接続ができない

在宅勤務・出社勤務

冒頭で記載した通り、現在のモノタロウでは在宅勤務と出社勤務をミックスした働き方を行っています。
それぞれの働き方は下記のとおりです。

■出社勤務時
有線LAN・無線LAN双方を利用できる執務室で社内用PCを利用します。終業時は翌日の在宅勤務に備えてPCラックへ社内用PCを置き、有線LAN接続します。
PCラックは在宅勤務用途であり、電源と有線LANを配置しています。この場所を利用する際、社内用PCの電源は入れっぱなしにしています。

■在宅勤務時
在宅勤務用PCからPCラックに置いた社内用PCに対し、リモートデスクトップ接続(以下RDP接続)を行うことで社内環境にアクセスしています。
※この方法が最善とは思っておらず、新たな在宅勤務環境は検証中です。

802.1X の認証モードについて

Windows PCにおいては、ネットワークアダプターの802.1Xの設定として、認証モードを下記A~Cより指定することができます。

　A. ユーザまたはコンピュータ認証
　B. ユーザ認証
　C. コンピュータ認証

今回、B案の「ユーザ認証」を採用し検証を進めたところ、下図のようにPCへのRDP接続が意図せず切断される問題が発生しました。全く接続できないわけではなく、RDP接続が確立されるものの1分程度で切断されてしまうという中途半端な事象も、検証に苦労する要因の一つでした。

RADIUSサーバのログや、NW機器のログと突き合わせて確認したところ、RDP接続時にはコンピュータ認証で接続を試みている動きが見られ、結果としてRDP接続を行うためにはクライアントPC側で認証モードを「ユーザまたはコンピュータ認証」ないしは「コンピュータ認証」に設定する必要があることが分かりました。

なお、認証モードを「ユーザ認証」に設定した際に、1分程度でRDP接続が切断される事象については、Microsoftの公式ドキュメントにて言及されています。
※参考: RDS 接続が入ると、802.1x ユーザー認証が失敗する

試しにA案の「ユーザまたはコンピュータ認証」に変更してみたところ、RDP接続が切れる事象はなくなりました。

ところで、モノタロウにおいては、クライアントPCは下記の要求のため、次の要件が求められます。

要求

リモートサポートのため、対象のPCへRDP接続ができること(後述)
ADから各PCに設定しているグループポリシーを確実に適用させるために、ユーザーログインをせずとも社内ネットワークへの接続が担保されていること

要件

PCに対してRDP接続をすることができる（コンピュータ認証）
ユーザーログイン前の社内ネットワークへの接続が担保できる（コンピュータ認証）
ログインユーザー毎に適切なVLANを割り当てることができる（ユーザ認証）

上記の理由から、認証モードは「ユーザまたはコンピュータ認証」を採用することとしました。

一方、PCラックについては、下記3点の理由から認証VLANの対象外としてDHCPフリーリースのネットワーク環境を継続しました。

RDP接続ではユーザ認証が不可能であり、ログインユーザごとに適切なVLANを割り当てられないため
RDP接続では接続先のクライアントPCがサーバのように扱われます。クライアントPCでの利用を前提としたIEEE802.1Xと組み合わせることは理にかなっていないと判断したため
トラブルが発生した際に在宅勤務者の業務に支障をきたすため

PCラックをDHCPフリーリースにすることにより、セキュリティリスクは残ります。ゲストや出張者がPCを持ち込むことがあり得る執務室のネットワークを認証VLANとし、「PCラックのエリアには梅田オフィス勤務者しか立ち入らない」ことを踏まえてリスク受容を行いました。

まとめると、出社勤務時と在宅勤務時では異なる対処法を取ることになりました。

■出社勤務時
執務室で業務を行うことを前提とし、執務室内のネットワーク(有線LAN・無線LAN問わず)に「ユーザまたはコンピュータ認証」の方式で認証VLANを導入しました。
認証VLAN導入により、執務室で在宅勤務用PC等外部から持ち込んだ端末が社内ネットワークに接続されるセキュリティリスクを軽減することができました。
職場から帰宅する時にPCラックへ社内用PCを置き、有線LAN接続する運用は変更しませんでした。

■在宅勤務時
自宅の在宅勤務用PCから、梅田オフィスのPCラックに置いた社内用PCにRDP接続して業務を行います。
PCラックに敷設した有線LAN環境については認証VLANの導入は行わず、DHCPフリーリースの状態を維持しました。

リモートサポート時

社内ユーザーがPCの利用で困った際、ヘルプデスクチームが利用者の端末へRDP接続をしてサポートするケースがあります。その際、RDP接続先のPCでは事前にサインアウトをしておく必要があります。
ユーザに紐づいたIPアドレス（ユーザ認証用）と、コンピュータに紐づいたIPアドレス（コンピュータ認証用）が異なるため、RDP接続後に接続先PCのIPアドレスが変わってしまい、通信断が発生してしまうからです。

サインアウトをしておくことで、コンピュータ認証のIPアドレスへ切り替わった状態となるので、RDP接続後の通信断は発生しません。また、コンピュータに対してDNSホスト名で接続したい場合は、事前に接続元PC側でDNSキャッシュをクリアしてから接続するといった工夫も必要です。

運用していく中で、考慮すべきことが様々に出てきました。膿が出し切れているかは分かりませんが、根気強く対処を続けています。

学びとなったこと

認証VLAN導入プロジェクトは、企業での導入事例が少なく、先行事例は学校での導入事例程度しか見つけられませんでした。ベンダーもたくさんナレッジを持っていたわけではなかったので、各社それぞれが苦心して導入までこぎつけました。

今回学びとなったことは下記の4点です。

学び1:新システム導入では検討要素が非常に多いため、とてつもなく根気が必要(高野)

プロジェクト期間の中で最も時間を使ったのが検証フェーズです。ADで配布する予定のVLAN情報であったり、ネットワーク機器の設定であったりと考えることが非常に多く混乱することが多かったです。新しいことにチャレンジする際には、検証が長くかかることも踏まえたスケジュールを組む必要があります。

宮本さんが粘り強く検証し、わからないところは噛み砕いて解説してくれたので、私(高野)自身もほぼ分からないところから、ここまで記事を書けるところまで引き上げてもらえました。

宮本さんには感謝しかありません。

学び2:何事も一次情報に当たることは重要である(高野)

インターネットの海には膨大な情報が転がっています。「一次情報に当たること」は当たり前とわかりながらも、自分が実践できていないものだと気付かされました。頼りにしていたサイトに誤記があったことによってコマンドの解釈に間違いが生じたため、公式リファレンスや公式のサポートセンターに問い合わせをすることになりました。

公式のサポートセンターは問い合わせするまでに収集しなければいけない情報が多いため、問い合わせまでのハードルが高いです。しかし、その分非常に迅速かつ正確、そして丁寧に対応いただきました。公式リファレンスが読みづらくともまず読んでみることは、問題解決に向けての最短コースであると実感できました。

学び3:仮説を立てて、動作検証。ベンダーに確認をとって確証を得る(宮本)

設計のとおりに動作することが理想でありますが、想定外の挙動が起こることはゼロではありません。今回は最初から複雑な設計をしていたため、まずは必要最小限の設定までパラメータを減らしました。そこから少しずつ設定を足していき、原因となるパラメータを発見できました。

「この設定ならこういう挙動をするはず」と仮定をして動作検証していき、1つ1つの設定を細かく確認しました。一次情報を閲覧したり、ベンダーに確認を取ることにより、理想の設定に近づくことができました。問題が起きた場合は、出来るだけ状況をシンプルにして考えることが大事だと学ぶことができました。

学び4:ユースケースに基づいて考える(宮本)

「オフィスでPCはどういった使われ方をするだろう？」と出来るだけユースケースをあげて検証に臨みました。

リモート接続先のPCが不調であれば、リモート接続した状態で再起動することもあります。「ではその検証をやってみよう」と実践した結果、問題を見つけたという背景もありました。問題を起こすことなくスムーズに導入するためには、「ユースケースをどれだけ挙げられるか」すなわち「問題を事前にどれだけ潰せるか」が鍵になります。