Tailscaleとは、WireGuardを土台にしたメッシュ型VPNサービスで、各端末が互いに直接暗号化トンネルを張り、鍵の配布と認証だけをTailscaleのコーディネーションサーバーが受け持ちます。自宅サーバーにインストールしてログインすれば、ルーターのポート開放も固定IPも動的DNSも不要で、外出先のスマホやノートPCから 100.x.y.z のアドレスでSSHやProxmoxのWeb UIに届きます。
ProxmoxホストとUbuntu VMに入れて、ACLで到達範囲を絞り、Subnet RouterでLAN全体へ、Exit Nodeで外出先の通信を自宅経由に、Tailscale SSHで鍵管理をなくす、というところまでを15分で通します。
この記事でわかること
- コーディネーションサーバー・DERP・MagicDNSがそれぞれ何をし、秘密鍵はどこにあるのか
tailscale upとtailscale setの違い、各OSでのインストールとログイン- タグとACL（ポリシーファイル）でサーバーへの到達を絞る書き方
--advertise-routes（Subnet Router）と--advertise-exit-node（Exit Node）の設定と承認- Tailscale SSH、MagicDNS、
tailscale serveの使いどころと、企業で使うときの線引き
Tailscaleとは：WireGuardベースの仕組み
各端末の tailscaled は初回起動時にWireGuardの鍵ペアを作り、公開鍵だけをコーディネーションサーバーに登録します。サーバーは「どの端末がどの公開鍵とどのIPを持ち、誰と話してよいか」を全端末に配り、端末同士はその情報でWireGuardトンネルを直接張ります。NATの内側同士でもSTUNで外側のポートを調べてホールパンチングし、それでも直接つながらない場合だけDERPという中継サーバーを経由します。DERPは暗号化済みのパケットを転送するだけで、中身は復号できません。
| 用語 | 役割 |
|---|---|
| tailnet | 1つのアカウント（組織）に属する端末の集合。私設ネットワークの単位 |
| コーディネーションサーバー | 公開鍵・端末一覧・ACLの配布と、IdPでのログイン処理。通信データは通らない |
| DERP | 直接接続できないときの中継。暗号化されたままリレーする |
| MagicDNS | ホスト名.tailnet名.ts.net で端末に名前解決できる仕組み |
| 100.64.0.0/10 | 各端末に配られるIPv4アドレスの範囲。CGNAT用の予約帯なのでLANと衝突しない |
安全性の考え方：鍵はどこにあり、何を信頼するのか
秘密鍵は端末から出ません。したがってTailscale社が通信を復号することはできず、盗聴に対する強度はWireGuardを自前で組むのと同じです。信頼しているのは「コーディネーションサーバーが正しい端末一覧を配る」という一点で、理屈のうえでは運営側が不正な端末をtailnetに追加できます。これを塞ぐのがTailnet Lockで、既存の署名ノードが承認した鍵しか有効にならなくなります。さらに踏み込むなら、コーディネーションサーバー自体をオープンソースのHeadscaleで自前運用する選択肢もあります。
ログインはGoogle・Microsoft・GitHub・Apple・OIDCのアカウント、またはパスキーで行うので、実質的な入口はそのIdPのアカウントです。ノード鍵は既定で180日で期限切れになり、再ログインが必要になります。常時稼働のサーバーは管理コンソールの端末メニューで「Disable key expiry」にしておかないと、半年後に突然つながらなくなります。
ログインに使うGoogleやMicrosoftのアカウントが乗っ取られると、tailnetごと乗っ取られます。そのアカウントに多要素認証（できればパスキー）を設定し、家族と共用のアカウントは使わないでください。
無料プランで使える範囲
執筆時点の個人向け無料プランは、ユーザー3人・端末100台までで、ACL・MagicDNS・Subnet Router・Exit Node・Tailscale SSHといったこの記事の機能はすべて含まれています。上限と条件は変わるので、公式の料金ページで確認してください。有料プランとの主な差は、ユーザー数、企業向けIdP連携、監査ログ、サポートです。個人プランは個人利用が前提なので、会社のサーバーに使うなら後述の「企業利用時の注意」を先に読んでください。
インストールとログイン（Linux・Windows・macOS・スマホ）
Linux（Proxmoxホストを含むDebian/Ubuntu）はインストールスクリプトがaptリポジトリを登録します。sh に直接流さず、一度ファイルに落として中身を見てから実行します。
curl -fsSL https://tailscale.com/install.sh -o install-tailscale.sh
less install-tailscale.sh
sudo sh install-tailscale.sh
sudo tailscale up # 表示されたURLをブラウザで開いてログイン
tailscale ip -4 # 100.x.y.z が返る
tailscale statusWindowsとmacOSは公式サイトのインストーラー（macOSはApp Store版もあります）、iOS/Androidはストアのアプリを入れ、同じアカウントでログインするだけです。設定を後から変えるときは tailscale set を使います。tailscale up は「指定しなかったフラグを既定値に戻す」動きをするため、--ssh を後から足そうとすると既存設定を全部書き直せというエラーになります。tailscale set --ssh なら、その項目だけが変わります。
ProxmoxのLXCコンテナに入れる場合、非特権コンテナには /dev/net/tun がなく tailscaled が起動に失敗します。ホスト側の /etc/pve/lxc/ID.conf に lxc.cgroup2.devices.allow: c 10:200 rwm と lxc.mount.entry: /dev/net/tun dev/net/tun none bind,create=file を追記して再起動してください。ホスト自体かVMに入れる方が手間は少ないです。
ACLで接続を制限する
新しいtailnetのポリシーは「全端末が全端末に全ポートで接続可」です。自分1人・端末数台なら困りませんが、家族の端末を招待した瞬間に、その端末が乗っ取られればサーバーに素通りになります。管理コンソールの Access Controls でポリシーファイル（HuJSON）を編集し、サーバーに tag:server を付けて到達先を絞ります。タグは端末を人ではなく役割で扱う仕組みで、タグ付きの端末はユーザーの鍵期限や退会の影響を受けません。
{
"tagOwners": {
"tag:server": ["autogroup:admin"],
},
"acls": [
// 管理者は全端末の全ポートへ
{"action": "accept", "src": ["autogroup:admin"], "dst": ["*:*"]},
// 家族など一般メンバーはサーバーのWebだけ
{"action": "accept", "src": ["autogroup:member"], "dst": ["tag:server:443,8096"]},
],
"ssh": [
// 管理者はTailscale SSHでサーバーへ。12時間ごとに再認証（check）
{"action": "check", "src": ["autogroup:admin"], "dst": ["tag:server"], "users": ["autogroup:nonroot", "root"]},
],
"autoApprovers": {
"routes": {"192.168.10.0/24": ["tag:server"]},
"exitNode": ["tag:server"],
},
}ACLは送信元から宛先への「新規接続」を許可するもので、戻りのパケットは自動で通ります。したがって「サーバーから家族の端末へ」の行は不要です。タグは管理コンソールの端末メニュー「Edit ACL tags」で付けるか、サーバー側で sudo tailscale up --advertise-tags=tag:server を実行して、tagOwnersに含まれるアカウントで再認証します。執筆時点では acls を置き換える grants という新しい書式も導入されていますが、acls はそのまま使えます。
Subnet RouterでLAN全体にアクセスする
NASの管理画面、プリンター、IoT機器、Proxmoxの各VMのように、Tailscaleを入れられない（入れたくない）機器には、LAN内の1台をSubnet Routerにして経路を広告します。Subnet Routerは受け取ったパケットをLAN側へ転送し、既定で送信元を自分のLANアドレスに書き換える（SNAT）ので、LAN側の機器に戻り経路を教える必要はありません。
echo 'net.ipv4.ip_forward = 1' | sudo tee -a /etc/sysctl.d/99-tailscale.conf
echo 'net.ipv6.conf.all.forwarding = 1' | sudo tee -a /etc/sysctl.d/99-tailscale.conf
sudo sysctl -p /etc/sysctl.d/99-tailscale.conf
sudo tailscale set --advertise-routes=192.168.10.0/24
# 転送性能の警告が出たら（Linux 6.2以降）:
sudo ethtool -K eno1 rx-udp-gro-forwarding on rx-gro-list off広告した経路は管理コンソールで承認しないと有効になりません。上のポリシーの autoApprovers があれば tag:server の端末が広告した 192.168.10.0/24 は自動承認されます。受け側のWindows・macOS・iOS・Androidは既定で経路を受け取りますが、Linuxは sudo tailscale set --accept-routes が必要です。Subnet Routerは1台で十分で、家じゅうの機器にTailscaleを入れて回るのは鍵期限の管理が増えるだけなので勧めません。
Exit Nodeで外出先の通信を自宅経由にする
Exit Nodeは、tailnet宛てだけでなくインターネット宛ての全通信を自宅サーバー経由にする機能です。空港やカフェの公衆Wi-Fiで、DNSを含むすべての通信を自宅の回線から出したいときに使います。サーバー側は sudo tailscale set --advertise-exit-node を実行し（IP転送の設定は上と同じ）、管理コンソールで承認します。クライアント側はスマホならアプリの「Exit node」メニューで自宅サーバーを選び、Linuxなら次のとおりです。
sudo tailscale set --exit-node=pve --exit-node-allow-lan-access
sudo tailscale set --exit-node= # 解除--exit-node-allow-lan-access を付けないと、外出先のプリンターやホテルのテレビなど、その場のLANに届かなくなります。Exit Nodeを常用すると動画も自宅の上り回線を通るので、日常はSubnet Routerだけにして、信用できないWi-Fiのときだけ切り替えるのが実用的です。
Tailscale SSHとMagicDNS
サーバーで sudo tailscale set --ssh を実行すると、tailnet経由で22番に来た接続だけをTailscaleが受け、ポリシーの ssh セクションとtailnetの身元で認証します。公開鍵の配布も authorized_keys の管理も要りません。LAN側からの通常のsshdはそのまま動くので、既存の運用を壊しません。check にしておくと既定で12時間ごとにブラウザでの再認証を求められ、端末を置き忘れたときの保険になります。
ssh alice@pve # MagicDNSで pve.tailnet名.ts.net に解決
# Proxmox Web UIを正規の証明書でtailnetに公開（サーバー側で実行）
sudo tailscale serve --bg https+insecure://localhost:8006
# https://pve.tailnet名.ts.net/ で警告なしに開けるtailscale serve は、管理コンソールのDNS設定で HTTPS Certificates を有効にしておくと、ts.net ドメインの証明書をLet's Encryptから自動取得し、ローカルのサービスをtailnet内にだけ公開します。https+insecure はProxmoxの自己署名証明書を検証せずに中継する指定です。似た名前の tailscale funnel はインターネット全体に公開するコマンドで、用途がまったく違います。
tailscale funnel は認証なしで世界中に公開します。Proxmox・NAS・ルーターの管理画面には絶対に使わず、使うなら公開して問題ない静的サイトやWebhook受信口に限ってください。
企業利用時の注意
| 状況 | 取るべき形 | 理由 |
|---|---|---|
| 個人の自宅サーバー | 個人プラン、個人アカウント | 本記事の範囲。IdPアカウントのMFAが要 |
| 会社で正式に導入 | 有料プラン、Entra ID/Okta等のSSO、ユーザー・端末承認、ポリシーをGitで管理 | 退職者の即時失効、監査ログ、レビュー付きの変更が要る |
| 会社が外部の管理サーバーを許容しない | Headscaleの自前運用、またはWireGuard単体 | コーディネーションサーバーへの依存をなくす |
情シスとして一番避けたいのは、社員が個人アカウントのTailscaleを社内サーバーに入れる「便利なシャドーIT」です。個人アカウントは退職しても会社から失効できません。導入するなら会社のtailnetを作り、端末承認を必須にし、タグとACLで部署ごとに到達先を分けます。境界型VPNの置き換えではなく、端末と身元を確認してから最小の到達先を許すゼロトラストの道具として位置づけると設計がぶれません。
動作確認
tailscale status
# 100.101.102.103 pve alice@ linux -
# 100.101.102.104 iphone alice@ iOS active; direct 203.0.113.5:41641
tailscale ping pve
# pong from pve (100.101.102.103) via 203.0.113.5:41641 in 14ms ← 直結
# pong from pve (100.101.102.103) via DERP(tok) in 45ms ← 中継
tailscale netcheck | grep -E 'UDP|Nearest'
# * UDP: true / * Nearest DERP: Tokyo
ssh alice@pve 'hostname' # pve が返ればTailscale SSHは正常
curl -sk https://192.168.10.30/ -o /dev/null -w '%{http_code}\n' # Subnet Router経由でNASに届くつまずきポイント
Error: changing settings via 'tailscale up' requires mentioning all non-default flags:tailscale upは未指定のフラグを既定値に戻します。tailscale setで項目だけ変えるか、表示された全フラグ付きのコマンドを使います。Warning: IP forwarding is disabled, subnet routing/exit nodes will not work.: sysctlのnet.ipv4.ip_forwardが0です。上の99-tailscale.confを作ってsysctl -pします。- 経路を広告したのにLANに届かない: 管理コンソールで経路が未承認か、Linuxクライアントに
--accept-routesがありません。端末一覧のSubnets列に承認済みの経路が出ているか確認します。 tailscale pingがいつもvia DERPで遅い: 直結が成立していません。tailscale netcheckでUDP: falseならファイアウォールが外向きUDPを止めています。MAP-EやDS-Liteの回線は使えるポートが限られ中継になりやすいので、ルーターでUDP 41641をサーバーへ転送すると直結しやすくなります。
よくある質問
Tailscaleは安全ですか？
通信はWireGuardで端末間を暗号化され、秘密鍵は端末から出ないため、運営側にも中継サーバー（DERP）にも中身は見えません。信頼するのは端末一覧を配るコーディネーションサーバーで、それを嫌うならTailnet LockかHeadscaleで補えます。実際の弱点はログインに使うIdPアカウントなので、そこにMFAを付けることが最優先です。
無料で使えますか？
執筆時点の個人プランは無料で、ユーザー3人・端末100台まで、ACL・Subnet Router・Exit Node・Tailscale SSHを含みます。条件は変わることがあるので公式の料金ページで確認してください。会社の業務で使う場合は有料プランが前提です。
ポート開放は必要ですか？
不要です。STUNとホールパンチングで両側のNATを越え、無理な場合はDERPで中継されます。直結の成功率を上げたいときだけ、任意でUDP 41641をサーバーに転送します。ルーターに穴を開けないまま使えるのが、自前のWireGuardサーバーとの一番の違いです。
WireGuardと何が違いますか？
WireGuardは暗号化トンネルのプロトコルで、鍵の交換・端末の追加削除・NAT越え・アクセス制御は自分で用意します。Tailscaleはその上に鍵配布、IdP認証、NAT越え、ACL、DNSを載せたサービスです。拠点間の固定トンネル1本ならWireGuard単体の方が依存が少なく、端末が増減する用途はTailscaleの方が運用が軽くなります。
まとめ
自宅サーバーへの入口は、ルーターのポート開放ではなくTailscaleにし、サーバーには tag:server を付けて鍵期限を無効化、ACLで一般メンバーの到達先をWebのポートだけに絞る。Subnet Routerを1台立てればNASやVMにも届き、Exit Nodeは信用できないWi-Fiのときだけ使う。この形なら、Proxmoxのポート8006も22番もインターネットからは見えません。サーバー側のsshd自体の固め方はLinuxサーバーの基本ハードニングで押さえてください。