この記事は、4/28 に動画配信したfreee Tech Night online #1 「3月1日のfreee全社員一斉リモートワークの裏側」 の補足記事です。
TL;DR
freeeがフルリモートに移行するまでのあゆみを時系列でまとめるとこんな感じです。
- 2月12日 リモート対応打診 = リモートの人増えるかも
- 2月18日 VPN能力増強の正式な打診 = max 400人くらいかな
- 2月20日 VPN β公開 = 暫定機材で運用開始
- 2月26日 VPN 全社公開 = 新機材到着
- 2月28日 全社フルリモートへ = max 800人で
- 3月1日 新機材で運用開始
記事の最後に貼ってあるグラフで見ると、移行した様子が綺麗に分かります。
時系列で追ってみる
2月初旬、COVID-19はダイヤモンドプリンセス号で感染が発覚した段階で、まだ、水際で止めることができていると考えられていました。
当時の機器構成はこんな感じでした。
freeeのcorporate engineering部門のissyさんと私(eiji)は、四半期の始めに立てた計画に従って、HA構成のrouterの検証作業を行なっていました。
当時は、確定申告終了後に新しいrouterで運用を開始する予定でした。
2月3日 五反田社内ネットワーク障害
ところが、障害が発生して、社内ネットワークが30分ほど停止してしまいました。実は、この障害は以前発生した障害が再発したものでした。
原因はrouterの能力不足と不完全な冗長化であることは突き止めていて、それを解消するために新しい機材への入れ替えを予定していたのですが、思ったよりも早く再発してしまったため、既存機器(=PA-3050)を流用してrouterの能力増強を先行して行うことにしました。
確定申告期間中の業務停止は避けなけれならない、という事情もありました。
2月5日 PA-3250検証機HA構成でHA Failover試験
検証機としてお借りしていたPA-3250の貸与期限が2/10に迫っていたので、HA構成の新しいrouterであるPA-3250の動作検証を実施しました。
ベンダーのmanualにしたがってHA構成を構築すると、masterの切り替えに30秒ほどかかってしまいました。想定では10秒以下で切り替えて欲しかったので、何か抜けがあるのだろうなぁ、と考えていました。
2月8日 PA-3250検証機HA構成でHA Failover時間の短縮
reference manualを読み込んで、以下の修正を行うことで、2秒に短縮することができました。
- L3SWでPA-3250に結線されているLACPのport channelをport fastに設定する
- PA-3250でCatalystに結線されているAggregate Ethernet InterfaceのLACPで、Fast Failoverを有効化し、Enable in HA Passive Stateにもcheckを入れておく
こうした機器の検証作業は、お金を払ってベンダーに任せる場合が多いのかもしれませんが、検証と構築を1ヶ月程度のスケジュールを提示したところ、折り合ってもらえませんでした。
freeeはスタートアップなので、自分たちで手を動かして素早く進めることが重要だと思っています。
ところで、この時点では、フルリモートのための環境整備を行うなんて話は出ていません。リモートでもオフィスにいる時と同様に仕事ができる環境は目指していましたが、 リモート勤務のためにVPNを提供していた機材のリース期限にまだ余裕があったので、年度末以降にゆっくりやろうと思ってました。
ところが、
2月11日 01:00 旧VPN機器に不正なアクセス集中し性能が低下してしまったので再起動を実施
ということで、以下のような報告をしています。
実は、当時VPNを提供していた機材がDMZなしの構成で運用されていたため、不正な通信をratelimitで落とすようなfilterを書くことができませんでした。VPNに用いるportを全世界に公開して何もfilterしない、自主的にノーガード戦法を取っている状態です。
これを構成変更するとなると、設定変更や、その後の検証作業を含めて、長時間の停止が必要なため、この時点で早いところ別の機器でVPNを提供したいなぁ、とは考えていました。
2月12日 リモート対応の打診
11:15-11:30 朝会
freeeが企業としてCOVID-19対応を行う、という話が出始めました。 この時点では、freeeのメンバーが罹患し、オフィスが閉鎖される事態を想定していました。
12:00−13:00 既存機材=PA-3050のrouter化検証作業を実施
これは、2/3に再発した社内ネットワーク障害対策のための検証作業でした。
14:30-15:00 ミーティングでVPN提供能力増強の打診
リモートワークを実現する手段として、以下の手法を提案しました。 正社員の希望者のみの想定で、max 400 sessionが同時に利用すると仮定していました。
- 旧機材 + 暫定機材 で、VPN sessionを確保する
コスト追加なしで環境構築可能、VPN server設定作業が必要 - AWSにSecurity VPCを別途用意して、VPN server instanceをload balanceさせてVPN sessionを確保する
instanceのコストに加えて、VPC作成、peering、routing、security policy、VPN server設定作業といった作業が必要、session確保に必要なresourceの見積りができていない状況 - SaaSで提供されているapplication proxyを利用して、application sessionを確保する
流行りのzero trust network、trialを準備していたサービスを利用することが考えられたが、予算の問題で400 sessionの確保は不可能、本番運用への移行が4月以降となってしまう
2月18日 VPN能力増強の正式な打診
この日から、新型コロナウイルス対策としてリモートでの勤務を希望する人は届出をすれば可能 になりました。
14:00−14:30 VPN max 400 sessionの確保決定
いくつか提案した手法のうち、もっとも短期間で確実に構築できると想定された暫定機材によるVPNを増強する手法が選択されました。
17:00 PA-3050上でVPN構築作業開始
とりあえず、PA-3050をrouterとして動作させて、別にVPNを提供できる状態を目指すことにしました。
20:17 Password認証でVPN構築完了
ベンダーが提供していたmanualにしたがって、3時間ほどで設定を完了しました。
ただし、PA-3050のIPsecの最大帯域は500Mbpsのため、もしも全員*1がリモートに移行すると帯域が不足すると予想していました。あくまで暫定的な解でした。
2月19日 暫定VPN機器の設定完了
前日から受付を始めたリモートの届出が、100人を超えました。
旧機材のVPNは、すでに不安定で接続できないという問い合わせをこの時点で受けるようになっていました。
でも、CPUは余裕でしたし、
帯域も余裕だったのです。
ベンダーさんに問い合わせても、すぐには解決できないようでした。
16:51 OneLogin MFAのVPN構築完了
リモートからのVPN接続を許可する際に考慮すべきセキュリティ的な弱さの一つは、認証がパスワードのみという運用が多いことです。もしも、私物のPCに設定をコピーされてしまうと、そこからもアクセスが可能になってしまいます。
でも、issyさんがOneLogin MFAとの連携を設定してくれました。
これが正常に動作するためには、「CertificateのbasicConstraints=CA:TRUEを入れないと、Paloaltoが認識しない」という罠を攻略する必要がありました。
これで、少なくともMFA deviceを持っている人だけにVPN userを限定することができるようになりました。
VPN接続できるdeviceを限定するためにdevice証明書の配布を自動的に行うことを予定していましたが、Windowsへの配布に手こずっていたため、一旦諦めることにしました。
ここからは、MacやWindowsからVPN接続をするためのmanualの整備を急ぎました。
この日に、ベンダーさんから新しい機材=PA-3250 2台が最短で2/26に納品できるとの連絡がありました。
この機材は、3/20−22に運用開始のつもりだったので、移行準備までの時間が十分確保できて、急いでくれたベンダーさんありがとう！って思ってました。
2月20日 β公開
00:07 VPN β公開
Slackで以下のお知らせをしました。
engineerさんたちの手を借りて、manualを手直ししつつ、まずは、つながらない問題を解決していきました。
trouble shootingは、SlackやG Suite docsで書かれたmanualのコメントで行われていました。
2月26日 全社公開
08:41 VPN 全社公開
この日の午後に、ベンダーさんからの連絡の通り、新機材=PA-3250 が到着しました。
この日のうちに、Mac OSへのdevice/user証明書配布手順を確立しました。
2月27日 確定申告期限が4/15に延長されることが発表される
これで、もともと、3/16の確定申告終了後の連休、3/20−22あたりで予定していた社内ネットワークの更改作業が、不可能となりました。
3月末で当時のrouterはサポート終了が決まっていたので、入れ替え作業の先延ばしは無理だったのです。
いやいや、困りました。
そして、この日は、「VPNがつながらない」というtrouble shootを大量に行っていて、新しい機材の方には手をつけられませんでした。VPN利用のお知らせのコメントスレッドが200件を超える状態でした。
ただ、問い合わせ率は、全利用者の2%ほどだったので、どうにか対応を行えました。
当時多かった問い合わせは、以下の4つでした。
- kernel driverの許可忘れ
- manualで手順が目立つように修正しました。再インストールを案内することも多かったです。
- 認証に用いる証明書のimport忘れ
- remoteから自動配布するようにscriptを組みました。
- 自宅側のrouterの問題でどうしてもIPsec packetが通らない
- server側でSSL VPNにfallbackさせるようにしました。
- MTUが大きすぎて、IP defragmentが多発し、接続できても使い物にならない
- 本来ならMTUは自動的に調整して欲しいところですが、環境によってはうまくいかないこともあります。MTUを手動で調整するmanualを書きました。engineer向けにwiresharkで状況を確認できるようにもしました。
2月28日 全社フルリモートへ
この日の朝に、業務委託さん、アルバイトのみなさんも含めて、基本的に全ての社員がリモートになることが知らされました。
週明けの3/2に、リモートワークの用意ができていない人は準備を各自行う、ということだったので、それまでに新しい機材でVPN環境を整えておく必要がありました。
というのも、PA-3050だと性能的にIPsec VPNは500Mbpsが限界で、性能を確保するにはPA-3250に移行するしかなかったのです。
まだ、開梱すらしてなかったんですけどね。
全社フルリモートということで、mobile teamが検証用に用いていたiPhoneやAndroidについてもVPN接続が必要になりました。
この時点のPA-3250のライセンスには、mobile VPNのライセンスは含めていなかったので、この日から別途mobile VPNライセンスの調達も開始しました。
この日、issyさんが、Windowsへのdevice証明書配布手順を確立してくれました。
17:00-23:00 新機材=PA-3250 開梱、ライセンス有効化、HA構成構築
通常業務をやっていたら、夕方になってしまいました。急いで、作業を開始しました。開梱、物理結線と進めて、空中配線になってしまったりしましたが、最初のうちは順調でした。
ただ、PA-3250のライセンス有効化に癖がありました、提供されたmanualの記述が正確ではなく、途中に採用面接を挟んだりしたので、延べ4時間ほど試行錯誤する結果になりました。
ライセンスを有効化したら、HA構成の構築を行いました。これは2月上旬に検証していた設定をrestoreするだけで終了しました。
事前検証大事。
この日はここまでで終電近くなってしまったので、帰宅するまでにリモートから作業できるようにしておきました。
2月29日 PA-3250 VPN設定
休日返上で、新機材=PA-3250にVPNの設定を追加しました。この時の作業は、リモートから行いました。
うるう年でよかった。
3月1日 PA-3250へVPN運用を移行
14:00-15:00 VPNを暫定機材のPA-3050から、新機材のPA-3250に移行
物理的な配線の差し替えと、routingの変更が必要だったので、この日は流石に休日出社が必要でした。
この作業によって、VPNの提供元は、暫定的に利用していたPA-3050から、新しい機材であるPA-3250に移行しました。
3月2日 全社フルリモート準備
全社でリモートに移行する準備をする日でした。
サポートのみなさんが利用しているsoftware phoneをlocal breakout(VPNを経由せず直接inetnetに抜け)させる設定を案内しました。
iOSへのdevice証明書配布手順を確立しました。
この日から、VPNの証明書認証を開始しています。 つまり、password + OneLogin MFA + 証明書でVPN user/deviceを認証するようになりました。
3月6日 mobileもVPN接続 + traffic engneering
mobile VPNのlicense適用完了、たった１週間で調達できました！
これで、iOS/Android/Chromebookでも利用可能となりました。
issyさんが、早速Chromebookへのdevice証明書配布手順を確立してくれました。
大多数の方がリモートでの作業に移行すると、trouble shootの対象も変わってきました。
- VPN接続はできるが、利用したかった特定のサイトだけ見えない
- 気づかぬうちに自宅に持って帰ったPCにIPv6 global unique addressが当たっていることが原因でした。
- A recordよりもAAAA recordの方が優先されてしまうので、IPv6を一時的に無効化することで対応しました。
- online meetingを実施していると画像や音声が乱れてしまう、切れてしまう
- 原因は複数考えられます。
自宅回線の帯域不足、自宅に固定回線がない場合、mobile Wi-Fiを会社から提供していますが、帯域不足が否めません。 - CPU resource不足、VPN sessionに動画を通してしまうと、暗号化/復号化にCPU能力をつぎ込まなければならず、packetの送受信timingに揺れや遅れが生じてしまいます。
- 出来るだけVPN経由の通信を減らすため、online meetingやapplication layerで認証を行なっているSaaSについては、local breakoutさせました。
- 原因は複数考えられます。
3月15日 旧機材によるVPN廃止
数人の方が、古いVPNを利用し続けていたので、新しいVPNへの移行を直接お願いして、移行完了を確認した後、旧機材でのVPNの運用を停止しました。
3月19、20日 社内ネットワーク更改
五反田オフィスには誰もいない状態だったので、もともと確定申告終了後に予定していた社内ネットワーク変更作業を平日に実施しました。 機器構成としては、とってもsimpleなものになりました。
ちなみにイベントでは、時間が足りなくて話せませんでしたけど、
PA-3250のpolicy、L3SWの設定など、社内ネットワークの設定は、ほぼすべてansibleでcode化しました。
おかげで、何を考えてその設定をしたのかわかるようになりましたし、設定変更前に差分を確認できるようになりました。
グラフで見る全社フルリモート
オフィスに出社した人の通信
五反田オフィスに出社したuserがinternetとやりとりした通信量=trafficを見てみると、
2月28日までは、出社する人も多く、それなりのtrafficが発生していますが、 3月2日に移行準備が完了するとtrafficは順次減少し、3月10日には、ほぼ通信がなくなってしまったことが読み取れます。
VPNを利用した通信
これに対して、VPNを利用したtrafficを見てみると、
3月2日は移行準備のためtrafficが少なく、次の日の3月3日から増えていることがわかります。 また、3月6日以降は、split tunnelによってonline meetingなどをlocal breakoutさせることで、trafficの下限が下がっていることが分かります。 3月23日の週にtrafficが増えているのは、地方の拠点がフルリモートを開始した影響です。
VPNの同時接続数
最後に、VPNを利用している人数の推移を見てみると、
こうした状況でも、VPN同時接続数の増加=VPNを利用した通信量の増加とはなっておらず、VPNを経由する通信量をtraffic engneeringによって適切に抑制ができているので、全社フルリモートが長期化しても、このまま乗り切れるのではないかと思っています。
もちろん、リモートに慣れてきたVPN利用者の方々が、気を使ってくれている面もあると思います。
ちなみに、帯域が足りなければ、複数のinternet接続回線を束ねるECMP*2構成を想定していて、準備も進めています。
最後に
VPNは、決して最終解ではありません。 今回は、限られた時間と予算の中で、もっとも安く*3、短期間で構築できる現実的な解として、VPNを選択しました。 本来なら、Zero Trust Networkでuserとserviceをend-to-endでmutual authenticateしたかったので、VPNはあくまで一時的な解です。
なお、VPNを接続するだけで、すべてが許可される構成にはなっていません。VPN接続後はuserやgroup別にpolicyが割り当てられますし、各サービスへのアクセスは個別に認証が実施されます。
多分、半年後には、別のことを言っていると思いますが、現状の報告は以上です。
