VPN との終わりなき戦い　〜新VPN導入編〜

はじめに

こんにちは、IT戦略部システム基盤グループの酒井と申します。

システム基盤グループは2023年4月にIT基盤部からIT戦略部に所属部門が代わり、社内システムのインフラやGithubやJira/Confluenceなどの運用を担当しています。

このタイトルに見覚えがある方は熱心なDeNA Engineering blogの読者だと思います。私の上長が過去に同じタイトルでblog投稿をしていました。まだ見ていない方は今回の内容とも関連するため、以下からご覧ください！

今回もタイトル通りVPNに関するお話となります。

DeNAのリモートワークの状況

本題に入る前に弊社のリモートワークの状況をご説明します。

DeNAではコロナが落ち着いてからもハイブリッドワークを継続しており、遠方居住者の採用も積極的に行なっていることから高いリモートワーク率となっています。

コロナの5類移行後、オフラインでのイベントや打ち合わせも増えつつありますが、私自身も月2回程度の出社となっています。（出社が全くない月もあります。）

VPNも社内システムへのアクセスに必須なため、リモートワークをしている全社員が常に利用しています。前回の戦いから早いもので2年が経過しようとしていますが環境の変化も早く、当時は最適であった構成も徐々に問題が発生するようになってきました。

今回の戦い

問題は利用者からの問い合わせ増加という形で顕在化してきました。

VPNの問題は業務を行うのに影響が大きく、早めに対策を講じる方針となり「VPN品質改善プロジェクト」が始動する事となりました。

まずは既に我々が認識している問題を含めてどういった問題があるか、どの程度発生して影響がどれほどあるかを把握するために、VPNに対する満足度を確認するアンケートを実施しました。

約670件ほどの回答をいただき、概ね以下のような問題である事が確認できました。

大量データ通信時で切断が発生してしまう
勝手に切断されてしまう事がある
通信速度が著しく遅い時がある

問題を申告している方は高い頻度（週に数回や多い方で毎日）で事象が発生していて、業務に支障が出ているというコメントがありました。

また、自宅のインターネット回線でプロバイダから払い出されるIPアドレスがIPv6になり、既存VPNだと全く繋がらないという回答も存在しました。これは弊社のVPNの仕組み上、既知の問題であり、問い合わせも増加傾向でした。

ただ、アンケート回答を見ると大半の利用者は既存VPNでも大きな支障はなく、満足度も高い事が分かりました。 VPNの全面更改はコスト面でも準備の面でも慎重な検討が必要になるため、既存VPNの満足度も加味して「問題がある一部利用者へ新VPN提供」というスコープに決定しました。

製品選定

次にいくつかの製品を調査して、机上で比較検討していきます。検討のポイントとして特に重要視したのが以下の点です。

認証やセキュリティ
利用者の設定負荷
Outbound IPの固定
安定性

さらに弊社では社内システムをクラウドへ全移行している事もあり、物理機器購入が必要なものは対象外としています。

調査対象は多数ありましたが、必須要件にマッチしたもののみをピックアップして、そこから更に詳細な内容を確認する方法で比較検討を進めた結果、最終的な候補に残ったのは4製品でした。

4製品すべてのPoCを行うのは時間や工数的にも現実的ではないので優先度を決めて順次、実施していく事とします。 Cloudflare社のZero Trustから行う事になりましたが、結果的にPoCはこの製品のみとなり導入が決定しました。

導入理由

導入理由としては認識している問題が解決できることは当然ですが、上で挙げた重要視した点についてご説明します。

認証やセキュリティ

Oktaと連携ができ、ユーザー認証やプロビジョニング、グループ情報をもとにした細かいアクセス制御も行えます。

端末シリアル番号の登録とポリシーの組み合わせで私物端末での利用を制限できた事も非常に大きな理由です。（弊社は資産管理に ServiceNowを活用しているためシリアル番号取得も容易でした。）

私物端末で社内ネットワークにアクセスできてしまうとセキュリティ面に大きなリスクになるのはご理解いただけると思います。

利用者の設定負荷

MDMで設定を配布する事もでき、クライアントのインストール自動化が可能です。インストール時にOktaでのユーザー認証を行えば、すぐに利用できます。接続は専用クライアント（WARP）のスライダーをクリックするだけのシンプルなつくりで分かりやすいクライアントインターフェースになっています。

Outbound IPの固定

IP固定化も追加オプションとなりましたが対応しています。弊社は多数の会社と協業させていただいており、協業先のシステム利用時にグローバルIPによって許可をしてただく事が多いため、こちらも外せない要件でした。追加費用は掛かってしまいますが、IP固定化のためにAWS上にインスタンスを立て、経由させるよりもコストと運用面でメリットの方が大きいと考えました。利用者が増えた場合の拡張性からも追加オプションを利用する事としました。

安定性

PoC期間中に目立った障害等もなく、試用していたユーザーからも不満の声は一切あがってきませんでした。有償プランであれば稼働率100%保証のSLAとなっており、Cloudflare社のサービスに対する自信が感じられます。

また余談ですが、PoC前後でもCloudflare社の担当営業や担当SEの方々が常にスピーディーに対応いただき、とても信頼でき導入に値すると判断できました。

導入後の構成

導入後の構成は以下となります。（簡略化しているのでイメージだけでも・・・）

既存VPN（JP-VPN）と共存させ、他環境の設定変更を最小限にする形で導入しました。

既存VPNは原則、AWS上にあるVPNサーバーを経由してインターネットに出ていくため、データ転送料が発生していました。 Zero Trustではプライベートネットワークへの通信のみAWS環境に向けており、インターネットへの通信はCloudflare社のネットワークから直接出ていくので「データ転送料の削減」も期待できます。

導入時に解決した事

導入にあたっていくつか解決した問題も参考までにご紹介します。導入を検討している方のお役に立てば幸いです。

IPv6通信の弊害

クライアントとCloudflare間はIPv6での通信が可能になり、既存VPNに接続できない問題の回避策となりました。しかし、いくつかのシステムでIPv6で通信可能だがアクセス制御（許可リスト）はIPv4にしか対応していないものがある事が発覚しました。デフォルトだとIPv6で通信してしまい、許可リストに登録がないIPv6通信はブロックされ、アクセスできません。

この問題は特定ドメインのみIPv6通信をブロックするポリシーを作成して解決しました。以下のように指定しています。（対象ドメインはリストに登録して、そのリストを参照するようにしています。）

NATポート枯渇対策

NATポートの枯渇に対しては前回、前々回の反省を踏まえ、かなり慎重に調査しました。上記の構成図の通り、インターネット通信は追加オプションの固定IPが使用されます。 1固定IPあたりのポート数上限があり、利用者が増えた場合の拡張性は考慮済みでしたが、そもそもポート枯渇を検知する方法が存在しませんでした。

そこでログの外部転送機能を利用し、転送したログを独自集計する事でポート利用状況を確認できるようにしました。集計には「Zero Trust Network Session Logs」を利用していますが以下画面のように他のログも転送設定をしています。