メインコンテンツへスキップ

自分たちのチームに合ったVPNを探す

    こんにちは。InflabのDevOpsエンジニア、Goofyです!

    多くの方が使っているように、Inflabでもプライベートネットワーク内部のリソースへのアクセス管理のためにVPNを使っています。VPNの構築にはこれまでAWS Client VPNとFirezoneを使ってきましたが、現在はTailscaleを採用しています。

    本記事では、InflabでVPNツールを選ぶ際に考慮した基準と経験を共有したいと思います。

    VPNとは?

    VPN(Virtual Private Network、仮想プライベートネットワーク)は、公衆ネットワークを介してプライベートネットワークに安全にアクセスできるようにする技術です。VPNは暗号化された接続によってユーザーのデバイスとプライベートネットワーク間のデータを保護し、認証されたユーザーのトラフィックだけがプライベートネットワークにアクセスできるよう認可します。

    企業では、社内で使うリソースのセキュリティを守り、ネットワークへのアクセスを制御するためにVPNを使います。つまり、在宅勤務をしているときやカフェでインターネットを使うときでも、開発サーバーやDBに安全にアクセスできる環境を作ります。

    画像
    VPNの構造

    AWS Client VPN

    画像
    https://aws.amazon.com/vpn/client-vpn

    最初にVPNの構築に使ったのはAWS Client VPNでした。

    AWS Client VPNは、OpenVPNプロトコルをサポートするAWSのマネージドVPNサービスです。
    OpenVPNベースのVPNクライアントを使って、Amazon VPCのネットワークに接続できるようにします。

    AWS Client VPNを選んだ理由

    • AWS Client VPNはAWSのフルマネージドサービスです。OpenVPNサーバーへの攻撃に自分たちで対応する必要がなく、プロビジョニングやアップデートもAWSが行ってくれるので、管理の工数が少なく済みます。

    • AWS Client VPNの料金は、1時間あたりの料金と1時間あたりの接続料金の2種類で請求されます。固定料金が低いので、安く使うことができました。

    • また、ユーザー認証にGoogle Workspaceなどが対応しているSAMLによるSSOを使えるので、手軽に構築できました。

    物足りなかった点

    AWS Client VPNは1年間使いましたが、モバイルアプリやWebのQAが必要になってくると、モバイルクライアントがSAMLに対応していないことが不便になりました。モバイルでQAをしたりadminにアクセスしたりする機会が増えたため、モバイルでも認証できる別のVPNを探すことにしました。

    Firezone

    画像
    https://www.firezone.dev

    次に使ったのは、WireGuardプロトコルベースのオープンソースVPNであるFirezoneでした。

    Firezoneを選んだ理由

    • Firezone VPNは、モバイルブラウザでGoogle SSOを使ってログインした後、WireGuardアプリでVPNセッションを問題なく確立できました。

    • Hacker Newsで紹介されるなど、多くの人が関心を寄せているオープンソースプロジェクトだったので、コミュニティのサポートが期待できました。

    • さらに、速度とレイテンシーに優れているというメリットもありました。WireGuardは軽量な暗号化アルゴリズムとカーネルレベルの命令セットを活用しており、OpenVPNの3〜4倍の性能が出ます。Firezoneを使うことで、WireGuardの性能面でのメリットを簡単に享受できました。

    物足りなかった点

    Firezoneは2年間満足して使っていましたが、以下のような物足りない点がありました。

    オープンソースのサポート終了

    • 構築当時、Firezoneの最新バージョンは0.x系だったため、安定した1.x系が出るのを待っていました。ところが、Firezoneはバージョン0.7を境にクローズドソースへの移行と有料化の計画を発表しました。そのため、継続的な機能サポートやアップデートは期待しにくくなりました。

    セッションと権限

    • Firezone VPNを構築する際、ネットワーク環境のセキュリティを高めるためにprodとdevのVPNを分けました。本番環境に開発チームの誰もがアクセスできると、個人情報やセキュリティの問題が起こりかねません。そこで、prod環境には認可された人だけがアクセスできるようにしたのです。しかし、Firezoneでは細かい権限設定ができなかったため、devとprodのVPNをそれぞれ構成しました。

    画像
    VPNのdev・prod構成
    • セキュリティは向上しましたが、開発中に両方の環境へアクセスしたいときは、それぞれのVPNにデバイスを登録し、片方ずつオンにして切り替えなければなりませんでした。環境を切り替える手間をかけずに、認可されたユーザーだけがprodにアクセスできる。そんな条件を満たす、効率的な権限設定の方法が必要でした。

    • また、Firezone VPNはログインセッションが切れても、クライアント側では期限切れかどうかを確認できませんでした。VPNを有効にしても通信できないときは、FirezoneのWebページに再度アクセスしてログインし直し、セッションを再有効化する必要がありました。このように、セッションと権限の管理にちょっとした不便がありました。

    CloudFrontのスプリットトンネル

    • VPNの使用量が増えてきたので、不要なトラフィックを減らすためにスプリットトンネル機能を使おうとしました。スプリットトンネルとは、その名のとおり特定のIPアドレス範囲の通信だけをVPNに通し、それ以外は通常のインターネットに流すよう分離する仕組みです。

    • VPNを通す必要があるのは、開発・本番サーバーのVPCのIPアドレス範囲と、LB、CloudFrontにアクセスするときだけです。それ以外のトラフィックがVPNを通らないようにすれば、コストを削減できると考えました。

    • しかし、開発サーバーのCloudFrontへのトラフィックをスプリットトンネルの対象にするには、Amazon CloudFrontが使うIPアドレス範囲をまるごとVPNの範囲に追加する必要がありました。そうすると、開発サーバー以外へのトラフィックまでVPNを通る可能性があります。そのため、スプリットトンネルを使っても、不要なVPNトラフィックのコストが一部発生していました。

    Tailscale

    Firezoneの有料化をきっかけに、権限とセッションの管理、スプリットトンネルなど、細かな要件をまとめて満たせるソリューションを探しました。

    TailscaleとNetbird

    画像
    https://tailscale.com
    画像
    https://netbird.io

    検討の末に見つけた2つのソリューションが、TailscaleとNetbirdでした。TailscaleはSaaS製品で、NetbirdはBSD-3ライセンスのオープンソースです。両者は機能面でよく似ています。

    基本機能

    • どちらもFirezoneと同じく、WireGuardベースのVPNサービスです。

    • タグ単位、またはグループ単位で詳細な権限設定ができます。

    VPNサーバーの構造

    • AWS Client VPNとFirezoneは、中央にある1つのVPNサーバーに複数のクライアントが接続する構造だったのに対し、TailscaleとNetbirdは複数のクライアントをプライベートネットワークとしてまとめて構成する構造です。

    • 従来のVPNのように1つのクライアントをVPNサーバーとして使うこともできますし、接続されたクライアント同士が同じネットワークにつながっているかのようにプライベートIPで通信することもできます。状況に応じてさまざまな構成が可能です。

    ドメイン単位のスプリットトンネル

    • さらに、ドメイン単位でスプリットトンネルを設定できます。細かな実装は両者で少し異なりますが、ドメインによるスプリットトンネルは、VPNクライアントがDNSサーバーをプロキシすることで実現しています。大まかな流れは次のとおりです。

      1. VPNクライアントのインストール時に、DNSサーバーのプロキシが起動する。
        (DNSクエリがプロキシに向かうよう、/etc/resolv.confファイルの内容が自動的に書き換えられる。)

      2. VPNがDNSサーバーのプロキシのアドレスにDNSクエリを送る。

      3. プロキシが実際のDNSサーバーに問い合わせ、返ってきたIPをVPNの範囲に追加する。

    • ドメイン単位でVPNを通すかどうかを決められるので、CFのIPアドレス範囲をすべて許可しなくても、必要なドメインだけをVPNに通せます。定期的にDNSクエリをやり直して更新するので、対象のIPが変わっても動作します。

    Tailscaleを選んだ理由

    • Netbirdはオープンソースなので、サーバーのホスティング以外の費用がかからないというメリットがあります。しかし、ドメインベースのルーティング機能は最近(2024年6月初め)開発されたばかりで、社内でテストしたところ、iOSとAndroidのクライアントではまだ動作が不安定でした。

    • 一方Tailscaleは、さまざまなOSのクライアントでスプリットトンネルやセッション更新の機能がスムーズに動作しました。セッションの有効期限やアカウントごとの権限ポリシーも管理しやすいものでした。現時点では管理工数の少ないSaaSを使うほうがコスト効率が良いと判断し、Tailscaleを導入して運用しています。

    まとめ

    結論として、Inflabは社内リソースへのアクセス管理のために、AWS Client VPN → Firezone → TailscaleとVPNソリューションを発展させてきました。各段階では、以下の要件がどれだけ必要か、どれだけ満たせるかを考慮して判断してきました。

    1. ユーザー体験

      • すべてのOS(デスクトップ、モバイル)での安定した動作

      • SSOなど便利なアカウント認証方式のサポート

      • セッション更新や管理のしやすさ

    2. 管理

      • 運用・保守に必要なリソース

      • アップデートやセキュリティパッチの安定性

      • 細かなアクセス権限の管理機能

    3. 技術的な要件

      • スプリットトンネルとドメイン指定オプションに対応しているか

      • ネットワーク性能(速度とレイテンシー)

    入社後に取り組んだTailscaleのPoCを通じて、VPNソリューションを選ぶ際に考慮した点をまとめてみました。拙い記事ですが、何かしら参考になる知見をお届けできていれば幸いです。

    皆さんの環境でも、安全で効率的なVPNを構成できることを願っています。

    お読みいただき、ありがとうございました :)

    ※この記事は2024年10月31日に執筆されたものです。

    あなたへのおすすめ