皆さんこんにちは。CloudbaseでCorporate ITを担当しております、yojiです。
Cloudbaseでは、メンバーの快適な仕事環境を整備する一環として、オフィスに10G回線を引いております。
構成としては、以下のとおりです。
回線はアルテリアネットワークスの「XPass（クロスパス）」を導入しています。 規格上の制約でUniFi Dream Machine SE（以下、UDM SE）では直接通信を受けられないため、前段にヤマハのルーター「RTX1300」を設置しました。 これにより、ネットワークの通り道が二段階になる「二重NAT」という構成で運用しています。
また、ISMS認証を取得している関係から、入退室状況の把握をするために、同じUniFiソリューションの防犯カメラ製品も導入し、動体検知を行っております。
…と、ここまでが運用開始時の状況であったり、私が着任する直前の状況でした。
着任後に色々見えてきた課題を、今回はお話ししたいと思います。
- Cloudflare ZTNAの接続ができない
- 無線LANの電波が弱い
- 数十人が同じWi-Fi下にいる場合に不安定になる
- Wi-Fiが使えなくなった！？
- Splatoon3でマッチングができない
無線LANの電波が弱い / 数十人が同じWi-Fi下にいる場合に不安定になる
まずはこちらについてです。
Cloudbaseでは、オフィスがまだそこそこコンパクトということもあり、稼働しているAPは3台（執務室に2台、ミーティングブースとエントランス共用で1台）の構成です。
執務室はメインの業務スペースとなるため、冗長化の意味も込めて2台で運用しており通信は安定しています。一方、ミーティングブースとエントランスは1台のAPでカバーしており、ベストな配置場所を改めて見直すことにしました。
通常であればRSSI値などを測定しながらオフィス内の調査が必要になるのですが、Ubiquiti製品にはありがたいことにInnerSpaceという機能があります。オフィスの図面をもとに、壁を描画してその材質を設定することで、簡易的に電波の到達状況を可視化することができます。
この機能をもとにAPの配置を見直した結果、電波減衰の問題はだいぶ改善されました。
また、UniFi側のAP送信設定についても、弊社は9割がMac環境ということを踏まえてチューニングを行いました。具体的には、送信出力（Tx Power）の調整、バンドステアリングの設定、チャンネル幅の最適化、クライアント数に対するレート制御といった項目を、Mac端末の無線特性やオフィスの利用状況に合わせて見直すことで、メンバーが集中した際の輻輳問題も改善しております。
40人規模のスタートアップで一人情シスがWi-Fiの最適化にどこまで時間を割くかは悩ましい判断ですが、全員がWi-Fiに依存して業務をしている以上、ここは投資する価値があると判断しました。InnerSpaceのようなツールがあると、感覚ではなくデータに基づいて配置を決められるので、限られた時間の中でも効率よく改善できたと思います。
Wi-Fiが使えなくなった！？
次にこちらですが、これは単純な話で、朝オフィスに来てみたらなぜかAPが死んでいた、というものです。
幸いにもその日一番最初にオフィスに来たのが私だったので、応急処置をして復旧させました。
原因を調査したところ、UDM SEのOS自動アップデートを即座に展開する設定にしていたことが発端でした。APはスイッチ配下に接続しており、スイッチとUDM SEはSFPで接続していたのですが、アップデートが展開された際に何らかの要因でSFPのリンクが確立できなくなり、結果としてスイッチ配下のAPもすべて通信不能になったのが原因でした。
再発防止策として、まず執務室に2台設置してあるAPの片方を、スイッチではなくUDM SE側に直接接続し、SFPリンク障害時にも最低限の無線環境が維持できるよう冗長化しました。
また、OSの自動アップデートについても即座展開ではなく、業務影響の少ないタイミングで適用するよう運用を見直しています。
Splatoon3でマッチングができない / Cloudflare ZTNAの接続ができない
最後にこちらについてです。
もちろん業務時間にSplatoon3を遊んでいるわけではなく、社内にはゲーム部という部活動があり、就業時間後に社内メンバーやお取引先の方々と活動をしておりますが、その際に頻発していた事象です。
Cloudflareに関しては、ZTNAやCASBの製品調査を行っていた際に発見した挙動で、DNS onlyモードでしか動作せず、Traffic and DNS(Full)モードだと疎通に失敗するというものでした。
一見すると無関係に見えるこの2つの事象ですが、一人情シスとしてはまず共通項を探るところから始めました。
Splatoon3はP2P通信、Cloudflare ZTNAはWARPトンネルと、通信方式はまったく異なります。しかし、どちらも「通常のWebブラウジングは問題ないのに、特定の通信だけが失敗する」という点では共通していました。
最初に疑ったのは二重NAT構成そのものです。NATトラバーサルの問題であれば、UPnPやNATタイプの設定で解決できるはずですが、RTX1300側の設定を見直しても改善しません。
次にファイアウォールのルールを確認しましたが、これも問題なし。
そこで視点を変えて、「特定サイズ以上のパケットだけが通らないのでは？」という仮説を立てました。 「なぜ特定の通信だけが通らないのか」という違和感を放置せず、AIも活用しながら膨大な機器ログを多角的に分析しました。 粘り強く調査を継続した結果、最終的にMTU不整合という根本原因にたどり着くことができました。
XPass（クロスパス）はIPv4 over IPv6のトンネル方式で通信を行います。RTX1300がこのトンネルの終端を担っているわけですが、IPv6ヘッダによるカプセル化のオーバーヘッド分だけ、実効MTUはイーサネットのデフォルトである1500よりも小さくなります。
にもかかわらず、後段のUDM SEではMTUがデフォルトの1500のまま運用されていたため、このサイズを超えるパケットが正常に通過できない状態になっていました。
通常のWebブラウジングなどではPath MTU Discoveryが機能するため問題が顕在化しにくいのですが、Splatoon3のP2P通信やCloudflare ZTNAのトンネル通信のように、特定のパケットサイズやプロトコルに依存する通信では、この影響をもろに受けていた、というのが真相です。
現在はMTU値を適切に修正することにより事象は発生しなくなりました。
ただし、これはあくまで二重NAT構成を前提とした回避策であり、根本解決には至っておりません。一人情シスとしてはRTX1300を撤廃してUDM SE一台で完結させるのが理想ですので、今後の製品アップデートがあり次第対応していきたいですね。
将来的な展望
今のオフィスでは現状この設備で賄えておりますが、メンバーが増え、扱うデータや業務の幅が広がっていく中で、次のステップとして見えている課題もあります。
現在は1人あたりの帯域を100Mbpsに制限しています。10G回線とはいえ、1人が数Gbpsをフルに使ってしまうと他のメンバーの通信に影響が出るため、現状の規模では妥当な制限と判断しています。ただ、今後のユースケースの変化に応じて、この制限は見直していきたいと考えています。
また、APの増設による安定した配置の実現、オフィスの防犯体制の強化、ネットワーク機器のUPS導入など、機器の追加投資が必要な領域も残っています。事業の成長フェーズに合わせて段階的に進めていければと思っています。
それまでは、RTX1300とUDM SEくんが健やかに過ごせるよう、整備を続けていきます。
これからもよろしくね。
Cloudbaseでは、単にネットワークを管理するだけでなく、メンバーが最高のアウトプットを出せる環境を共に創り上げてくれる2人目のCorporate ITメンバーを募集しています。
セキュリティを「制約」ではなく「事業の挑戦を支える基盤」として捉え、一緒にIT基盤を作っていける方を探しています。
興味のある方は、ぜひこちらのJDをご覧ください。
