ふと技術系の記事を漁っていると面白そうな物を見つけました。
「Twingate」と呼ばれるものです。
リモートワークが増えてきた中、VPNを使って社内イントラに接続して何かしら作業を行う機会が多くなった人も多いと思いますが、TwingateはこのVPNに代わるものとして作られたようです。VPNで指摘されている問題を解決する為に生まれたとの事で、試しに触ってみました。
注意点
ここではTwingateの仕組みやアーキテクチャの解説は行いません。ドキュメントの参照をお願いします。
https://docs.twingate.com/docs
必要と思ったら注釈程度に説明を入れていこうと思います。
やる事
- ドキュメントを参考に実際に環境を構築し、どのような感じなのかを確かめる。
- 導入の難易度や管理のしやすさを評価する。
構築は以下の手順に沿って進めます。
https://docs.twingate.com/docs/twingate-configuration
構成
まずは一番シンプルに、AWS上のインスタンスにリモートで接続するのをやってみようと思います。インターネットに接続されていないプライベートサブネット上にサーバーを構築し、そこにsshで接続するという感じです。
アカウント作成とリモートネットワーク追加
何よりTwingateアカウントを作ります。難なく作れると思います。
「リモートネットワーク」を追加せよと言われるので、AWSを設定します。ですがこれは後から追加できるのと、「AWS」だと複数入れた場合に管理が大変なので、後から追加したほうが良さそうです。実際にチュートリアルでも、「名前を変更する事を推奨」となっていました。
今回は「AWSProductionVPC」を追加しました。またリソースは空です。
コネクタの作成
次に「コネクタ」を設定します。
「コネクタ」とはリモートネットワーク内で実行されるTwingateソフトウェアコンポーネントの1つです。プライベートリソース宛てのトラフィックはすべてこの「コネクタ」を通過し、リソースから見ればすべて「コネクタ」から発信されるように見えます。コンポーネント自体はDockerコンテナです。
作成したリモートネットワークをクリックし、「コネクタ」の追加ボタンを押します。そして「Generate Tokens」をクリックするとコマンドが発行されるので、それをコピーします。
AWSにコネクタ用インスタンスを作成します。以下にコネクタ用のベストプラクティスがあるので参考にします。t3a.microを使います。
https://docs.twingate.com/docs/connector-best-practices
これは後で熟読ですね。
コネクタにはアウトバウンドのインターネットアクセスが必要との事なので、コネクタだけはパブリックサブネットに配置する必要があります。AmazonLinux2環境においてDockerをセットアップしないといけないので以下を参考に設定
https://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/docker-basics.html
セッションマネージャーは便利だなぁ！！
インスタンスを起動してDockerが使えるようになったら先程発行したコマンドを実行します。
接続ができるようになると以下のように差込プラグのマークが緑になります。
リソースの作成
次に「リソース」を作成します。リソースとは宛先のサーバー、またはアプリケーションを指します。
今回の場合プライベートサブネットに建てたもう一つのサーバーを指します。
Twingate画面の「Add Resource」よりリソースを追加します。
ここで指定したアドレスの解決はリモートネットワーク上のコネクタから実行されます。なのでローカルIPまたはプライベードDNSを入力します。
これでリソース追加完了です。
クライアントのインストールと接続
クライアントをインストールします。以下からダウンロードできます。
インストールして起動するとTwingateのURLを入力する画面が出てくるので入力します。
するとログイン画面に飛ばされるのでログインします。成功するとアプリが常駐します。
接続してみる
Twingateへの接続ができている事が確認できたら、あとは普通にssh等でサーバーへの接続コマンドを実行するだけです。
ちょっとハマったのは、リソース追加時に指定したアドレスでしか接続できない所です。ここでプライベードDNSを指定した場合はプライベードDNSを使ってssh接続はできるのですが、ローカルIPだとできません。
その逆も同じです。 私はリソースのアドレスにはプライベードDNSを指定していて、接続にローカルIPを使おうとしていて全然繋がらず、あーだこーだしてしまいました。
まとめ
- セットアップはめっちゃ簡単。
- コネクタ自体にインバウンドを許可していないのでセキュア。
- リソースの追加も簡単。
- SSOによるユーザー管理で管理コストも低い。
これは非常に期待できます。
ちなみにTwingateの目玉機能として、ユーザーやグループ単位でアクセスできるリソースの制御ができるのですが、無料版であるStarterだと使えなかったので今回は試すことができませんでした。なので次はトライアル期間を利用してアクセス制御もやってみようと思います。
この記事を書いた後もしばらく使っていて思ったのが、クラウドリソースよりオンプレリソース管理の方が向いてる気がしました。
ビジネスプランでも管理できるリモートネットワークの数が10個となっています。1つのAWSアカウント＝1プロダクトで管理している場合、10アカウントで終了です。本格的にAWSを使って何かソリューションを提供しているととても足りません。
あとわざわざこれで管理しなくてもIAMで管理すればいいですし。
なので、そこまでネットワークの数が多くなく、リソースへのアクセス制御を構築するのが難しいオンプレ環境に構築したリソースの管理には非常にマッチする気がします。