社内で利用している Client VPN を Twingate に移行した話
目次
背景
IPアドレス制限を持った対向先に接続する際に、 VPNを利用して固定IPアドレスからの接続を行っていました。
以下のような AWS Client VPN + NAT Gateway の構成です。
いくつか課題を持った状態で運用(後述)していましたが、Twingate というサービスの特徴・利点が要望に合致するため移行を試みました。
Twingate
Twingate の特徴などは公式サイト(Twingate) を参照ください。
検討
- 利用者数・頻度が少ないためVPN構成は過剰でしたが、ユーザ数課金である Twingate は小さく始められます。
- (当然ながら、利用規模によっては VPN の方が安価になる状況も有り得ます。)
- 利用者側はアプリケーションインストールとログインだけで接続できるようになります。
- Client VPN で利用していた証明書の配布・管理などが不要になります。
- リソースレベルのスプリットトンネリングが行えます。
- Client VPN Endpoint の split-tunnelI 設定や ProxyServer を経由することで対処していましたが、それらも不要になり、利用者側も特に意識せず利用できます。
料金
プランによる機能の違いについては Pricing を参照ください。
SSO( Identity Providers) や Group (Groups) を利用したアクセス制御は Business プラン以上の機能です。
アクティブユーザ数の考え方や、ユーザ数超過時のよくある質問などは、 Subscription management にまとまっています。
Twingate を経由しリソースにアクセスして初めてアクティブユーザとしてカウントされるとのことです。
例えば、Idp連携で同期を行った際に Twingate ユーザ数としては増加しても、リソースへのアクセスが無ければ課金対象にはなりません。
導入
Connector
Twingate 側の設定以外で用意するリソースは Connector だけです。
プラットフォーム別にドキュメントも用意されており、特に躓く事無く作成できました。
ベストプラクティスに記載がある通り、2つ以上で冗長構成を取るのが推奨のようです。
特別設定せずに複数台用意すれば負荷分散、冗長化されます。
公式AMIを利用し、AWS 上に EC2 インスタンスを作成しました。
こんな感じの構成です。(NAT Gatewayは他の利用用途との併用なので使い回しています。)
異常時は新規インスタンスを立ち上げる事で自動復旧できるよう、常時1台起動させておく Auto Scaling Group 2つの構成にしています。
インバウンドの接続は不要なので通信許可もしていません。
Terraform Provider
Connector の構築は、公式の Twingate Provider を利用し、Terraform でコード管理しています。
以下のように、現時点ではいくつか対応していない機能がありましたが、Connector や Resource の作成は問題無く行えます。
- Remote Network の “Location” 設定
- User の Group 割当
- Connector の “Status emails” 設定
これらは頻繁に変更する物でもないので WebUI 上で設定変更しました。
Client
証明書のインストールなども無く、
各プラットフォームのクライアントをダウンロード・インストールして、
network 名 (URL の https://xxx.twingate.com/ 部分) を入力するだけです。
モバイルアプリ(iOS, Android) もあります。
まだ未検証ですが、CI/CD 向けに Headless Clients も公開されています。
その他
Connector の冗長化と監視について
前述の通り、Connector を複数構成しておくことで冗長化されます。
Twingate 上で Connector の HealthCheck が行われており、異常があればUI上のStatusがNGになります。
また、”Status emails” を有効化しておくと管理者へのメール(Connector offline / Connector back online)通知が発生します。
ここで言う管理者は、Teams/Admins に属するユーザとなるようです。
また、Connector のバージョンが古い状態のまま稼働させていると、更新を促すメール(Connector upgrade required)通知が発生します。
忘れずに定期的に更新するよう設定を入れておきます。
サービス障害について
Connector 障害の他に起こりうる障害として、 Twingate サービス自体の障害があります。
Twingate を経由する仕組みなので、Twingate側に何か異常があると当然繋がりません。
ステータスページやTwitterアカウントが公開されているのでそちらで確認します。
余談ですが、検証していた期間中に比較的規模の大きい障害が発生してました。
幸いVPNと並行稼動期間でしたので大きな影響はなかったのですが、この時は4時間程利用できない状態でした。
また、 GCP を利用してホストしているとのことですので GCP 側障害に引き摺られる可能性もありそうです。
まとめ
利用者数によるサービスの利用料が掛かりますが、VPNサービスを利用する事を考えると比較的安価だと思います。
宣伝文句にもある通り、導入はとても簡単でした。
管理者の負荷が減り、また、利用者は設定などに迷うこと無く利用開始できるのは凄く良いと思いました。
