一休.com Advent Calendar 2025

Tailscaleを社内VPNとして採用できるかという観点で試してみた

Last updated at 2025-12-10Posted at 2025-12-09

💻 TailscaleというVPNを試してみた

この記事は一休.com Advent Calendar 2025の6日目の記事です。

一休の情シスで社内ネットワークを担当している出張です。この記事ではTailscaleという製品についてお話ししたいと思います。

📌 はじめに

皆さん、社内のVPNは何を利用していますか？

オンプレ機器、パブリッククラウド上のホスティング、クラウドサービス、各社の提供するサービスなど、様々な選択肢があると思います。

今回はその中でも、TailscaleというSaaSで提供されるVPNについてご紹介をします。

📜 目次

Tailscaleとは (Tailscaleの特徴と仕組み)
VPN(Tailscale)に求めるもの (一休の要件)
Tailscaleの構築 (管理画面設定とSubnet Router構築)
Tailscaleを検証して良かった点
契約・費用面の話
構築のTips (ECS、Apps、ACLの自動承認)

1. Tailscaleとは

Tailscaleはカナダの企業が提供するVPNサービスです。

従来の一般的なVPNと大きく異なると感じたのは以下の点です。

ピアツーピアに主軸を置いたネットワークトポロジを構築する
外部に公開されたエンドポイントを持たない

1-1. ピアツーピアに主軸を置いたネットワークトポロジを構築する

Tailscaleはテナントを作成すると、テナント毎に閉じたテールネットと呼ばれる専用空間を作成します。

この空間は専用ドメインを持ち、テールネットに参加したデバイスは自動的に「ホスト名＋専用ドメイン」と「100.64.0.0/10のIPアドレス」が付与されます。そしてTailscaleはテールネット内の名前やIPアドレスを使ってピアツーピアの通信を行います。

従来のVPNは既存の社内ネットワークに接続するものでしたが、Tailscaleは相互に通信できるネットワークそのものを作成します。これが最大の特徴だと思います。

【Tailscaleのネットワークトポロジ】

Tailscaleはピアツーピアに主軸を置いているため、通信をするマシンすべてにTailscaleのクライアントソフトがインストールされる前提となります。しかし、オフィスネットワークであればサーバやDBなども存在するため、全てのマシンにTailscaleを導入することは非現実的です。

💡 Subnet Router

全てのマシンにクライアントソフトを導入することが難しい環境のために、TailscaleにはSubnet Routerという機能があります。

これはTailscaleの通信を中継してくれるプロキシのような存在です。Subnet RouterにTailscaleが導入されていれば、Tailscaleがインストールされていない社内マシンとも通信が可能になります。

【Subnet Routerを利用した通信の仕組み】

1-2. 外部に公開されたエンドポイントを持たない

従来のVPNは自宅やオフィス外から接続するため、インターネットに公開されたIPアドレス/FQDNが必要でした。しかし、Tialscaleはこれが必要ありません。

接続先/元マシンそれぞれがクラウド上のTailscaleサーバにアクセスし、IPアドレス/ポート番号を仲介してもらうことでVPN接続を行います。

【NAT Traversalによる接続の仕組み】

昨今、VPNを狙われるサイバー攻撃が多いため、攻撃面を減らせるという意味で非常に良い対策になると考えています。

Tailscale社自体が攻撃された場合どうするのか？という疑問もあるかと思いますが、個人的には「自社のVPNで問題が発生する確率」の方が高いと思っています。

この点は会社やエンジニアの考え方、社内の構成・体制で変わってくるので、各社にあった方式を検討されると良いかと思います。

具体的な仕組みについては、Tailscale公式サイトの解説をご覧ください。

🔗 How NAT traversal works (Tailscale公式ブログ)

2. VPN(Tailscale)に求めるもの

一休としてTailscale(VPN)に求める要件は以下です。

EntraIDを使った認証ができること
端末認証が行えること
VPN経由で指定したネットワークサブネットにアクセスできること
VPN経由で指定したFQDNにアクセスできること
DNSサフィックスを指定できること
ユーザ単位でACLを設定できること
各ユーザのアクセスログが取得できること
サーバを仮想マシン、可能であればコンテナイメージで運用できること

6.ACLと7.アクセスログはスタータープランでは実現できず、上位のプレミアムプランにする必要がありましたが、Tailscaleは上記の要件をほぼ満たすことができました。

これならば社内VPNとして利用できるだろうと思い、いざ構築へ！

3. Tailscaleの構築

今回は以下の環境を構築しました。

ADで社内ドメインの名前解決をする
Subnet Router (中継サーバ)で社内の各セグメントと通信をできるようにする
Subnet RouterはECSを使い、管理の手間を省く
ついでに特定FQDN宛の通信もTailscale経由させたい

【構築した環境のイメージ図】

3-1. Tailscale 管理画面の設定

3-1-1. Tailscaleの登録

公式サイトからTailscaleを開通します。今回は自社のEntraIDアカウントで作成しました。

ついでにEntraIDでエンタープライズアプリケーションを作成し、MFAのアクセスポリシーを付与しました。これでTailscaleで認証をする時にMFAが求められるようになります。

3-1-2. Settings(基本設定)

「Settings」タブから基本的な設定を実施します。従来のVPN機器と比べると設定項目は少ない印象です。

設定項目	内容	理由/補足
User Approval	ユーザ接続時に管理者の承認を必須にする (デフォルトON)	端末認証のため有効にしました。
Device Approval	マシン接続時に管理者の承認を必須にする (デフォルトON)	端末認証のため有効にしました。
Key Expiry	Tailscale接続マシンのタイムアウト	お好みで設定。
Auto-update Tailscale	クライアントアプリの自動更新	有効化しました。弊害はほぼありませんでした。
Trust credentials	ECS用のキー発行に使用	Subnet RouterをDockerイメージで構築する際に利用しました。

3-1-3. DNS

TailscaleにはMagicDNSという機能があり、テールネットに参加したマシンはこのMagicDNSに向かってDNSリクエストを送ります。

Global nameservers: 「Add nameserver」からDNSを指定します。（今回は検証のため8.8.8.8を指定）
Split DNS: 宛先が特定ドメインの場合、指定したDNSで名前解決をする設定です。社内ドメインがインターネット上で名前解決できない時に有効です。
- 例: 宛先がikyu.comの場合、社内DNSを参照する。
Search Domains (DNSサフィックス): いわゆるDNSサフィックスを指定できます。AD環境などホスト名だけでアクセスしている場合、これを設定しないと通信できない事象が発生したので注意が必要です。

3-1-4. Access Control (ACL)

公式ドキュメントを参考に、各社に合わせた設定を行ってください。

3-1-5. Apps (FQDN単位の通信制御)

特定FQDN宛の通信をTailscale経由させたい、という要件を実現する機能です。

「Add app」から対象FQDNを指定するだけで、指定したFQDN宛の通信がSubnet Router宛になります。

【メリット】

送信元IPアドレス制限があるサイトに対して、Subnet RouterのIPアドレス（NAT Gateway経由など）でアクセスさせることができます。

従来のVPNのようにIPアドレス単位ではなく、FQDN単位でスプリットトンネルが設定できます。

ただし、これを行うためにはSubnet Routerで動作するTailscaleプロセスでオプションを付与する必要があります。詳しい方法後述。

3-2. Subnet Router (中継サーバ)の構築

中継サーバの構築は、「LinuxマシンにTailscaleをインストールし、専用オプションを付与して起動する」という手順になります。

手順は公式サイトに詳しく載っています。

🔗 Subnet Routers · Tailscale KB

【起動コマンド例】 (※ネットワークセグメントは環境に合わせてください)

sudo tailscale up \
  --accept-routes \
  --advertise-routes=10.0.0.0/8,172.16.0.0/16,192.168.0.0/16 \
  --hostname=subnetrouter \
  --advertise-connector \
  --advertise-tags=tag:connector

4. Tailscaleを検証した結果…

結果としてTailscaleは十分に社内VPNとして利用できることがわかりました。

私の他にも複数名のエンジニアに試してもらいましたが、問題なく業務が行えました

私の所感によるTailscaleで良いと思った点は以下の通りです。

設定が非常に簡素: VPN機器ではなくSaaSのため、導入・運用負荷が低い
ストレスからの解放: PC起動後自動で接続するため、都度VPN接続する手間がない
高速な通信: WireGuardというUDPベースのプロトコルを利用しているため、非常に高速
セキュリティ向上: 外部に公開されたエンドポイント(グローバルIP+FQDN)がないため、外部から狙われづらい
DevOps連携: GitHub ActionsなどのCI/CDに組み込み、社内DBへのアクセスなども可能

従来のVPN構築は、機器の調達、ネットワーク設定、認証設定、証明書対応、クライアントソフト配布、そして運用...と非常に面倒な作業が必要でした。Tailscaleの場合、このほとんどから解放されるため、VPNで悩んでいるエンジニアの方は、一度検討してみることをお勧めします。

5. 契約・費用面の話

Tailscaleの料金はあらかじめプランで決められています。

🔗 Tailscale Pricing

リモートアクセス手段として使いたいだけであれば**Starter ($6/月)**で十分です。
ただし、以下の点まで考えたい場合はPremium以上をお勧めします。
- 通信ログを取得したい
- ユーザ毎にACLを設定したい
- SCIM連携したい

なお、Tailscaleは利用数が100名を超えるとディスカウントを受けることができるため、この辺りは営業にご連絡ください。

6. 構築のTips

6-1. ECSの構築

オンプレもEC2インスタンスも面倒を見たくないという理由から、Subnet RouterをECSで構築しました。Tailscaleは公式がDockerイメージを提供しているため、簡単に構築ができるのでお勧めです。

基本的には必要なパラメータを環境変数で与えるだけです。

ECS構築時の主なTips

TS_AUTHKEY (認証キー):
- デバイス認証を有効にしている場合、ECSでデプロイされたSubnet Routerも管理者の承認が必要です。これを自動化するため、Auth Keyを使います。
- Settings → Trust Credentialsからキーを発行します。（Personal Settingsからのキーは最大90日で有効期限が短い）
- キーの最後に**?preauthorized=true**をつけることを推奨します。
  - これはマシンにエフェメラルの属性を付与するオプションで、ECSのタスクが終了するとTailscale上のマシンも自動で削除されます。管理上、古いマシンが残り続けるのを防げます。なぜか専用の名前がなく、認証キーに?で繋ぐ形で引き渡します。
TS_HOSTNAME: 任意の名前を付けます。
TS_ROUTES: 中継サーバでアクセスしたい社内セグメントをカンマ区切りで指定します。
TS_EXTRA_ARGS: 公式で環境変数が用意されていないオプション（例: --advertise-connector）を付与する場合、すべてこの環境変数に半角スペース区切りで指定します。

Tailscaleの中継サーバは基本1台のみをおすすめします。

2台にすると自動で冗長化が行えるのですが、同じ宛先ネットワークに対してはラウンドロビンによるバランシングがされるような挙動になります。

Webアクセス程度であれば問題なかったのですが、SSH接続は行えませんでした。

ECS タスク定義の画面

6-2. Appsと自動承認の設定

Appsの機能

Appsは指定したFQDN宛の通信をSubnet Router経由でアクセスすることができる機能です。VPNのスプリットトンネルと言えばIPアドレス単位でしか宛先を指定することができなかったですが、TailscaleはFQDN単位で指定することができます。

さらにSunnetRouter→NAT-Gatewayと経由させることで、インターネット上のFQDNに対しても通信ができます。これにより送信元IPアドレス制限がかかったサイト宛の通信にNAT-Gateway経由でアクセスさせることができます。

Apps機能を使うには、↑でも記載したようにSubnet Routerの起動オプションが必要です。

--advertise-connector --advertise-tags=tag:connector

この時指定したタグ(今回の例ではconnector)をAppsの画面で指定してあげてください。

ACLによる自動承認

デフォルトだとSubnet Routerで宛先ルートが増えた場合、管理者はそのルートを手動操作で承認する必要があります。Appsも挙動は同じです。

下記の記載をACLに追加することで、Appsで追加されたルートを自動承認するようにできます。

{
	"autoApprovers": {
		"routes": {
			"0.0.0.0/0": ["tag:connector"],
			"::/0":      ["tag:connector"]
		}
	}
}

⚠ 1点注意点
AppsはDNSを利用した挙動です。そのため、hostsファイルに記載された宛先など、DNSパケットが発生しない通信はTailscale経由の通信になりません。この場合はAppsではなく、社内ネットワークのセグメント同様にIPアドレスレベルで指定をする必要があります。

７．最後に

一通りTailscleを触り、実際に社内のエンジニアにも協力してもらうことで、Tailscaleが十分に社内VPNとして利用できることが分かりました。

特に設定の容易さとVPNエンドポイントを持たない点は非常に魅力的だと思います。

またTailscaleには本日紹介できていない機能が多数あります。しかも、今後のアップデートで新機能はどんどん増えていくとのことなので、今後の展開にも期待ができます。

この記事が、Tailscale導入を検討されている方の参考になれば幸いです。

一休の情シスでは共に働いてくれるメンバーを募集しています

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up