App Connector
更新
App Connectorは全プランでご利用いただけます。
App Connectorは、tailnet内のユーザーやデバイスから特定のアプリケーションへ向かう通信を、専用のLinuxノード(App Connectorデバイス)経由でルーティングする機能です。
対象のアプリケーションはIPアドレスではなくドメイン名で指定します。
SaaS、クラウド上のサービス、自社でホストしているWebアプリケーションのいずれにも利用できます。
App Connectorを経由した通信は、アプリケーション側からはApp ConnectorデバイスのグローバルIPアドレスから届いたように見えます。
そのため、SaaSのIPアドレス制限(IP許可リスト)にApp ConnectorのIPアドレスだけを登録しておけば、ユーザーが自宅・出張先・モバイル回線など、どこから接続していても同じ送信元IPアドレスでアクセスさせることができます。
このページでは、App Connectorが解決する課題、仕組み、Subnet RouterやExit Nodeとの違い、設計・運用上の注意点を解説します。
App Connectorが解決する課題
多くのSaaS(Microsoft 365、Google Workspace、Salesforce、GitHub、Okta等)は、管理者が登録したIPアドレスからのアクセスのみを許可するIPアドレス制限機能を持っています。
しかし、リモートワークやモバイル端末からの利用が前提になると、次のような問題が生じます。
- 社員のアクセス元IPアドレスが毎回変わるため、IPアドレス制限を有効にできない。
- 例外登録を繰り返すうちに許可リストが肥大化し、誰のためのIPアドレスなのか追跡できなくなる。
- 本社のVPN装置を経由させてIPアドレスを揃えると、SaaSと無関係な通信まで本社に集中し、回線と装置がボトルネックになる。
App Connectorを使うと、指定したドメイン宛ての通信だけをApp Connector経由にし、それ以外の通信は各端末から直接インターネットへ出すことができます。
SaaSのIPアドレス制限を「社内ネットワークからのアクセス」ではなく「tailnetに参加し、ACLで許可されたユーザー・デバイスからのアクセス」に置き換えられる点が、App Connectorの本質的な価値です。
仕組み
App Connectorの動作に関わる構成要素は次の3つです。
- App Connector(設定)
-
管理コンソールまたはtailnetポリシーファイルで定義する設定です。
「どのアプリケーション(ドメイン)の通信を、どのタグを付けたデバイス経由でルーティングするか」を指定します。 - App Connectorデバイス
-
アプリケーションへの通信を中継する、tailnet内のLinuxデバイスです。
物理サーバでも仮想マシンでも構いません。 - アプリケーション
- App Connectorデバイスが通信を転送する先の、SaaS・クラウド・自社ホスト型のアプリケーションです。
通信は次の流れで処理されます。
- ユーザーのデバイスが、App Connectorに設定されたドメイン(例:
github.com)の名前解決を行います。 - App Connectorデバイスは、PeerAPIを使ったDoH(DNS over HTTPS)によるDNSディスカバリで、そのドメインのIPアドレスを解決します。
- 解決されたIPアドレスは、App Connectorデバイスからtailnetへのルートとして自動的にアドバタイズされます。
- ユーザーのデバイスからそのIPアドレス宛ての通信が、WireGuardで暗号化されたトンネルを通ってApp Connectorデバイスへ届きます。
- App Connectorデバイスは、自身のグローバルIPアドレスからアプリケーションへ通信を送り出します。応答は同じ経路を折り返してユーザーのデバイスへ返されます。
App Connectorは内部的にはSubnet Routerと同様に動作しますが、宛先をIPアドレスの範囲ではなくドメイン名で指定できる点が異なります。
SaaSのIPアドレスは事業者の都合で頻繁に変わるため、IPアドレス範囲を手作業で追従するSubnet Routerよりも、ドメイン名を起点にルートを学習するApp Connectorの方が安定して運用できます。
学習したルートは自動では承認されないため、tailnetポリシーファイルのautoApproversでApp Connectorのタグに対するルートの自動承認を設定します。
また、DNSディスカバリのため、ユーザーのデバイスからApp Connectorのタグに対して、ポート53(TCP/UDP)への最小限のアクセスを許可する必要があります。
Subnet Router・Exit Nodeとの違い
App Connectorは、Subnet RouterやExit Nodeと同じく「特定のノードを経由させる」機能ですが、対象と目的が異なります。
| 項目 | App Connector | Subnet Router | Exit Node |
|---|---|---|---|
| 経由させる通信 | 指定したドメイン宛ての通信のみ | 指定したIPアドレス範囲(サブネット)宛ての通信 | インターネット宛ての通信すべて |
| 宛先の指定方法 | ドメイン名(ワイルドカード可) | CIDR形式のIPアドレス範囲 | 指定不要(全通信) |
| 主な用途 | SaaS・Webアプリケーションへの送信元IPアドレスの集約 | Tailscaleを導入できない機器・拠点LANへの到達 | 公衆Wi-Fi利用時の保護、特定拠点からのインターネット利用 |
| ノードの要件 | Linux、グローバルIPアドレス、IPフォワーディング有効 | Linux・Windows・macOS等(LinuxではIPフォワーディングの有効化が必要) | Linux・Windows・macOS等(LinuxではIPフォワーディングの有効化が必要) |
| その他の通信への影響 | なし(他の通信は端末から直接) | なし(指定範囲以外は端末から直接) | すべての通信がExit Node経由になる |
Webアクセス全般を特定の出口IPアドレスから出したい場合はExit Node、IPアドレス制限のあるSaaSや特定のWebアプリケーションだけを対象にしたい場合はApp Connectorが適しています。
なお、App Connectorに設定したドメイン宛ての通信は、ユーザーがExit Nodeを使用している場合でもApp Connector経由でルーティングされます。
構成要件
Tailscaleの公式ドキュメントで定められている要件と、Velumeshが構築時に前提としている条件は次のとおりです。
| 項目 | Tailscale公式ドキュメントの要件 | Velumeshの構築方針 |
|---|---|---|
| OS | Linux | Linux(専用サーバとして構築) |
| IPアドレス | パブリックIPアドレスを持つこと | 固定のグローバルIPアドレスを割り当てる |
| IPフォワーディング | 有効にすること | 有効にする |
| 筐体 | 物理デバイスまたは仮想マシン | 社内・学内にグローバルIPアドレスを割り当てたサーバを用意できない場合は、クラウド(GcoreのVPS等)上の仮想マシンで構築 |
| 管理者権限 | tailnetのOwner、Admin、Network adminのいずれか | お客様のtailnet管理者と役割分担を決めて設定 |
| アプリケーション側 | 管理者権限を持つSaaSまたは自社ホスト型アプリケーション | IPアドレス制限の設定はお客様のアプリケーション管理者と調整 |
公式ドキュメントの要件は「パブリックIPアドレスを持つこと」であり、固定IPアドレスであることまでは明記されていません。
しかし、App Connectorの主な目的であるSaaS側のIP許可リストへの登録は、送信元IPアドレスが変わらないことが前提になります。
そのため、Velumeshでは固定のグローバルIPアドレスを持つサーバでApp Connectorを構築することを前提としています。
IP許可リストに登録するのはApp ConnectorデバイスのパブリックIPアドレスであり、Tailscale IPアドレス(100.x.y.z)ではない点にもご注意ください。
プリセットアプリとカスタムアプリ
App Connectorの対象アプリケーションは、プリセットアプリとカスタムアプリの2種類の方法で設定できます。
- プリセットアプリ
-
Tailscaleが、アプリケーションに必要なドメインとルートを事業者の公開情報から定期的に取得し、tailnetに反映する方式です。
ドメインやIPアドレス範囲を自分で調べる必要がなく、ルートは原則として自動承認されます。
2026年10月時点で、Tailscaleの公式ドキュメントには次のプリセットアプリが掲載されています。- AWS CloudFront(グローバル)
- AWS Elastic Compute Cloud(EC2)/Elastic Load Balancing(ELB)
- AWS Simple Storage Service(S3)
- Confluence
- GitHub
- Google Workspace
- Jira
- Microsoft 365
- Okta
- Oracle Cloud Infrastructure(OCI)
- Oracle Object Storage
- Oracle Services Network(OSN)(グローバル)
- Salesforce(Hyperforce環境)
- Salesforce(Salesforceホスト)
- Stripe
- カスタムアプリ
-
プリセットにないアプリケーションは、tailnetポリシーファイルの
nodeAttrsにドメイン名を記述して設定します。
ワイルドカードはサブドメインに対して使用できます(例:*.example.com)。
ワイルドカードは親ドメインを含まないため、example.comとそのサブドメインの両方を対象にする場合は、example.comと*.example.comの両方を記述します。
カスタムアプリのルートには、常にautoApproversの設定が必要です。
設計・運用上の注意点
App Connectorは設定自体は簡単ですが、導入後に「つながらない」「制限がかからない」といった問題を起こさないためには、次の点を設計段階で考慮する必要があります。
- tailnetに接続していない端末は制限されない
-
App Connectorはtailnetに接続している端末の通信をルーティングする機能です。
ユーザーがTailscaleを切断している場合、SaaS側でIP許可リストを設定していなければ、そのまま直接アクセスできてしまいます。
IP許可リストを設定したうえで、MDMのシステムポリシー(AlwaysOn.Enabled等)で常時接続を強制する構成が有効です。 - ルートの受け入れ設定
-
ユーザーがTailscaleクライアントで「Tailscaleサブネットを使用する」設定を無効にすると、App Connectorを経由しなくなります。
システムポリシー(UseTailscaleSubnets)で、ユーザーが変更できないように固定できます。
また、Linuxのデバイスは既定でルートを受け入れないため、tailscale set --accept-routes=trueの設定が必要です。 - ドメインの網羅
-
1つのサービスが、ログイン用、API用、静的コンテンツ配信用など複数のドメインを使い分けていることがあります。
必要なドメインがすべてApp Connectorに設定されていないと、一部の通信だけがIP許可リストで拒否されます。
プリセットアプリがある場合はプリセットアプリを優先して利用し、カスタムアプリの場合はブラウザの開発者ツールやDNSログで使用ドメインを洗い出します。 - 同じIPアドレスを共有する他のドメイン
-
CDNやクラウドのロードバランサーでは、複数の無関係なドメインが同じIPアドレスを共有することがあります。
App Connectorはドメインから学習したIPアドレスをルートとして扱うため、同じIPアドレスを共有する別のドメイン宛ての通信もApp Connector経由になります。 - App Connectorデバイスの障害
-
App Connectorデバイスが停止し、代替のApp Connectorがない場合、対象ドメインの名前解決が失敗するようになります。
業務で使うSaaSを対象にする場合は、同じアプリケーションに対して複数のApp Connectorデバイスを用意する冗長構成を推奨します。
冗長構成では、各App ConnectorのグローバルIPアドレスをすべてSaaS側のIP許可リストに登録します。 - ノードキーの有効期限
-
App Connectorデバイスのノードキーが期限切れになると、ルートは他のデバイスに残ったまま到達不能になります(フェイルクローズ)。
タグを付けたApp Connectorデバイスではキーの有効期限を無効化するなど、キーの期限切れによる停止を防ぐ設定を行います。 - IaCとの併用
-
TerraformなどでtailnetポリシーファイルやApp Connectorを管理している場合、管理コンソールで行った変更は次回の同期で上書きされます。
App Connectorの設定は、管理コンソールとIaCのどちらか一方で管理してください。
Gcore仮想マシンによるApp Connector構築サービス
App Connectorには固定のグローバルIPアドレスを持つLinuxサーバが必要ですが、社内にそのようなサーバを用意できない企業も少なくありません。
Velumeshでは、Spelldataが代理店を務めるEdgeZone(Gcore)の東京リージョンに仮想マシンを用意し、App Connectorとして構築・提供します。
Gcoreの仮想マシンはエグレス(送信トラフィック)が無料のため、App Connectorを経由する通信量がいくら増えても、費用は仮想マシンの月額のみです。
サーバの調達、OSの初期設定、Tailscaleの設定、tailnetポリシーファイルの設計までを一括で承るため、お客様はSaaS側のIP許可リストにApp ConnectorのグローバルIPアドレスを登録するだけで利用を開始できます。
サーバの標準構成
| 項目 | 内容 |
|---|---|
| 設置場所 | Gcore 東京リージョン |
| 仮想マシン | 1vCPU・メモリ2GB(バースト型ではないインスタンス) 利用状況に応じてスケールアップ可能 |
| OS | Rocky Linux 9 |
| IPアドレス | 固定のグローバルIPアドレス(サーバを作り直す場合も同じIPアドレスを引き継ぐ設定) |
| 通信料金 | エグレス(仮想マシンからの送信トラフィック)は無料。通信量による追加費用なし |
| 更新 | OSとTailscaleを自動更新し、更新を反映するため毎日深夜2時に自動で再起動 |
| 構築方法 | 構成管理ツールAnsibleで構築を自動化し、同じ構成を短時間で再構築できる状態で納品 |
| 稼働状況の確認 | Tailscaleの管理コンソールで、App Connectorのオンライン・オフラインを確認可能 |
シングル構成と冗長構成
App Connectorのサーバは、1台で運用するシングル構成と、2台で運用する冗長構成からお選びいただけます。
| 項目 | シングル構成(1台) | 冗長構成(2台) |
|---|---|---|
| 仮想マシン費用 | 月額3,454円(税抜) | 月額6,908円(税抜) |
| 深夜2時の再起動 | 再起動中の数分間、社外から対象SaaSを利用できない | 2台の再起動時刻をずらすため、再起動による停止なし |
| サーバ障害・更新失敗時 | 復旧が完了するまで対象SaaSを利用できない | もう1台のApp Connectorで利用を継続 |
| SaaS側のIP許可リスト | 1件を登録 | 2台分の2件を登録 |
| 適した用途 | 検証環境、少人数での利用、深夜の短時間停止が業務に影響しない場合 | 全社での本番利用、深夜・早朝もSaaSを利用する場合 |
仮想マシン費用は12か月分の年間契約で承ります。
いずれの構成も、通信量に応じた追加費用は発生しません。
業務で使うSaaSを対象とし、利用者が多い場合は冗長構成をお勧めします。
運用設計の考え方
- エグレス無料のGcoreを選ぶ理由
-
App Connectorは、対象SaaSとの通信をすべて中継するサーバです。
利用者がSaaSからファイルをダウンロードしたり、SaaSへアップロードしたりすると、その通信はすべてApp Connectorの仮想マシンを経由して送受信されます。
仮想マシンからの送信トラフィック(エグレス)に従量課金があるクラウドでは、利用者数や利用量が増えるほど通信料金が増え、月々の費用を事前に確定できません。
Gcoreは、仮想マシンの送信トラフィックを無料と定めています(Gcore Billing)。
そのため、App Connectorの費用は仮想マシンの月額のみで確定し、全社展開で通信量が増えても、通信量によって費用が変動しません。 - OSとTailscaleの自動更新
-
App Connectorはインターネットに直接接続するサーバであるため、OSのセキュリティ更新を止めずに適用し続けることを優先します。
App Connectorは専用サーバとして構築し、他の用途と兼用しないため、毎日深夜2時の自動再起動を前提とした運用ができます。
冗長構成では、2台の再起動時刻をずらすことで、更新の適用と継続利用を両立します。 - バックアップを取らない理由
-
App Connectorのサーバには業務データが保存されません。
アクセス制御ポリシーや対象SaaSのドメイン設定は、サーバではなくTailscaleのコントロールプレーン側に保存されています。
そのため、万一サーバが壊れた場合は、バックアップから復元するのではなく、Ansibleで新しいサーバを構築し直す方が早く確実です。
冗長化は「1台が止まってもサービスを止めない」ための仕組み、バックアップは「失ったデータを元に戻す」ための仕組みであり、目的が異なります。
データを持たないApp Connectorでは、グローバルIPアドレスの保持と、構築作業の自動化をバックアップの代わりの対策としています。 - EDRエージェントの導入
-
CrowdStrike Falcon等のEDRエージェントを、App Connectorのサーバに導入することもできます(オプション)。
Linux用のEDRエージェントは、対応するカーネルのバージョンがエージェントのバージョンごとに決まっている製品があります。
OSを毎日自動更新する構成では、エージェントが未対応の新しいカーネルに更新され、検知・防御が制限される期間が生じる可能性があります。
カーネルへの依存が少ない動作モードの選択や、EDRの管理コンソールでの状態確認など、運用方法を事前にご相談のうえ導入します。
エージェントのインストールは弊社で行い、EDRの管理コンソール側のポリシー設定は、お客様の運用ルールに沿ってお客様に行っていただきます。
作業内容と費用
構築作業はプロフェッショナルサービス(ショット契約、1時間30,000円・税抜)として承ります。
標準的な作業時間は次のとおりです。
| 作業 | シングル構成(1台) | 冗長構成(2台) |
|---|---|---|
| ACL(tailnetポリシーファイル)の設計・設定 | 1時間 | 1時間 |
| App Connectorの構築 | 2時間 | 4時間 |
| 小計 | 3時間 | 5時間 |
| EDRエージェントのインストール(オプション) | 1時間 | 1時間 |
サーバ障害時の再構築作業も、弊社が責任を持って行います。
再構築の作業費は、プロフェッショナルサービスとして承ります。
お客様にご用意いただくもの
- App Connector経由で利用するSaaS・Webアプリケーションの一覧
- 各SaaSのIP許可リストを設定できる管理者の方のご協力
- tailnetの管理者権限(弊社のサポート用アカウントをAdminとして招待していただきます)
- EDRエージェントを導入する場合は、エージェントのインストーラーと、テナントの識別子などインストールに必要な情報
サーバへのアクセスについては、App ConnectorやSubnet Routerを経由させるよりも、サーバ自体にTailscaleを導入してP2Pで直接接続する構成の方が、経路が単純で性能面でも有利です。
Velumeshでは、App Connectorは「Tailscaleを導入できないSaaS・外部サービス」へのアクセスに用い、自社管理のサーバにはTailscaleを直接導入する構成をご提案しています。
App Connectorに関するよくある質問
- App Connectorを経由すると、SaaSとの通信内容をApp Connectorデバイスで見られますか?
-
ユーザーのデバイスからApp ConnectorデバイスまではWireGuardで暗号化されます。
App ConnectorデバイスはIPパケットを中継するだけで、HTTPS通信の場合はSaaSとの間のTLSで保護されているため、中継時に通信内容を復号することはありません。 - Windows・macOS・iOS・Androidの端末からも利用できますか?
-
App ConnectorデバイスはLinuxである必要がありますが、App Connectorを経由してアプリケーションを利用する側の端末は、ルートを受け入れる設定になっていれば利用できます。
Linuxの端末から利用する場合は、ルートの受け入れ(--accept-routes)を有効にしてください。 - Kubernetes上にApp Connectorを構築できますか?
-
はい。
TailscaleのKubernetes Operatorを使って、KubernetesクラスタにApp Connectorをデプロイできます。 - App Connectorの追加・削除は記録されますか?
-
はい。
App Connectorの追加・削除は、構成変更の監査ログに記録されます。
詳細ドキュメント
App Connectorの設定手順や詳細な仕様は、Tailscale公式ドキュメントの日本語訳をご参照ください。
関連機能
Subnet Router
Tailscaleクライアントをインストールできない機器(監視カメラ、プリンタ、IoTデバイス、レガシーサーバ等)を、Tailscaleネットワークに接続するための中継ノードです。
産業用LinuxBoxを使った構築もVelumeshでは対応しています。
全プラン
Exit Node
特定のデバイスをExit Nodeとして指定すると、そのデバイスを経由してインターネットにアクセスできます。
公共Wi-Fi利用時のセキュリティ確保や、特定の拠点からインターネットに出たい場合に活用できます。
全プラン
高可用性Subnet Router
同一サブネットに対して複数のSubnet Routerを設定し、自動フェイルオーバーを実現します。
1台のSubnet Routerが障害で停止しても、別のルータに自動的に切り替わるため、ネットワークのダウンタイムを最小化できます。
全プラン
ACL(アクセス制御リスト)
JSON形式でネットワーク全体のアクセスポリシーを定義します。
Starterプランではautogroupsベースのシンプルなルールを、Premium以上ではユーザ・グループ単位のきめ細かなルールを定義可能です。
GitOpsによるバージョン管理にも対応しています。
全プラン(フルACLはPremium以上)