はじめに
こんにちは！KADOKAWA Connected、ネットワークチームの 立松(Matsu) です。データセンターとキャンパスのネットワークサービスのデザイン、デリバリ、O&Mの業務を担当しています。「サクラタウンへの無線デプロイでヒヤッとしたお話」という記事が好評だったので、サクラタウンシリーズ第二弾として、有線ネットワークについて書いてみたいと思います(とはいえ、前回も無線の皮を被った、ほぼ有線ネタだったのですが...)。
この記事でお話しすること
実は、ところざわサクラタウンのネットワーク設計と運用は、「ネットワークエンジニアが一度はプレイしてみたい無理ゲー200選」にもノミネートされているヤバイ案件と古事記にもそう書かれているのです(アイエッ！)。この記事では、 有線ネットワークの無理ゲーな要件に対して、どのように解決したのか？について、書いていこうと思います。なので、前回のようなトラブルシュートではなく、複合施設に求められる要件の実現と、運用が始まってからのギャップについてお話ししてみたいと思います。
この記事は、スイッチを用いたネットワークに馴染みがある方むけの記事になっています。少なくとも、ポートベースVLANを理解されていればお楽しみいただけるかな、と思っています。予めご承知おきください。
- はじめに
- この記事でお話しすること
- ワークエリアとパーマネントリンク
- 複合商業施設で必要となる有線ネットワーク
- 有線LANの接続端末を「認証」する
- 有線LANの接続端末を個別のネットワークにつなげる
- 有線認証ポートの下にハブを生やす
- 標準HUB
- ネットワークシェル芸、再び
- おわりに
ワークエリアとパーマネントリンク
当然の話ですが、スイッチを端末と繋げるためには、そのための有線LAN回線が必要になります。その際の物理のお話を少ししたいと思います。
スイッチは基本的に機械室に鎮座まします場合と、パイプスペース(シャフトスペース)や設備キャビネット、はたまた天井裏などの設備室に追いやられて設置される場合があります。
【パイプスペース(シャフトスペース)に設置されたネットワークラックの例】
こういった機械室や設備室から、実際に端末が設置されるワークエリア(執務室)などへ有線LANが配線されるわけです。
この間のEnd-to-Endの有線LAN配線のことを「チャンネルリンク」と呼び、特に壁や天井などを通る固定された有線LAN配線のことを「パーマネントリンク」と呼びます。また、実際にユーザが必要に応じて取り回す有線LAN配線のことを、「ワークエリアコード」と呼びます。機械室/設備室内の配線であったり、ワークエリアコードは刺したり抜いたり好き勝手に配線をし直す事ができますが、パーマネントリンクは壁を貫通していたり壁の中の配管を通っているために、いじる事ができません。そのため、パーマネント=永続的なリンクと呼ぶのです。このあたりの定石は、BICSIの発行するTDMM(Telecommunication Distribution Method Manual)や、JISの資料に詳しく載っていますので、気になる方はググってみてください(上記の図はJIS X 5150規格を参照し作成しました)。
複合商業施設で必要となる有線ネットワーク
ところざわサクラタウンにおけるネットワークの提供方式は、基本的に無線接続というポリシーにしています。なぜかというと、有線接続では当然ながらケーブルの敷設コストがかかりますし、スイッチのポートの数にも限りがあるからです。ただし無線接続はISMバンドの干渉やDFSの発動、持ち込みWiFiアクセスポイントによる電波環境汚染など、安定性が保てない場合もあり得ます。無線LANをサポートしない端末は当然として、固定される端末や、安定性や高速性能を重視する端末などをネットワークへ繋げる場合は、必然的に有線LANを使用することになります。有線LANのポートを提供する場合は、使用されるVLANのアクセスポートとすることが一般的です。
しかし、KADOKAWAでは従業員が働きやすいようABW(アクティビティ・ベースド・ワーキング)という「時間や場所にとらわれない働き方」が推進されていたり、ところざわサクラタウン自体が複合施設という都合から館内に多種多様な個別ネットワーク需要が存在するために、どの通信アウトレットに何のネットワークを出せばいいのかを決める事ができませんでした。
有線LANの接続端末を「認証」する
どの通信アウトレットに何のネットワークを出すのかわからないという事は、どの通信アウトレットに何の端末が繋がってくるか、わからないという事です。おぼろげながらに浮かんできたんですよ、第一に考えなければいけないのはセキュリティだという事が。編集部のVLANに対して編集部以外の従業員が入れてしまったらいけませんし、工場のVLANに従業員の持ち込み端末が繋がれてマルウェアが蔓延してしまったら困ってしまうのです。従業員だけでなく、お客さまの立ち入るエリアにも通信アウトレットがあるため、許可された端末のみが社内LANに繋がるように考えなければいけません。これを実現する手法として、「有線認証(ポートベース認証)」という方式があります。有線LANで接続された端末を認証し、その有線LANポートにアサインされたVLANに接続してもいいかどうかを判断する事ができます。主に下記のような方式が使用されます。
- Web認証(Captive Portal)：LANに端末を繋げた際、認証用のWebページに誘導されます。ユーザはここで、ID/Passwordを入力することで、ユーザの認証を行います。フリーWiFiなどで使用された事がある方も多いのではないでしょうか？しかし、規格化されておらずベンダにより実装がマチマチで、うまく動かない場合もあるようです。
- IEEE 802.1X認証：この方式では、端末に予めセットアップしておいた証明書を用いて、端末の認証を行います。証明書を入れておかねばならない手間はありますが、IEEE 802.1X(Port-based NAC)という規格で標準化されており、認証も暗号化され安心安全な方式です。
- MACアドレス認証：この方式では、端末のMACアドレスを使用して、端末の認証を行います。プリンターやIoT機器などの、証明書がインストールできない様々な端末も認証できます。ただし、MACアドレスを詐称する事で突破できてしまうという弱点があります。Ciscoでは「MAB認証(MACアドレスバイパス認証)」と呼ばれ、IEEE 802.1X認証が失敗した時に使用される事が一般的です。
Web認証やMACアドレス認証を行う際、許可する端末の情報をスイッチのConfigにハードコーディング することも可能ですが、管理の都合上、認証サーバを使用します。認証サーバはRadiusを使用する事が大半で、OSSであればFreeRADIUS、プロプライエタリなものであればInfoBloxやClearPass、Windows NPS(昔のIAS)を使用できます。認証サーバとして、Radius以外にもDiameterを使用する場合もあるようですが、最近はモバイル系などでしか見かけず一般的ではないでしょう。
なお、IEEE 802.1X(Port-based NAC)という規格において、証明書を格納した被認証端末をサプリカント、有線認証を実施するスイッチをオーセンティケータと呼称します。
ところざわサクラタウンでは、オーセンティケータにArubaの2930スイッチを使用するため、認証サーバは同一ベンダーの製品「ClearPass」を使用しました。認証方法の組み合わせとしては、IEEE 802.1X認証とMACアドレス認証を選択しました。IEEE 802.1X認証が失敗したらMACアドレス認証を実施し、それでもダメならばゲストVLANに落とす、という非常にオーソドックスな設計にしました。
有線LANの接続端末を個別のネットワークにつなげる
通常の有線認証では認証VLAN(図中では社内ネットワークVLAN)とゲストVLANの二種類のネットワークにしか接続ができません。つまり、有線LANポート自体に「端末が繋がるべきであろうVLAN」を予め、設定しておかなければならないという課題は解決しないのです。今回のような要件では、どのポートに何のネットワークを出せば良いのか分からないので、十分ではありません。
そこで、ダイナミックVLANという仕組みを使用して、端末毎に様々なネットワーク(VLAN)に振り分けをできるようにします。
ダイナミックVLANという仕組みについて規格化された正式な文章を実は知らないのですが、多くのオーセンティケータ(スイッチ)はRadius-AcceptのAVP(Attribute Value Pair)を使用して任意のVLANをアサインする事が可能です。AVPは属性値ペアのことで、RFC2868に記載されています。ダイナミックVLANを実現するにあたり、一般的にはTunnel-Private-Group-ID(属性値)に格納される文字列(=ペア)がVLAN IDとして使用されます。この辺りは、CiscoやArubaの資料を確認すると良いでしょう。認証サーバにRADIUSではなくDiameterを使用する際でもAVP code 81として同名のアトリビュートがありますので、試したことはありませんがDiameterでも上手くいくハズです。
なお、有線LANを前提にここまで話しましたが、ところざわサクラタウンでは無線でも802.1X認証やダイナミックVLANといった仕組みを使用して端末を認証し、同じことを実現しています。この辺りもCisco(WLC)やAruba(MC)のドキュメントを紐解けば、さして苦労せず実現が可能です。
有線認証ポートの下にハブを生やす
最初に、パーマネントリンクの話を少ししましたね。ネットワークの提供にあたっては必要なパーマネントリンク数を事前に把握した上で、十分な数の配線をしておく事が重要です。しかし、一般的にジャブジャブとパーマネントリンクを配線をすることは良いアイディアではありません。予算が無限にかかりますし、またワークエリアコードの数が増えて輻輳しても景観上・安全上よろしくありません。
ところざわサクラタウンの場合は突発でイベント需要や新規案件が出てくる事が多々あるのですが、予算や施設の運営上の安全保護の都合でパーマネントリンクの追加配線工事が困難という事情もありました。
パーマネントリンク数以上のネットワーク需要が出てきたとすると、(原始時代に生きているのでなければ)選択肢として上がってくるのは「ハブ」を接続する事です。しかし、ここが悩みどころでした。有線認証ポートの配下にハブを接続することは、ポートベースではなくユーザベースでの認証を行うことで、技術的には可能です。しかし、これには多くのデメリットがあります。
Case.1：悪意のあるユーザがスニッフィングを行いMACアドレスを詐称することでなりすましされ、セキュリティも何もなくなる。
Case.2：ユーザがBBルータをハブとして使用した場合、オーセンティケータでdhcp-snoopingをしていたとしても、意図しないDHCPパケットが流通してしまう。ユーザには悪気はない。
Case.3：ハブの口に空きがあると不安になるユーザが、ケーブルを開いているポートに差し込む。するとvoilà、ループが発生する。もちろん、ユーザには悪気はない。
Case.4：想定外に多くの端末が繋がってきて、ユーザベース認証の上限値をカンストする。もちろん、ユーザには悪気はない。
思いつくだけでも4つです。Case.1はさておきとして、ユーザに悪気はなく、いつでも起きうる事故です。持ち込みのHUBは我々の管理外なので当然切り分けは現地でしかできませんし、申告は我々インフラ部隊のことを気にしてはくれません。ところざわサクラタウンのネットワークは24時間の稼働が求められるので、夜もおちおち寝られなくなるのです。
標準HUB
そこで我々が考えたのが、「標準HUB」と呼ばれる仕様化されたHUBを支給することでした。Arubaの12ポートスイッチを大量に準備して、設置マニュアルとともに、ヘルプデスク部隊にお配りをしたのです。
この標準HUB自体をオーセンティケータとし、端末を有線認証することにより安全かつ低コストにネットワークの拡張が出来るようになったのです。まぁ、キャンパスネットワークは通常、コア〜ディストリビューションスイッチ〜フロアスイッチの3層構造を取る事が定石なので、予定調和と言えなくもないのですが。
また課題に対して、ベテラン勢によりGVRP(VTPの様なもの)の導入も検討されたのですが、仕様上の制限やデリバリを優先するために見送りました。
ちなみに、有線認証ポートを標準HUB用に設定変更する際には、ヘルプデスク部隊からワークフローが回ってくるように業務設計をしました。ワークフローがまわって来たら、対象の通信アウトレットに対応するスイッチのインタフェースの設定を、有線認証設定から標準HUB用の設定に入れ替えてやればいいのです。しかし、ここで少し課題が出てきました。
ネットワークシェル芸、再び
Aruba(というかHP ProCurve系)のスイッチを触った経験がある方は経験があるかもしれないのですが、実はArubaの有線認証のConfigは、消すのが大変に面倒くさいのです。例としてAruba 2930Mフロアスイッチのinterface 1/14の有線認証のconfigをshow runコマンドで見てみましょう。なお、商用のConfigを載せているので、パラメータは検閲させていただいています。
stw01se-fsw03# show run
---snip---
interface 1/14
name "<<LN LN011202-3>>"
rate-limit bcast in kbps xxxx
rate-limit mcast in kbps xxxx
rate-limit unknown-unicast in kbps xxxx
exit---snip---
nameはインタフェースのdescriptionの設定で、統一された表記方式を定めています。レートリミットはBUM抑止の設定です。それ以外は、設定が入っていないように見受けられますね？では、全体のshow runをgrepしてみるとどうでしょうか。
stw01se-fsw03# show run | inc 1/14
interface 1/14
aaa port-access authenticator 1/14 tx-period x
aaa port-access authenticator 1/14 supplicant-timeout x
aaa port-access authenticator 1/14 server-timeout x
aaa port-access authenticator 1/14 reauth-period x
aaa port-access authenticator 1/14 logoff-period x
aaa port-access authenticator 1/14 client-limit 1
aaa port-access mac-based 1/14 logoff-period x
aaa port-access mac-based 1/14 reauth-period x
aaa port-access mac-based 1/14 unauth-vid xxx
aaa port-access 1/14 auth-order authenticator mac-based
aaa port-access 1/14 auth-priority authenticator mac-based
stw01se-fsw03#
認証設定はinterface ディレクティブの配下ではなく、別のところに記載がなされている様です。という事は、Ciscoの様に単純に「no interface 1/14」としただけでは、Config削除ができないのです。じゃあ 「aaa port-access」の先頭に「no」をつけてやれば上手く消えるのか？というとそういう訳にもいきません。AirHeadsで同じ様に困っている人が見つかりました。
Cant undo aaa command | Network Management
Remove All AAA Config From a Port | Wired
なんと面倒なことに、デフォルト値を入れてやらないと、設定が削除できないのです。まぁパラメータは残しておいても害はないのですけど、後に負債化する可能性が高いのできれいに消しておく頃が大事です。そこで、テンプレートエンジン(m4マクロ)の登場です。
yuusuke_tatematsu@yutatematsu ~> cat ln2bb.m4
---snip---
no aaa port-access authenticator AUTH_PORT
aaa port-access authenticator AUTH_PORT tx-period 3
aaa port-access authenticator AUTH_PORT server-timeout 300
aaa port-access authenticator AUTH_PORT reauth-period 0
aaa port-access authenticator AUTH_PORT logoff-period 300
aaa port-access authenticator AUTH_PORT supplicant-timeout 30
no aaa port-access authenticator AUTH_PORT client-limit
no aaa port-access mac-based AUTH_PORT
aaa port-access mac-based AUTH_PORT logoff-period 300
aaa port-access mac-based AUTH_PORT reauth-period 0
no aaa port-access mac-based AUTH_PORT unauth-vid
no aaa port-access AUTH_PORT auth-priority
no aaa port-access AUTH_PORT auth-orderint AUTH_PORT name "<<BB LN_NAME BB_DESC IGN>>"
---snip---
yuusuke_tatematsu@yutatematsu ~> m4 -DAUTH_PORT="1/11" -DLN_NAME="LN051908" -DBB_DESC="stdhub" ln2bb.m4
---snip---
no aaa port-access authenticator 1/11
aaa port-access authenticator 1/11 tx-period 30
aaa port-access authenticator 1/11 server-timeout 300
aaa port-access authenticator 1/11 reauth-period 0
aaa port-access authenticator 1/11 logoff-period 300
aaa port-access authenticator 1/11 supplicant-timeout 30
no aaa port-access authenticator 1/11 client-limit
no aaa port-access mac-based 1/11
aaa port-access mac-based 1/11 logoff-period 300
aaa port-access mac-based 1/11 reauth-period 0
no aaa port-access mac-based 1/11 unauth-vid
no aaa port-access 1/11 auth-priority
no aaa port-access 1/11 auth-orderint 1/11 name "<<BB LN051908 stdhub IGN>>"
---snip---
yuusuke_tatematsu@yutatematsu ~>
一部抜粋して記載しましたが、このようにポートID、通信アウトレットID、特記事項をシェルから叩けば一瞬でポートの設定変更Configを生成することが可能になりました。
あとは、前回お話ししたのと同じスキームで、ネットワークシェル芸によりsed/awk/xargsとrancidを駆使すれば、ワンライナーで瞬時にConfig変更を実施できる様になり、ローカロリーな対応が可能となりました。
おわりに
いかがでしたでしょうか。今回は前回のようなトラブルシュート話ではないので、ドキドキハラハラが無く楽しんでいただけたか若干不安ですが、ここまで読んでいただいてありがとうございました。実は運用上の課題もまだまだ残っており、有線LANネットワークについてはまだまだ話題が尽きません。タイトルに「認証編」が入っていますのは、有線LANネットワークのオオモノである「WDM話し」が残っているからなのです。他の課題やWDMのお話は、来月開催されるJANOGで発表します。リモートで視聴ができますので、ぜひぜひご視聴いただければ、望外の幸せでございます。それではまた！
