こんにちは、IT 基盤部第三グループのジュンヤと申します。 前回 は、日本と中国の間の VPN 接続に発生した問題とその解決について紹介しました。あれから約1年が経とうとしていますが、今回も VPN がテーマです。そうです、偶然にもまたも VPN です。

DeNA の テレワーク状況

DeNA は6月19日現在、出社率がなんと5%！という、ほぼ全社テレワーク状態で稼働を続けています。この背景には、ごく短期間で、VPN 接続数が150から2500へと約16倍に急増した、という事実がありこの記事はその戦いの記録を綴ったものになります。(なお、5月の出社率は2%でした)

DeNA の VPN 構成

VPN とは Virtual Private Network の名の通り、仮想的な専用線(プライベートネットワーク)を構成する技術です。この VPN を使うことで自宅や外出先であっても安全に社内 LAN に接続している状態を得ることができます。24時間365日、システムを保守運用する IT 基盤部では必須のシステムであり、以前より重要なシステムとして位置付けられてきました。勿論、エンジニア以外でも VPN は利用することができ、平常時の接続数はピーク時で約150人ほどでした。過去形になっていることから分かる通り、この数字は4ヶ月前までの話です。

• Active Directory との親和性が非常に高く、VPN 利用の許可制御が楽。
• 主要なクライアントOS Windows / macOS の標準機能として組み込まれている VPN クライアントを利用できる。
• 維持コストが安い。

などがあげられます。特に3点目は大事な点で、よくある接続アカウント数によるライセンスフィーや、接続時間によるコスト増などとはほぼ無縁です。そのため、システム維持の予算作成などの見通しをたてることも比較的容易です。

突然始まった全社テレワークへの「静かなるカウントダウン」

DeNA では、部署によって違いはあるものの、以前からテレワークによる勤務が認められており、私が所属している IT 基盤部では、週2回までテレワークが許可されていました。部内ではこれを WFA (Work From Anywhere)と呼んでいますが、この制度の利用回数制限の撤廃が示されたのは1月下旬のことでした。

2020年2月全社テレワーク前夜。VPN サーバを増強して備える

それまでの平常時の接続ユーザ数であればサーバリソースに全く問題はありませんでした。しかし、2月に入ってからは横浜港に停泊したクルーズ船での感染拡大が報じられ、2月中旬には、IT 基盤部が所属するシステム本部全体でも原則テレワークという方針が決まり、VPN 接続数が大幅に増えることは確実な状況となりました。それでも、2月下旬あたりではまだテレワーク体制に移行していない部署も多く、接続数のピークは300前後で、サーバリソースにはまだまだ余裕がありました。しかし、全社員約3000人が VPN 接続することが近い将来に発生する可能性に備え、VPN サーバを数台増設する対応をとりました。

「VPN が遅い」「Zoom が切断される」等の問い合わせが続々と…

3月からはテレワーク体制に移行する部署が徐々に増えていくにつれ、3月26日時点で接続ピーク数は800となりましたが、まだまだリソース的には余裕がある状態でした。しかし、翌27日に接続数1100を超えたあたりで、ユーザから、VPN の通信速度の劣化等についての問い合わせが寄せられるようになりました。

問い合わせをまとめてみると、おおよそ以下のような内容でした。

• VPN コネクションは問題なく張れる。
• Zoom を利用していると切断されることが多い。
• 社内のサイトは問題ないが、外部のサイトへアクセスすると遅い。

ポイントは社内サイトは遅くない、すなわち、社内ネットワークから外へ出ていく途中にボトルネックがあるということになります。結論をいうと、今回の通信劣化の原因は VPN 接続セッション数の増加による「NAT テーブルの枯渇」であり、DeNA が採用している VPN 接続方式のデメリットが表面化したことによるものでした。

NAT テーブル枯渇問題の解消のために

通常、社内ネットワークに接続したクライアント PC はプライベート IP アドレスを持ち、インターネットへアクセスする際に、プライベート IP アドレスをグローバル IP アドレスに変換します。一般的にこれを NAT (Network Address Translation)といいますが、今回のような場面では、あわせて Port 番号も変換される NAPT (Network Address Port Translation)が利用されます。Port 数は有限のため、多数のクライアントPC が接続すると、変換する Port 数が枯渇し通信劣化につながる、というわけです。

この問題が発生した場合、解決する方法としては変換されるグローバル IP アドレスを増やす（N 対 1なら N 対 2以上にする）ことが最も簡単です。ただし、グローバル IP アドレスを追加する前に、社内周知とリードタイムが必要です。なぜなら、VPN 接続環境から利用できるサイト等の中には IP アドレスによるアクセス制限をしているものも多く、接続先システムの許可リストに、追加するグローバル IP アドレスを予め追加してもらう必要があるからです。このためのリードタイムをある程度とる必要があり、グローバル IP アドレスを増やすまでの間、VPN 通信劣化の問題をなんとか改善する必要がでてきました。

フルトンネリング方式 vs スプリットトンネリング方式

前述した、「DeNA が採用している VPN 接続方式のデメリットが表面化してしまった」とはどういうことなのか、もう少し詳しく見ていきます。VPN 接続の方式は2つあります。あらためて両方式の特徴をまとめると以下のようになります。

DeNA では①を採用していたため、すべての通信が VPN 接続を経由する形になり、VPN 利用者増加と比例して変換 Port 数も増加し、Port 枯渇につながってしまいました。②に変更すれば、Port 枯渇は緩和されますが、IP によるアクセス制限をしているシステムをすべてリストアップし、これらに対して VPN へのルーティングを記載する必要があります。しかし、この作業にはヒアリングに工数がかかること、そして十中八九、漏れがでてくることは避けられないことから採用を見送りました。

では、①の方式のまま、Port 枯渇を軽減するにはどうすればよいか？検討をした結果、VPN を通す必要がないトラフィックは、ユーザのインターネット回線から直接出ていく構成にすることにしました。要するに、VPN 通信が必要な宛先に対してスタティックルーティングを書く「スプリットトンネリング方式」とは逆の考え方になります。VPN を通らず直接通信をさせることは、VPN サーバからパブリックへの通信の絶対量を減らすことを意味します。つまり NAT テーブルの利用量を減らす効果があるというわけです。そして、この方式を採用するにあたって次に検討すべきポイントは、どうすれば極力ユーザに手間をかけさせずに実現できるか、になります。

Jamf & LanScope Cat でスクリプト配布、「逆」スプリットトンネリング方式が功を奏す

実は、社内では、すでに自身でルーティングを追加して VPN を通さない設定をしているエンジニアなどがチラホラ出てきていました。しかし、ユーザになんらかの追加手順を強いるようでは物事はうまくいきません。ユーザの手をわずらわせることなく、約3000台のクライアントを設定するには以下の点を考える必要があります。

1. VPN 外にスプリットする宛先の決定
2. ルーティングを追加するスクリプトの準備
3. クライアント PC にスクリプトを配布する方法

1.については、テレワークにより利用が活発になっていた Zoom を始め、全社で利用している社外のサイトを洗い出しました。また、将来的に対象が増減する可能性も考慮しました。

2.については、調査をしてみると macOS の VPN クライアントは、接続時に任意のスクリプトを実行できることがわかりました。Windows でも VPN 接続のタイミングで同様にスクリプトを実行できることもわかりました。早速フルトンネル方式のクライアントの振る舞いをかえるスクリプトを作成しテストを行うと、期待通りに指定した宛先の通信を VPN の外に逃すことができました。

3.については、従前より DeNA では端末管理に Mac 端末では Jamf 、Windows 端末には LanScope Cat を利用しています。これら端末管理ツールの導入や利用についてはまた別の機会に紹介するとして、Jamf と LanScope Cat を使ってこのスクリプトを利用者の手を借りることなく展開しました。これらのツールはスクリプトの改良版を展開する時にも威力を発揮しました。社外にある端末であっても管理できる仕組みを導入していたことが功を奏したと言えます。

このようにユーザの VPN 接続体験、つまり「 VPN に接続するだけ」を変えることなく、「逆」スプリットトンネリング方式を展開し、グローバル IP アドレスを増やすまでの通信劣化を抑えることができました。グローバル IP アドレスを増やした後も VPN 通信量の負荷軽減を行うためこのスクリプトは継続して使用しています。

グローバル IP アドレス追加、そして終息へ

4月2日、ようやくグローバル IP アドレスが追加され、より安定した VPN 接続環境が整いました。そしてこの日には、ピーク時約1700ユーザが VPN を利用し、その後約2500ユーザまで利用者は増加していきました。6月1日以降からは約2000前後で推移しつつ、出社率5%という DeNA のテレワーク環境を支えています。

働き方の多様化、ゼロトラストへの道

ここまで、新型コロナウイルスによる、急激なテレワーク体制への移行中に発生した VPN にかかわる問題とその解決について振り返ってみました。部署を越えたシームレスな連携と個々のエンジニアの迅速な対応があって、影響を最小限に抑えることができました。そして今日まで、大きなトラブルもなく VPN サービスを提供できています。
この劇的な社会の変化を受け入れざるを得なくなってから数ヶ月が経ち、緊急事態宣言が解除となった現在でも、継続してテレワークを推奨する企業も少なくないと思います。 オフィス外で働くことが当たり前となった今、VPN のみでは限界も見え隠れします。ゼロトラストへの道も真剣に考えるタイミングにあるのかもしれません。
そして、次回の blog は VPN 以外のテーマであることを願っています。