SoftEther VPN運用の裏側 – 台風による緊急対応の学び

はじめに

こんにちは！
システム事業部のfujikoです。
新卒で入社し現在2年目で、社内のITインフラ周りを担当する基盤チームに所属しています。
具体的な業務内容は、プロダクトインフラの構築・運用、メールサーバー・VPNサーバーの運用保守、その他ITサポートなど多岐にわたります。
その中でも特にVPNの運用業務は、リモートワークの普及に伴いその重要性が高まってきています。

8月のある日、台風が接近し、普段は出社勤務を行っている社員が在宅勤務に切り替える動きが増えたことで、VPNアカウントの発行申請が一気に集中しました。
その際、我々のチームは迅速に連携してVPN環境を整え、リモートワークへのスムーズな移行を実現することができました。
今回は、その緊急対応の流れや具体的な対策、そしてそこから得た学びについて紹介します。

緊急対応の背景

8月に発生した台風は被害が大きくなることも予想され、外出が難しくなることが懸念されました。
そのため在宅勤務を希望する社員が急増し、台風の前日に、社員から次々と新たなVPNアカウントの発行依頼が寄せられました。
通常であれば、依頼は月に数件ほどなのですが、今回は数十件の発行依頼が一度に集中し、迅速な対応が求められました。
また、社員のほとんどが在宅になった場合のVPNサーバーの負荷状況がどうなるか読めなかったため、サーバーのスペック増強も視野に入れて対応を進めました。

対応の流れ

通常の流れ

普段のVPNアカウントの発行までの流れは以下の通りです。

　VPNアカウントの発行依頼が基盤チームに届く
　申請書をもとに発行VPNアカウントを決定
　VPNサーバーにアカウントを登録
　接続情報を依頼者に共有
　登録済みアカウント一覧を更新

台風前日

届き続けるVPNアカウントの発行依頼

勤務開始時刻が過ぎたあたりから基盤チームに対してVPNアカウントの発行依頼が複数届き始めました。
また、この日は夏季休暇期間の中日ということもあり、運悪く基盤チームの人手も足りていませんでした。
普段であれば上記の流れに沿って作業を進めていきますが、この後いつまで依頼が届き続けるのかわからない中で待機し続けるとVPNアカウントの発行が間に合わない状況でした。
チームメンバー各々が他のタスクも抱えており、時間も限られているということで、状況整理も兼ねて一度チーム内で相談する時間を取りました。

対応方針決定

相談の結果、「依頼を待つのではなく、こちらから発行が必要なVPNアカウントのリストを関係各所に問い合わせよう」という結論でそれぞれ動き出しました。またセキュリティの観点から、発行希望のアカウントが永続利用か一時利用かについても確認しました。
慌てる場面もありましたが、関係各所の協力のおかげで、何とか発行が必要な方の情報を整理することができ、漏れなく対応を完了することができました。

まとめると以下のような流れです。

　VPNアカウントの発行依頼が基盤チームに届く
　台風接近による依頼が複数届き始めたため、関係各所にVPNアカウント新規発行希望者の確認を依頼
　確認の結果をもとにVPNアカウントを発行
　接続情報をまとめて各代表者に共有
　登録済みVPNアカウント一覧を更新

VPNサーバーのスペックアップ

チームでの相談の際、アカウント発行の件とは別に、サーバーのスペックアップが必要ではないかと話が上がりました。
普段出社している社員が一気に在宅勤務になるためです。

弊社では、SoftEther VPNを使用してVPN環境を提供しています。構成のポイントは以下の通りです。

　サーバー環境：AWS EC2インスタンス上にSoftEther VPNをインストールして構築。
　接続方式：L2TP/IPsecを使用し、WindowsやMacの標準VPNクライアントから接続。OpenVPNもサポート。
　トラフィックルーティング：すべてのトラフィックがVPN経由となるフルトンネル*1を採用。

このような構成で運用しているため、特に勤務開始時刻前後はEC2のCPU負荷が急上昇し、スペックが足りていないVPNサーバーにおいてはダウンの可能性も考えられました。
そこで各VPNサーバーのインスタンスタイプ、登録済みアカウント数、普段のCPUの状況等を改めて確認した結果、VPNサーバーのスペックを上げることになりました。
基本的に社員の勤務開始は午前8時～9時に集中するため、事前にVPNサーバーメンテナンスの周知をしたうえで、台風当日の早朝7時からスペックアップ作業を実施しました。

※インスタンスタイプの変更は互換性を考慮する必要があるため、事前に確認が必要です。 aws.amazon.com

台風が過ぎ去って

結果的には何事もなく、ホッとしました。
ただ、台風当日の早朝にスペックを上げたサーバーの1つは、CPU使用率が70％付近になっている時間帯もあり、スペックを上げていなかったらと思うとゾッとします。
セキュリティの観点から、一時的に発行したアカウントは後日削除し、ようやく一件落着。

緊急対応での学び

今回の緊急対応で学んだことを以下にまとめます。

手薄な日の対応計画を見直す必要性
長期休暇等の事情で基盤チームの人数が少なくなることを見越し、VPNやメールサーバーなど業務の基盤となる部分については、より一層の知識共有が重要だと感じました。
すでに基本的な体制は整っていますが、手薄な日でも誰もが必要な対応を取れるよう、さらなるスムーズな対応を目指した体制強化が今後の課題だと改めて考えさせられました。
状況に応じた柔軟な対応の重要性
通常のフローにこだわらず、急な状況に合わせて柔軟に対応する重要性を実感しました。
今回は、事前にVPNアカウント未発行者を確認し、まとめて対応することで、効率よく処理できました。
緊急事態に備えたフローとリソースの整備の重要性
緊急時に即座に対応できるフローや専用のアカウント管理があれば、さらにスムーズに対応できたはずです。今後は、こうした状況に対応できるような準備を進めることが課題です。

これらを踏まえ、今後も迅速かつ効率的に対応できる体制を整備していきたいと思います。