Tailscaleとは｜使い方・料金・VPNとの違いをWireGuardで実演

Tailscale の中心は「調整サーバー（鍵と住所を配る係）」と「端末同士の直接の通信」の2つに分かれています。通信の中身は調整サーバーを通りません。

flowchart TD
    CS[調整サーバー<br>公開鍵と住所を配る] -.-> A[ノートPC]
    CS -.-> B[自宅のPC]
    CS -.-> C[クラウドのサーバー]
    A <-->|WireGuardで直接| B
    A <-->|WireGuardで直接| C

やりたいことごとの操作は次のとおりです。

確認環境：Ubuntu 24.04.4・Linux カーネル 6.18・wireguard-go 0.0.20230223（ユーザー空間の WireGuard）・wireguard-tools v1.0.20210914（wg コマンド）・iproute2 6.1.0・iptables 1.8.10・tcpdump 4.99.4・curl 8.5.0・Python 3.11.15。Linux の network namespace（1台の中に独立したネットワークを作る仕組み）で「NAT の内側のノートPC・公開サーバー2台・その裏の LAN・Web サーバー」を作り、WireGuard でメッシュ・NAT越え・暗号化・MTU・subnet router・exit node の動きを実際に確かめています。Tailscale の CLI の表示・既定値（MTU 1280・UDP 41641・アドレス範囲）は GitHub の tailscale/tailscale のソース（1.105.0 の開発版、2026年10月21日のコミット）で、機能・料金・手順は tailscale.com の公式ドキュメント、最新の安定版（v1.104.2）は公式の Changelog で確かめました（確認日 2026年10月22日）。

Tailscaleとは：WireGuardで端末同士を直接つなぐVPN

この節では、Tailscale が何をする製品で、何が新しいのかが分かります。 Tailscale（読み方：テイルスケール）は、Tailscale Inc. が提供する VPN です。パソコン・スマホ・サーバーにアプリを入れて同じアカウントでログインすると、それらの端末が1つの私設ネットワークに入り、どこにいても互いに 100.x.y.z のアドレスで通信できます。

公式ブログ「How Tailscale works」の説明を要約すると、仕組みは次の3つです。

• 通信そのもの（データプレーン）は WireGuard のメッシュ：端末同士を直接、暗号化されたトンネルで結びます。原文では "The data plane is a mesh." です。
• 調整サーバー（コントロールプレーン）は鍵と住所を配るだけ：各端末の公開鍵・アドレス・アクセスの決まりを配り、通信の中身はほとんど運びません（"carries virtually no traffic"）。
• 秘密鍵は端末から出ない：各端末が自分で鍵の組を作り、秘密鍵は "never, ever leaves its node" とされています。

この私設ネットワークを Tailscale では tailnet（テイルネット） と呼びます。tailnet の各端末には、CGNAT 用の共有アドレス範囲 100.64.0.0/10（RFC 6598）から固定の IP が付きます。公式ドキュメントには、Wi-Fi からモバイル回線に切り替えてもアドレスは変わらない、とあります。

Tailscaleでできること

従来のVPNとの違い（中央サーバー型とメッシュ型）

この節では、会社の VPN 装置と Tailscale の通り道の違いが図で分かります。 公式ブログでは、従来の VPN を「ハブ＆スポーク型」と呼んでいます。すべての通信が中央の VPN 装置（コンセントレーター）を通るため、遠回りになりやすい形です。

従来の VPN は、次のようにすべてが中央を通ります。

flowchart TD
    A1[ノートPC] --> G[中央のVPN装置]
    B1[自宅のPC] --> G
    G --> S1[社内サーバー]

Tailscale は、端末同士が直接つながります。

flowchart TD
    A2[ノートPC] <--> B2[自宅のPC]
    A2 <--> S2[サーバー]
    B2 <--> S2

アクセス制御について、公式ブログは "central control over policy, but efficient, distributed enforcement"（決まりは中央で管理し、判定は各端末で分散して行う）と書いています。

WireGuardとの関係：Tailscaleが足している4つのもの

この節では、WireGuard だけで作る場合に手作業になる部分と、Tailscale が自動にしている部分が分かります。 WireGuard は、もとは Linux カーネル向けに作られ、今は Windows・macOS・iOS・Android などでも動く軽量な VPN の仕組みです。Tailscale は WireGuard のユーザー空間の実装（wireguard-go）を使い、その周りを自動化しています。

公式の比較ページ「Tailscale vs. WireGuard」の内容を表にします。

同じページの結論は、「少数の安定した Linux サーバーを守るなら WireGuard を直接使う形が向き、多くのユーザーを管理したい・集中管理の ACL が欲しいなら Tailscale が向く」です。

WireGuard だけで3台をつなぐと、実際にどこが手作業になるのかは、後の「Tailscaleが裏でしていることをWireGuardで再現する」で実物を見せます。

Tailscaleの用語・機能の早見表（tailnet・MagicDNS・ACL・exit node・subnet router）

この節では、管理画面やドキュメントに出てくる言葉の意味が1つの表で分かります。

ソースコード（net/tsaddr）では、tailnet の IPv4 の範囲が 100.64.0.0/10、IPv6 の範囲が fd7a:115c:a1e0::/48、端末の中の DNS などのサービスの住所が 100.100.100.100 と決められています。

Tailscaleの料金：無料のPersonalでできること

この節では、無料でどこまで使えるか、仕事で使うときはどのプランかが分かります。 料金は公式の料金ページの内容で、2026年10月22日時点のものです。

全プラン共通の点と追加料金です。

• ユーザーの端末（ユーザーデバイス）は全プランで数の制限なし。
• タグ付きの端末（サーバーなど）は、全プランで50台まで含まれ、それを超えると1台あたり月1ドル。
• Personal は非商用向け。 Gmail などの公開ドメインのアカウントで作った tailnet は自動で Personal になります。会社の独自ドメインで登録すると、14日間の Enterprise のトライアルになり、終了後にプランを選ばないと新しい端末の追加などが制限されます。
• ACL（grants）と基本の Tailscale SSH は全プラン共通の機能として料金ページに載っています。 Funnel・Tailscale SSH・端末の承認は、各機能のドキュメントに「全プランで利用できる」とあります。
• Mullvad VPN を exit node として使う追加機能は、5台ごとに月5ドル。

関連して、Standard からは SCIM でのユーザー管理、Premium からはネットワークのフローログ・ログのストリーミング・高度な Tailscale SSH が加わります。

Tailscaleのインストール（Windows・Mac・Linux・iPhone・Android）

この節では、OS ごとの入れ方と、最初のログインまでの手順が分かります。 どの OS も「アプリを入れる → SSO（Google・Microsoft・GitHub などの既存のアカウント）でログイン」の流れです。

Linux：install.sh と tailscale up

Linux は公式のワンライナーで入れ、tailscale up でログインします。

curl -fsSL https://tailscale.com/install.sh | sh
sudo tailscale up

tailscale up は、ログインが要るときに認証用の URL を出します。ソースコード（cmd/tailscale/cli/up.go）では、表示の形は次のとおりです。

To authenticate, visit:

    https://login.tailscale.com/a/（ランダムな文字列）

この URL をブラウザで開いて認証すると、端末が tailnet に入ります。サーバーのようにブラウザを開けない端末は、管理コンソールで作る auth key を使います。

sudo tailscale up --auth-key=tskey-（管理コンソールで作った鍵）

公式ドキュメントでは、auth key の有効期限は1〜90日（既定は90日）、ノードキーの既定の有効期限は180日です。再利用できる auth key は "Be very careful with reusable keys!" と注意されています。

パッケージを使わない環境では、静的バイナリを展開して sudo tailscaled --state=tailscaled.state でデーモンを起動する方法も公式に書かれています。

Tailscaleの使い方：最初に覚える操作

この節では、つながった後に毎日使う操作（状態を見る・IP を見る・名前でつなぐ・経路を確かめる）が分かります。

tailscale status の見方

tailscale status は、tailnet の端末を1行ずつ「IP・名前・持ち主・OS・状態」の順に表示します。状態の列に出る言葉は、ソースコード（cmd/tailscale/cli/status.go）の書式では次のとおりです。

ログインしていないときは Logged out.、管理者の承認待ちのときは Machine is not yet approved by tailnet admin. と表示されます（同じファイルの文言）。

tailscale ping で経路を確かめる

tailscale ping は、普通の ping と違い、Tailscale の層で届いたかと、どの経路を通ったかを表示します。ソースの書式は次の1行です。

pong from マシン名 (100.x.y.z) via 経路 in 時間

MagicDNS：名前でつなぐ

MagicDNS は、tailnet の端末に DNS 名を自動で付ける機能です。公式ドキュメントでは、2022年10月20日以降に作った tailnet では既定で有効です。名前は「マシン名 + tailnet の DNS 名（例：yak-bebop.ts.net）」で、同じ tailnet の中ではマシン名だけで届きます。

ssh user@monitoring                  # マシン名だけ
ssh user@monitoring.yak-bebop.ts.net # 完全な名前（共有された端末はこちら）

Windows のリモートデスクトップで自宅の PC につなぐときも、接続先にマシン名か 100.x.y.z を入れます。リモートデスクトップは Windows 側で有効にしておく設定で、Tailscale はその通り道を作ります。

tailscale コマンド一覧（CLI）

この節では、tailscale コマンドのよく使うサブコマンドの役割が一覧で分かります。 説明は公式の CLI リファレンスと、ソースの各コマンドの短い説明（ShortHelp）から書いています。

tailscale up で一度設定した後に、別のフラグだけを付けて up を実行すると、次のエラーになります（ソースの文言）。設定を1つだけ変えるときは tailscale set を使います。

Error: changing settings via 'tailscale up' requires mentioning all
non-default flags. To proceed, either re-run your command with --reset or
use the command below to explicitly mention the current value of
all non-default settings:

Tailscaleが裏でしていることをWireGuardで再現する

この節では、Tailscale が自動にしている「鍵の配布」「NAT 越え」「暗号化」「MTU」を、WireGuard だけで3台をつないで実物で確かめます。 Tailscale 本体ではなく、Tailscale が中で使っている WireGuard（wireguard-go）を手で設定して、同じ動きを見ています。

実験の構成

Linux の network namespace で次の形を作りました。203.0.113.0/24 は「インターネット」の役、A は家庭のルーター（NAT）の内側にいるノートPC の役です。

flowchart TD
    A[A ノートPC<br>192.168.88.10] --> NAT[家のルーター NAT<br>203.0.113.1]
    NAT --> NET[インターネット役<br>203.0.113.0/24]
    NET --- B[B サーバー<br>203.0.113.20]
    NET --- C[C サーバー<br>203.0.113.30]
    C --- NAS[C の裏の LAN<br>NAS 10.88.3.50]

WireGuard の上のアドレスは、Tailscale と同じ CGNAT の範囲から A＝100.88.0.1、B＝100.88.0.2、C＝100.88.0.3 にしました。家のルーターは、外から来た新しい通信を通さない設定です。

1. 鍵を作る（Tailscale では自動）

WireGuard は、端末ごとに秘密鍵と公開鍵を作ります。

$ wg genkey | tee a.key | wg pubkey
DjCkwfaoAw+1XYjufChk7RZzMi8ysAxWhDoAlrOtByQ=
$ wc -c a.key a.pub
45 a.key
45 a.pub

鍵はどちらも 44 文字の Base64（改行を含めて 45 バイト）です。WireGuard だけの場合、この公開鍵を相手の端末すべての設定に書き写します。3台なら設定の [Peer] は全部で6つ、10台なら90個です。Tailscale では、この配布を調整サーバーが行います。

2. NAT の内側の端末には、外から先に話しかけられない

B と C には「A の公開鍵」だけを登録し、A の住所（エンドポイント）は書きませんでした。家のルーターの内側にいる A の住所は、外からは分からないためです。この状態で B から A へ ping を送りました。

[B]$ ping -c 2 -W 1 100.88.0.1
PING 100.88.0.1 (100.88.0.1) 56(84) bytes of data.

--- 100.88.0.1 ping statistics ---
2 packets transmitted, 0 received, 100% packet loss, time 1025ms

[B]$ wg show wgb
peer: DjCkwfaoAw+1XYjufChk7RZzMi8ysAxWhDoAlrOtByQ=
  allowed ips: 100.88.0.1/32

A の行には endpoint がありません。B は A にどこへ送ればよいか分からず、パケットは届きませんでした。住所が分かっている B と C の間は、同じとき 0% の損失で応答しました。

3. 内側から話しかけると、外からも届くようになる

次に A に B と C の住所を登録し、25 秒ごとに空のパケットを送る設定（persistent keepalive）を付けました。

[A]$ ping -c 3 100.88.0.2
64 bytes from 100.88.0.2: icmp_seq=1 ttl=64 time=0.438 ms
64 bytes from 100.88.0.2: icmp_seq=2 ttl=64 time=0.567 ms
64 bytes from 100.88.0.2: icmp_seq=3 ttl=64 time=0.747 ms

その直後、さっき失敗した B から A への ping が通りました。

[B]$ ping -c 2 100.88.0.1
64 bytes from 100.88.0.1: icmp_seq=1 ttl=64 time=0.570 ms
64 bytes from 100.88.0.1: icmp_seq=2 ttl=64 time=0.693 ms

[B]$ wg show wgb
peer: DjCkwfaoAw+1XYjufChk7RZzMi8ysAxWhDoAlrOtByQ=
  endpoint: 203.0.113.1:28801
  allowed ips: 100.88.0.1/32
  latest handshake: 3 seconds ago
  transfer: 1.05 KiB received, 988 B sent

B が覚えた住所は、A の本当のアドレス（192.168.88.10）ではなく、家のルーターの外側の住所です。 WireGuard の公式サイトは、サーバー側は相手の住所を最初は知らず、正しく認証できたデータの送り元からそれを知る（Built-in Roaming）と説明しています。 今回は片方（B）が公開されたサーバーだったので、A から先に話しかけるだけでつながりました。両方が NAT の内側にいる場合は、両方が同時に相手へ送って NAT に穴を開ける必要があります。Tailscale はこれを、STUN（自分の外側の住所を調べる仕組み）と、調整サーバー経由の住所の交換で自動で行い、うまくいかないときは DERP で中継します。

A の設定は、WireGuard の書式では次のようになっていました（秘密鍵は省略）。

[Interface]
ListenPort = 28801
PrivateKey = (省略)

[Peer]
PublicKey = QDWkN9yzcpi6FByUzVZnhuqut+d2WpPP7f0kd4Q/gnc=
AllowedIPs = 100.88.0.2/32
Endpoint = 203.0.113.20:28802
PersistentKeepalive = 25

[Peer]
PublicKey = j1IhfHe9N8sDZ4u4nLYhkV7NLjUGl75xf3IhcIupRjg=
AllowedIPs = 100.88.0.3/32
Endpoint = 203.0.113.30:28803
PersistentKeepalive = 25

Tailscale を使うと、この [Peer] の中身（公開鍵・AllowedIPs・Endpoint）を、調整サーバーが各端末に配って書き換え続けます。

4. 経路の上では、中身は読めない

B で HTTP サーバーを動かし、A から WireGuard の上で token=s288-HELLO-OVER-TUNNEL という文字列を取得しました。同時に B の物理側（eth0）とトンネル側（wgb）でパケットを記録しました。

[A]$ curl -s http://100.88.0.2:28880/secret.txt
token=s288-HELLO-OVER-TUNNEL

物理側には、UDP のパケットしか見えませんでした。

IP 203.0.113.1.28801 > 203.0.113.20.28802: UDP, length 96
IP 203.0.113.20.28802 > 203.0.113.1.28801: UDP, length 96
IP 203.0.113.1.28801 > 203.0.113.20.28802: UDP, length 176
IP 203.0.113.20.28802 > 203.0.113.1.28801: UDP, length 272

トンネル側では、TCP の接続と HTTP のやり取りがそのまま見えました。

IP 100.88.0.1.33358 > 100.88.0.2.28880: Flags [S], seq 1954459096, win 64480, options [mss 1240,sackOK,TS val 588932380 ecr 0,nop,wscale 10], length 0
IP 100.88.0.1.33358 > 100.88.0.2.28880: Flags [P.], seq 1:90, ack 1, win 63, options [nop,nop,TS val 588932381 ecr 1543086391], length 89

記録したファイルの中から文字列を探した結果です。

$ grep -c s288-HELLO under.pcap over.pcap
under.pcap:0
over.pcap:1

経路の上（物理側）からは、文字列は1か所も見つかりませんでした。 Tailscale の DERP サーバーや Funnel の中継サーバーも、この暗号化された UDP を受け渡すだけなので中身を読めない、と公式ドキュメントにあります。

5. MTU 1280：大きいパケットはトンネルの中で小さくなる

Tailscale のソース（net/tstun/mtu.go）では、Tailscale のインターフェイス（Linux では tailscale0）の MTU の既定値は 1280 です。同じ 1280 を WireGuard に設定して確かめました。

[A]$ ping -c 1 -M do -s 1252 100.88.0.2
PING 100.88.0.2 (100.88.0.2) 1252(1280) bytes of data.
1260 bytes from 100.88.0.2: icmp_seq=1 ttl=64 time=0.575 ms

[A]$ ping -c 1 -M do -s 1253 100.88.0.2
PING 100.88.0.2 (100.88.0.2) 1253(1281) bytes of data.
ping: local error: message too long, mtu=1280

1280 バイトの ping は、物理側では UDP の中身が 1312 バイトになっていました。

IP 203.0.113.1.28801 > 203.0.113.20.28802: UDP, length 1312

ソースのコメントでは、WireGuard が足す大きさを「IPv6 ヘッダー 40・UDP 8・種別 4・鍵の番号 4・ナンス 8・認証タグ 16」の合計 80 バイトと見積もっています。1280 + 80 = 1360 なので、途中の経路の MTU が 1360 以上あれば分割されずに届きます。トンネルの中の TCP の MSS も、上の記録のとおり 1240（1280 − 40）でした。MTU と MSS の関係は、関連記事「ipconfigの使い方とMTUとは｜/all・/flushdnsとMTUの実例」で扱っています。

6. AllowedIPs：決まった送り元以外は受け取らない

WireGuard は、相手ごとに「この相手から来てよい送り元アドレス（AllowedIPs）」を持ちます。A に、B に登録していないアドレス 100.88.0.99 を足し、そこから B へ送りました。

[A]$ ping -c 2 -W 1 -I 100.88.0.99 100.88.0.2
--- 100.88.0.2 ping statistics ---
2 packets transmitted, 0 received, 100% packet loss, time 1019ms

[A]$ ping -c 2 -W 1 -I 100.88.0.1 100.88.0.2
2 packets transmitted, 2 received, 0% packet loss, time 1008ms

暗号化は正しくても、送り元が AllowedIPs に無いパケットを B は捨てました。WireGuard の公式サイトは、受け取るときの allowed IPs は "a sort of access control list"（一種のアクセス制御リスト）として働く、と書いています。Tailscale では、この AllowedIPs を調整サーバーが設定し、その上に ACL（grants）の判定を各端末で重ねています。

subnet router と exit node の設定

この節では、自宅 LAN の機器に入る subnet router と、通信の出口を変える exit node の設定と、それぞれで何が起きるかの実物が分かります。

subnet router：アプリを入れられない機器に届ける

公式ドキュメントの Linux の手順は、IP フォワーディング（転送）を有効にしてから、ルートを広告（advertise）します。

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.1.0/24

その後、管理コンソールの Machines で、その端末の Subnets の「Edit」からルートを承認します。Linux の利用側は、既定ではサブネットのルートを受け取りません。 sudo tailscale set --accept-routes が要ります。ソースでは --accept-routes の既定値は Windows・Android・iOS（と App Store 版などの macOS）で true、それ以外で false です。

WireGuard で同じことをしました。C を subnet router にし、A の C への AllowedIPs に 10.88.3.0/24 を足し、C で転送を有効にしました。

[A]$ curl -s -m 3 http://10.88.3.50:28881/ ; echo "exit=$?"
exit=7

[A]$ wg show wga allowed-ips
QDWkN9yzcpi6FByUzVZnhuqut+d2WpPP7f0kd4Q/gnc=    100.88.0.2/32
j1IhfHe9N8sDZ4u4nLYhkV7NLjUGl75xf3IhcIupRjg=    100.88.0.3/32 10.88.3.0/24

[A]$ ip route get 10.88.3.50
10.88.3.50 dev wga src 100.88.0.1 uid 0

[A]$ curl -s http://10.88.3.50:28881/
NAS ok

設定前は curl が exit=7（接続できない）で、設定後は NAS に届きました。NAS 側のアクセスログで、送り元がどう見えるかを比べました。

公式ドキュメントでは、Tailscale の subnet router は既定で送り元を subnet router 自身のアドレスに書き換えます。 書き換えをやめると、LAN の機器から元の Tailscale IP が見えますが、LAN の機器（またはそのルーター）に「100.64.0.0/10 への戻りは subnet router の LAN 側の IP へ」というルートが要ります。今回の実験で SNAT なしでも返事が届いたのは、NAS の既定のゲートウェイが C だったためです。

exit node：インターネットへの出口を変える

exit node は、インターネット向けの通信（0.0.0.0/0・::/0）を tailnet の1台に任せる機能です。公式ドキュメントの流れは次のとおりです。

1. exit node にする端末で、IP フォワーディングを有効にし、sudo tailscale set --advertise-exit-node を実行する（Android は「Run as exit node」）
2. 管理コンソールの Machines で「Edit exit node」→「Use as exit node」を選んで承認する
3. 使う側で exit node を選ぶ（CLI は tailscale set --exit-node=マシン名、解除は --exit-node=）
4. 自分の LAN のプリンターなどにも届けたいときは --exit-node-allow-lan-access を付ける

WireGuard で、B を exit node にして確かめました。A の B への AllowedIPs に 0.0.0.0/0 を足し、A の既定の経路をトンネルに向け、B で送り元を書き換えます。Web サーバー（203.0.113.80）のアクセスログの送り元が変わりました。

WEB log (exit nodeなし):
203.0.113.1 - - [22/Oct/2026 18:20:36] "GET / HTTP/1.1" 200 -
WEB log (exit node=B):
203.0.113.20 - - [22/Oct/2026 18:20:36] "GET / HTTP/1.1" 200 -

[A]$ ip route
default dev wga scope link
10.88.3.0/24 dev wga scope link
100.88.0.0/24 dev wga proto kernel scope link src 100.88.0.1
192.168.88.0/24 dev eth0 proto kernel scope link src 192.168.88.10
203.0.113.20 via 192.168.88.1 dev eth0
203.0.113.30 via 192.168.88.1 dev eth0

既定の経路をトンネルに向けても、WireGuard 自身が相手（B・C）に送る UDP は物理側の経路に残す必要があります。 上の最後の2行がそれです。手で書くとここを間違えて通信が全部止まりやすく、Tailscale はこの経路の調整を自動で行います。既定の経路の仕組みは、関連記事「デフォルトゲートウェイとは｜調べ方・設定・決め方をLinuxで実演」で扱っています。

公式ドキュメントには、exit node・subnet router の注意点として次の2つがあります。

• ノードキーが期限切れになると、広告したルートは他の端末に残ったまま届かなくなる（"fail close"）。 中継に使う端末は、管理コンソールで「Disable Key Expiry」にするか、複数台で冗長にします。
• ポリシーを独自に書いている場合、exit node を使うには dst が autogroup:internet の許可が要る。

ACL（grants）でアクセスを絞る

この節では、tailnet の中で「誰がどこに届くか」を決めるポリシーの書き方が分かります。 公式ドキュメントでは、新しい tailnet の既定のポリシーは tailnet 内のすべての端末同士の通信を許可 します。現在は grants という新しい書き方が推奨で、従来の acls も引き続き動きますが、新機能は grants にだけ足されます。

全部を許可する形（公式の例）です。

{
  "grants": [
    { "src": ["*"], "dst": ["*"], "ip": ["*"] }
  ]
}

チームで使うときの形の例です。公式の例（グループからタグの特定ポートへの許可、exit node の許可）を組み合わせています。

{
  "groups": {
    "group:dev": ["alice@example.com", "bob@example.com"]
  },
  "tagOwners": {
    "tag:server": ["group:dev"]
  },
  "grants": [
    { "src": ["group:dev"], "dst": ["tag:server"], "ip": ["tcp:22", "tcp:443"] },
    { "src": ["autogroup:member"], "dst": ["autogroup:internet"], "ip": ["*"] }
  ]
}

公式ドキュメントの ACL の原則は「既定で拒否・向きがある（A→B を許しても B→A は別）・各端末で判定・ローカルの LAN の通信には影響しない」です。ポリシーは HuJSON（コメントと末尾のカンマを書ける JSON）で書きます。

Tailscale SSH を使うときは、ポート22への通信の許可に加えて、ssh の節で「誰が・どの端末に・どのユーザー名で」入れるかを書きます。接続される側で tailscale set --ssh を実行すると、Tailscale がその端末の Tailscale IP のポート22を受け持ちます。/etc/ssh/sshd_config は変わりません。

Serve と Funnel：tailnet内とインターネットへの公開

この節では、手元の Web サーバーを見せる2つの方法の違いが分かります。

どちらも tailnet で HTTPS（証明書）を有効にする必要があります。Funnel はさらに MagicDNS の有効化と、ポリシーの nodeAttrs の funnel 属性が要ります（初回に tailscale funnel を実行すると、画面の案内で有効にできます）。

公式ドキュメントにある Serve の実行例です。

$ tailscale serve 3000
Available within your tailnet:
https://amelie-workstation.pango-lin.ts.net

|-- / proxy http://127.0.0.1:3000

Press Ctrl+C to exit.

同じポートを Serve と Funnel の両方に使うことはできず、最後に実行した方（serve なら非公開、funnel なら公開）になります。Funnel の公開用の DNS が反映されるまで最大10分かかることがあります。Funnel で公開したものはインターネットの誰でも見られるので、認証の無い管理画面や開発用のサーバーを出さないことが前提です。

Tailscaleは安全？危険と言われる理由と見直す設定

この節では、Tailscale の安全の仕組みと、導入後に見直す設定が分かります。 暗号化については、前の実験のとおり経路の上では中身が見えず、DERP の中継も中身を読めません。一方で、次の点は仕組みとして知っておく必要があります。

公式のセキュリティ公報のページでは、2026年10月21日の TS-2026-013 で v1.104.2 以降への更新が案内されています。

Tailscale 経由で入れるようにしたサーバーは、インターネット側の SSH の受け口を閉じると、攻撃の入口を減らせます。ファイアウォールの設定は関連記事「ufwとfirewalldの使い方｜コマンド対応表とSSH締め出し対策」で、SSH の接続の書き方は関連記事「ssh コマンドの使い方まとめ｜鍵・ポート指定・config・接続エラー対処」で扱っています。

Tailscaleが遅いとき・つながらないとき（エラーと直し方）

この節では、遅い・つながらないときの切り分けと、よく出るメッセージの意味が分かります。

遅いときは「直接」か「中継」かを見る

公式ドキュメントでは、両端が難しいネットワークにいて直接つながらないとき、DERP の中継を通り、直接より遅くなります。tailscale status で relay "…"、tailscale ping で via DERP(…) と出ていれば中継です。

公式が推奨するファイアウォールの設定は次のとおりです。多くの場合、ポートを開ける（受け入れる）設定は要りません。

tailscale netcheck で、UDP が通るか・NAT の種類・いちばん近い DERP とその遅延を確かめられます。宛先ごとに外側のポートが変わる NAT（hard NAT）では直接つながりにくく、中継に頼ることになります。UDP のポートは、公式ドキュメントでは既定 41641 で、Linux は /etc/default/tailscaled の FLAGS、Windows は tailscaled-env.txt の PORT=N で変えられます。ソースでは、Windows の既定が 41641、ほかの OS は環境変数 PORT（Linux の systemd の設定が渡す値）が無ければ空いているポートを自動で選びます。

よく出るメッセージと直し方

メッセージの文言は、Tailscale のソース（1.105.0 の開発版）にあるものです。

そのほかのつまずき

• MagicDNS の名前が Mac の nslookup・host で引けない：公式ドキュメントに、これらのツールはシステムの名前解決を通らないので MagicDNS では動かない、とあります。ping マシン名 やブラウザで確かめるか、tailscale dns query マシン名 を使います。
• ほかの VPN と同時に使うとつながらない：Tailscale の 100.64.0.0/10 は、同じ範囲を使うほかの VPN と重なることがある、と公式ドキュメントにあります。
• Linux で subnet router の先に届かない：利用側の --accept-routes、管理コンソールでのルートの承認、ポリシーでの許可の3つがそろっているかを見ます。公式ドキュメントは、ルートの承認は「どのルートを経路表に入れるか」、アクセスのルールは「どの通信を許すか」で、別の仕組みだと説明しています。
• しばらく使わなかった端末に届かない：ノードキーの既定の期限は180日です。期限が切れると、再認証するまでその端末との通信が止まります。

ネットワークの切り分けに使う ip・ss などのコマンドは、関連記事「Linuxネットワークコマンド一覧｜ip/ss/ncで障害切り分け」で扱っています。

Tailscaleとほかの方法の違い（WireGuard単体・Headscale・従来のVPN）

この節では、Tailscale 以外の選び方と、それぞれが向く場面が事実の表で分かります。

Headscale の README には、"An open source, self-hosted implementation of the Tailscale control server." とあり、扱える tailnet は1つで、"This project is not associated with Tailscale Inc." と明記されています。端末側は Tailscale のクライアントを使います。

よくある質問

Q. Tailscale とは何ですか？ A. WireGuard を使って、パソコン・スマホ・サーバーを1つの私設ネットワーク（tailnet）にまとめる VPN です。鍵の配布と相手の住所探しを自動で行い、端末同士が直接通信します。「Tailscaleとは」の節に仕組みの要点があります。

Q. Tailscale は無料で使えますか？商用利用は？ A. 無料の Personal プランは6ユーザーまで、ユーザーの端末は数の制限なしで使えます。ただし非商用向けです。仕事で使う場合は Standard（1ユーザー月8ドル）以上が対象です（2026年10月22日時点）。

Q. Tailscale と普通の VPN は何が違いますか？ A. 普通の VPN はすべての通信が中央の装置を通りますが、Tailscale は端末同士が直接つながるメッシュ型です。ポート開放が多くの場合要らず、ログインには既存の Google・Microsoft などのアカウントを使います。

Q. Tailscale と WireGuard の関係は？ A. Tailscale の通信そのものは WireGuard です。Tailscale は、WireGuard で手作業になる鍵の配布・エンドポイントの更新・NAT 越え・ACL・名前解決を自動にしています。この記事では WireGuard だけで3台をつなぎ、その違いを実物で見せています。

Q. Tailscale は危険ですか？通信を Tailscale 社に見られますか？ A. 秘密鍵は端末から出ず、DERP の中継も中身を読めない設計です。一方、既定のポリシーは全許可で、調整サーバーを信頼する形なので、grants での制限・Tailnet Lock・端末の承認・更新の管理が見直す点です。「Tailscaleは安全？」の節にチェックリストがあります。

Q. Tailscale が遅いのはなぜですか？ A. 直接つながらず DERP の中継を通っている可能性があります。tailscale status で relay と出ていないか、tailscale netcheck で UDP が通るかを確かめ、UDP 41641・3478 の外向きを許可します。

Q. ルーターのポート開放は必要ですか？ A. 公式ドキュメントでは、多くの場合ポートを開ける必要は無く、NAT 越えで自動的につながります。直接つながらないときは中継で通信が続きます。

Q. 自宅の NAS やリモートデスクトップに外から入れますか？ A. 入れます。PC に Tailscale を入れればマシン名か 100.x.y.z でリモートデスクトップにつなげます。アプリを入れられない NAS などは、同じ LAN の1台を subnet router にして届けます。

Q. exit node とは何ですか？ A. インターネット向けの通信を tailnet の1台に任せる機能です。外出先から自宅の回線を通して Web を見るときなどに使います。実験では、Web サーバーのログの送り元が 203.0.113.1 から exit node の 203.0.113.20 に変わりました。

Q. MagicDNS で名前が引けません。 A. MagicDNS が有効か（管理コンソールの DNS の画面）、端末が Tailscale の DNS 設定を使っているかを確かめます。Mac の nslookup・host はシステムの名前解決を通らないので、ping マシン名 などで確かめます。

Q. Headscale とは何ですか？ A. Tailscale の調整サーバーを自分で運用するためのオープンソース実装です。Tailscale 社のプロジェクトではなく、1つの tailnet を扱います。

Q. Tailscale の IP アドレスは変わりますか？ A. 端末ごとに 100.64.0.0/10 から付き、場所や回線が変わっても変わりません。IPv6 は fd7a:115c:a1e0::/48 の範囲です。

まとめ

• Tailscale は、WireGuard で端末同士を直接つなぎ、鍵の配布・住所探し・NAT 越え・アクセス制御を自動にした VPN。通信の中身は調整サーバーを通らない。
• 従来の VPN は中央の装置を通る形、Tailscale はメッシュ。直接つながらないときは DERP で暗号化したまま中継する。
• 無料の Personal は6ユーザーまで・非商用。仕事は Standard 以上（2026年10月22日時点）。
• WireGuard だけで再現すると、NAT の内側の端末には外から先に届かず、内側から話しかけた後に住所（203.0.113.1:28801）を覚えて届いた。経路の上では文字列は0件、トンネルの MTU は 1280。
• subnet router は既定で送り元を書き換え（NAS からは 10.88.3.1 に見えた）、exit node は出口の IP を変える（203.0.113.20 に変わった）。
• 導入後は、全許可のポリシーを grants で絞り、タグ・auth key の期限・クライアントの更新を見直す。

参考・出典

確認日はいずれも 2026年10月22日です。

• Tailscale「How Tailscale works」：https://tailscale.com/blog/how-tailscale-works
• Tailscale「Pricing」：https://tailscale.com/pricing
• Tailscale「Tailscale CLI」：https://tailscale.com/kb/1080/cli
• Tailscale「Install Tailscale on Linux」：https://tailscale.com/kb/1031/install-linux
• Tailscale「Install Tailscale on Windows」：https://tailscale.com/kb/1022/install-windows
• Tailscale「Install Tailscale on macOS」：https://tailscale.com/kb/1016/install-mac
• Tailscale「Install Tailscale on iOS」：https://tailscale.com/kb/1020/install-ios
• Tailscale「Install Tailscale on Android」：https://tailscale.com/kb/1079/install-android
• Tailscale「MagicDNS」：https://tailscale.com/kb/1081/magicdns
• Tailscale「DNS in Tailscale」：https://tailscale.com/kb/1054/dns
• Tailscale「Tailscale IP addresses」：https://tailscale.com/kb/1015/100.x-addresses
• Tailscale「Exit nodes」：https://tailscale.com/kb/1103/exit-nodes
• Tailscale「Subnet routers」：https://tailscale.com/kb/1019/subnets
• Tailscale「Manage permissions using ACLs」：https://tailscale.com/kb/1018/acls
• Tailscale「Grants」：https://tailscale.com/kb/1324/grants
• Tailscale「Grant examples」：https://tailscale.com/docs/reference/examples/grants
• Tailscale「Tailscale Serve」：https://tailscale.com/kb/1312/serve
• Tailscale「Tailscale Funnel」：https://tailscale.com/kb/1223/funnel
• Tailscale「Tailscale SSH」：https://tailscale.com/kb/1193/tailscale-ssh
• Tailscale「Taildrop」：https://tailscale.com/kb/1106/taildrop
• Tailscale「Sharing your nodes with other users」：https://tailscale.com/kb/1084/sharing
• Tailscale「Auth keys」：https://tailscale.com/kb/1085/auth-keys
• Tailscale「Key expiry」：https://tailscale.com/kb/1028/key-expiry
• Tailscale「Tailnet Lock」：https://tailscale.com/kb/1226/tailnet-lock
• Tailscale「What firewall ports should I open to use Tailscale?」：https://tailscale.com/kb/1082/firewall-ports
• Tailscale「Tailscale vs. WireGuard」：https://tailscale.com/compare/wireguard
• Tailscale「Security bulletins」：https://tailscale.com/security-bulletins
• Tailscale「Changelog」：https://tailscale.com/changelog
• GitHub tailscale/tailscale（cmd/tailscale/cli・net/tstun/mtu.go・net/tsaddr/tsaddr.go・cmd/tailscaled/tailscaled.go）：https://github.com/tailscale/tailscale
• GitHub juanfont/headscale：https://github.com/juanfont/headscale
• WireGuard（Built-in Roaming・Cryptokey Routing）：https://www.wireguard.com/
• RFC 6598 IANA-Reserved IPv4 Prefix for Shared Address Space：https://www.rfc-editor.org/rfc/rfc6598

株式会社RJC ― SI事業・SES事業・AI駆動開発。RJCは一緒に成長を楽しめる会社です。