著者 VPSをTailscaleのexit nodeにする方法
VPSにTailscaleをインストールし、exit nodeの広告、IP forwarding、管理コンソールでのルート承認まで設定します。DNSとIPv6の注意点も確認できます。
Tailscale の exit node が行うこと
Tailscale の exit node は、tailnet 上の他のデバイスのインターネットトラフィックをすべて転送するマシンです。VPS (virtual private server) は、固定されたパブリックアドレスを持ち、常時オンラインであるため、exit node に適しています。設定は 5 つの手順で行います。サーバーに Tailscale をインストールし、exit node を広告し、IP forwarding を有効にし、管理コンソールでルートを承認してから、ラップトップでそのノードを選択します。4 番目の手順は Web ページ上のトグルであり、コマンドではありません。ここで止まる人が最も多くなります。
有効にすると、ラップトップはすべてのパケットを暗号化して VPS に送信します。VPS は source NAT (network address translation) を適用し、自身のパブリック IP アドレスでパケットを送信します。Web サイトからは VPS がアクセス元に見えます。カフェの Wi-Fi からは、VPS への暗号化された UDP フローが 1 本見えるだけで、その他の通信は見えません。
Tailscale は、データパスに WireGuard を使用し、鍵を配布して NAT 越しに 2 台のマシンが互いを検出できるようにする coordination server を組み合わせています。この coordination server があるため、以下の手順では鍵をどこにもコピーしません。トレードオフの詳細については、Tailscale と通常の WireGuard の比較 を参照してください。トンネルのすべての要素を自分で管理したい場合は、代わりに VPS で通常の WireGuard VPN をセルフホストする 方法を利用してください。
以下の手順では、ラップトップですでに Tailscale が動作しており、両方のマシンが同じ tailnet にサインインしていることを前提とします。tailnet はプライベートな Tailscale ネットワークです。その中のすべてのデバイスには、100.64.0.0/10 内部の安定したアドレスが割り当てられます。
VPS に Tailscale をインストールする
curl -fsSL https://tailscale.com/install.sh | sh
sudo tailscale upインストールスクリプトは、ディストリビューションに対応するパッケージリポジトリを選択し、tailscaled デーモンをインストールします。続いて tailscale up が認証 URL を表示します。ブラウザーで URL を開き、ノート PC と同じアカウントでサインインしてください。VPS が別の tailnet にサインインしていると、ノート PC にサービスを提供できません。
tailscale status
tailscale ip -4tailscale status を実行すると、両方のマシンが一覧表示されます。tailscale ip -4 は VPS の tailnet アドレスを表示します。後でクライアントにこのアドレスを指定します。
Tailscale はトンネルを構築するために TUN デバイスを必要とします。KVM VPS では、このデバイスが用意されています。ホストカーネルを共有するコンテナ仮想化ベースのプランでは、/dev/net/tun が存在しない場合があります。その場合、tailscaled は tailscale0 インターフェースを作成できません。先に ls -l /dev/net/tun を実行してください。
IP forwarding を有効にしないと、VPS はすべてのパケットを破棄します
Linux マシンは、自身宛てではないパケットを破棄します。これは、net.ipv4.ip_forward の初期値が 0 だからです。Exit node はトラフィックを受信して復号しますが、その後で破棄してしまいます。再起動後も設定が維持されるように、設定をファイルに書き込みます。
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.conftee -a は追記するため、これらの行を2回目に実行すると、両方の設定が2回ずつ書き込まれます。結果は引き続き機能しますが、cat /etc/sysctl.d/99-tailscale.conf の表示は不自然になります。ファイルの内容をそのまま信頼せず、現在有効な値を確認します。
sysctl net.ipv4.ip_forwardnet.ipv4.ip_forward = 1 と表示される必要があります。この確認を省略して tailscale up --advertise-exit-node を使用すると、クライアントは次のように表示します。
Warning: IP forwarding is disabled, subnet routing/exit nodes will not work.tailscale set --advertise-exit-node はこの確認を実行しません。そのため、set に何も表示されなくても、IP forwarding が有効である証拠にはなりません。sysctl の値を自分で読み取ります。
masquerade ルールを手動で書く必要はありません。tailscaled は独自の firewall chain をインストールします。chain 名は ts-input、ts-forward、ts-postrouting です。Exit node のトラフィックに対する NAT ルールは ts-postrouting にあります。sudo iptables-save | grep ts- で確認します。nftables を使用するホストでは sudo nft list ruleset を使用します。
VPS を exit node として広告する
sudo tailscale set --advertise-exit-nodetailscale set は 1 つの設定だけを変更し、その他の設定はそのままにします。tailscale up --advertise-exit-node もノードを広告しますが、副作用があります。up は、コマンドラインで指定されたフラグをデフォルト以外の設定の完全な一覧として扱うため、その後に引数なしの sudo tailscale up を実行すると拒否され、次のメッセージを表示します。
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:継続的な変更には set を使用してください。このメッセージが表示されることはありません。
広告とは、利用を申し出ることです。VPS は、exit node として利用できることを調整サーバーに通知する状態になります。まだ、どのクライアントもこの VPS を利用できません。
Tailscale の exit node を管理コンソールで承認する
この手順には実行するコマンドがありません。管理コンソールの Machines ページを開き、VPS を見つけます。行の末尾にある 3 点メニューを開き、Edit route settings を選択して、Use as exit node を有効にします。
この切り替えを有効にするまで、コントロールプレーンはこの要求を保留し、どのユーザーにも割り当てません。ノート PC の tailscale exit-node list には何も表示されず、ネットワークトラフィックも通常の経路を通り続けます。どちらのマシンにもエラーメッセージは表示されません。exit node は表示されないままです。
tailnet policy ファイルにエントリを追加すると、exit node を自動的に承認できます。
"autoApprovers": {
"exitNode": ["tag:exit"],
}--advertise-tags=tag:exit で起動したデバイスは、同じ policy ファイルの tagOwners の下に tag:exit が定義されていれば、自動的に承認されます。タグを付けると所有者が変わります。タグ付きデバイスはユーザーアカウントではなく tailnet に属し、それに伴って適用されるアクセスルールも変わります。1 台の VPS であれば、切り替えを使うほうが簡単です。
ラップトップで exit node を選択する
Linux クライアントでは、次のコマンドを実行します。
tailscale exit-node list
sudo tailscale set --exit-node=vps.your-tailnet.ts.netexit-node list は、tailnet で承認済みの exit node とそのアドレスを表示します。空のリストが表示される場合、承認手順が完了していません。macOS、Windows、iOS、Android では、Tailscale アプリの Exit Node の下にあるメニュー項目から同じ選択を行います。
確認はサーバーではなく、必ずクライアントから実行します。
curl -4 https://ifconfig.meexit node を選択する前と、選択した後に 1 回ずつ実行します。アドレスがローカルのアドレスから VPS のパブリック IP に変わることを確認します。exit node の使用を停止するには、次を実行します。
sudo tailscale set --exit-node=初日に設定しておくべきフラグがもう 1 つあります。exit node を選択すると、クライアントは 192.168.1.50 宛てのパケットを含め、すべての通信をトンネルに送信します。そのため、プリンターやネットワークストレージが応答しなくなります。ローカルネットワークにはローカルルートを使用します。
sudo tailscale set --exit-node=<name> --exit-node-allow-lan-access=trueexit node を有効にすると DNS が変わる理由
デフォルトでは、exit node を使用するデバイスは、すべてのドメインの DNS（domain name system）リゾルバーとしてもその exit node を使用します。これにより、tailnet に設定したグローバル DNS と split DNS のネームサーバーは上書きされます。これは意図された動作です。クエリがローカルネットワークのリゾルバーに送られ続けると、通信自体はプライベートでも、カフェのルーターにはアクセスしたすべてのサイト名が見えてしまいます。名前解決とパケットは、同じ場所から送信されるべきです。
内部リゾルバーを運用している場合、この動作が問題になることがあります。依存している tailnet のネームサーバーが、exit node の有効化中は使用されなくなるためです。管理コンソールの DNS ページで、そのネームサーバーの Use with exit node を有効にすると、再び使用できます。
MagicDNS の名前は引き続き機能します。Tailscale クライアントが、exit node に到達する前に 100.100.100.100 でローカルに応答するためです。dig @100.100.100.100 your-vps.your-tailnet.ts.net で確認できます。systemd-resolved クライアントでは resolvectl status を使用すると、Tailscale インターフェースが 100.100.100.100 を DNS サーバーとして登録していることを確認できます。
--accept-dns=false で Tailscale の DNS 処理を無効にすると、クライアントはローカルネットワークから取得したリゾルバーを使い続けます。通信はトンネル化されますが、DNS クエリはトンネル化されません。これは、手動で構築した WireGuard トンネルで発生するものと同じ DNS リークです。変更する明確な理由がない限り、--accept-dns はそのままにしてください。
IPv6 の出口ノード経由
出口ノードは、0.0.0.0/0 と ::/0 の両方のデフォルトルートを通知します。VPS にインターネットへの IPv6 経路がない場合、IPv6 パケットはトンネル経由で到着した後、そこで停止します。信頼する前に、VPS 上で確認してください。
ip -6 addr show
curl -6 https://ifconfig.meリクエストが失敗する場合、VPS には IPv6 の上流経路がありません。デュアルスタックの Web サイトは通常、引き続き読み込めます。クライアントが IPv6 を断念し、IPv4 で再試行するためです。ただし、この再試行により、各サイトへの初回接続で遅延が発生します。IPv6 専用の宛先には接続できません。
もう一方の要素は転送です。net.ipv4.ip_forward = 1 のまま net.ipv6.conf.all.forwarding を 0 にすると、IPv4 の経路は機能しますが、IPv6 はブラックホールになります。利用者にはエラーとして表示されず、「一部のサイトが遅い」という症状になります。そのため、検索で原因を特定しにくくなります。両方の行を sysctl ファイルに記述してください。
VPS はサブネットルートも広告すべきですか？
exit node はすべてのインターネットトラフィックを転送します。サブネットルートは、広告元のマシンの背後にある 1 つのプライベート範囲への経路です。これらは別々の機能であり、承認も別々に必要です。1 台のマシンで両方を利用できます。
sudo tailscale set --advertise-routes=10.0.0.0/24VPS が、プライベートアドレスで接続したい他のサーバーとプライベートネットワークを共有している場合は、サブネットを広告します。同じ Edit route settings パネルで、専用のトグルを使って承認します。
範囲は慎重に選んでください。広告された経路は、ラップトップのデフォルトルートより具体的です。そのため、VPS から 192.168.1.0/24 を広告すると、同じ範囲を使用する自宅ネットワークのアドレスがその経路に奪われ、手元のデバイスに接続できなくなります。自分で選んだ範囲を使用し、自宅のルーターが自動的に選んだ範囲は避けてください。
UDP GRO フォワーディングで exit node を高速化する
Linux 6.2 以降のカーネルで Tailscale 1.54 以降を使用すると、受信オフロードによってフォワーディングトラフィックのスループットを向上できます。GRO（generic receive offload）は、カーネルがパケットを 1 つずつ処理する前に、受信パケットを結合します。2026 年 8 月時点では、exit node で手動設定が必要です。
sudo apt install -y ethtool
NETDEV=$(ip -o route get 8.8.8.8 | cut -f 5 -d " ")
sudo ethtool -K $NETDEV rx-udp-gro-forwarding on rx-gro-list offip -o route get 8.8.8.8 は実際にインターネットへ接続しているインターフェースを表示するため、eth0、ens3、enp1s0 のどれかを推測する必要はありません。ethtool -k $NETDEV | grep udp-gro-forwarding で確認します。結果は on になっているはずです。
この設定は再起動時に失われます。networkd-dispatcher を実行しているシステムでは、自動化します。
printf '#!/bin/sh\n\nethtool -K %s rx-udp-gro-forwarding on rx-gro-list off \n' "$(ip -o route get 8.8.8.8 | cut -f 5 -d " ")" | sudo tee /etc/networkd-dispatcher/routable.d/50-tailscale
sudo chmod 755 /etc/networkd-dispatcher/routable.d/50-tailscale最初に /etc/networkd-dispatcher/routable.d/ が存在することを確認します。存在しない場合、そのマシンでは networkd-dispatcher が実行されていません。その場合は、起動時に ethtool の行を実行する小さな systemd unit で同じ処理を行えます。
出口トラフィックに関するプロバイダーの利用規約の意味
クライアントが出口ノード経由で送信するすべてのパケットは、VPS のパブリック IP アドレスから送信されたものとして扱われるため、あなたのアカウントに紐付けられます。著作権侵害の通知やポートスキャンに関する苦情などの不正利用報告は、あなたの受信トレイに届きます。家庭内の利用者やチームを 1 台のサーバー経由で接続する前に、プロバイダーの AUP（acceptable use policy）を確認してください。責任を持って管理できない利用者には、出口ノードを公開しないでください。
帯域幅は 2 回分として計上されます。トラフィックはトンネル経由で VPS に到着し、その後インターネットへ再び送信されます。通常は、両方向の通信がプランの転送量に加算されます。出口ノード経由で視聴する動画ストリームは、多くの人が想定するより大きな転送量になります。
データセンターの IP アドレス帯には、評判も影響します。一部のサイトでは CAPTCHA の表示が増え、一部のストリーミングサービスでは接続を完全に拒否されます。これは、プロバイダーが所有するアドレスブロックの性質によるものです。設定を変更しても、この点は変わりません。
ローカル接続経由でネットワークトラフィックが流れ続ける理由
出口ノードとして広告されていますが、承認されていません。 クライアントで tailscale exit-node list を実行しても何も表示されず、どちらのマシンにもエラーは記録されません。Machines ページを開き、Use as exit node を有効にします。
クライアントが出口ノードを選択していません。 承認すると、そのノードを tailnet で利用できるようになります。ノードの選択は、各デバイスで別途行う必要があります。sudo tailscale set --exit-node=<name> を再実行し、その後 curl -4 https://ifconfig.me をもう一度確認します。
フォワーディングが無効です。 症状は明確です。tailscale ping <vps> は成功し、トンネルも確立されていますが、外部のすべてのアドレスがタイムアウトします。sysctl net.ipv4.ip_forward の値は 0 です。sysctl ファイルを修正し、sudo sysctl -p /etc/sysctl.d/99-tailscale.conf を実行します。
ファイアウォールが転送パケットを破棄しています。 tailscaled は独自の ts-forward チェーンを追加するため、初期状態の VPS では通常これだけで十分です。ufw または Docker がすでに動作しているホストでは、FORWARD ポリシーが DROP になり、Tailscale のルールより前に別のルールが配置されることがあります。推測で判断せず、クライアントがページを読み込もうとしている間に sudo iptables -L FORWARD -n -v を実行し、どのカウンターが増えるかを確認します。ufw を使用しているホストでは、通常、/etc/default/ufw 内で DEFAULT_FORWARD_POLICY="ACCEPT" を設定し、その後 sudo ufw reload を実行します。プロバイダーのネットワークファイアウォールもコントロールパネルで確認してください。これはサーバー上で動作しているファイアウォールとは別の制御です。
動作しますが、速度が遅いです。 両方のマシンで tailscale netcheck を実行します。UDP がブロックされていると表示される場合、2 台のデバイスは直接経路を構築できず、DERP リレーにフォールバックします。そのため、すべての接続で遅延が発生します。プロバイダーのネットワークファイアウォールで、VPS への inbound UDP のポート 41641 を許可すると、通常は直接経路が復元します。
Tailscale の調整サーバーから切り替える場合
ここまでの構成では、鍵交換とクリックした承認に Tailscale のホスト型調整サーバーを使用しています。通信は引き続きラップトップから VPS へ直接送られ、調整サーバーを経由しません。ただし、どのユーザーが tailnet に参加できるか、各デバイスからどこへアクセスできるかは調整サーバーが決定します。この依存関係をなくしたい場合は、独自の Tailscale コントロールサーバーとして Headscale を実行するし、両方のクライアントを Headscale に接続します。その後の exit node の手順は同じですが、経路の承認はホスト型コンソールではなく Headscale のコマンドラインで行います。Headscale はコントロールプレーンを置き換えますが、Tailscale クライアントは引き続き使用します。スタック全体を自分で運用したい場合は、NetBird が独自の調整サーバーとクライアントを提供しており、1 台の VPS でホストできます。
FAQ
Exit node を選択した後も、ネットワークトラフィックがローカル接続を使用するのはなぜですか？
主な原因は 2 つあります。1 つ目は、Exit node が広告されたものの、承認されていないことです。管理コンソールで Machines ページを開き、VPS を見つけて Edit route settings を選択し、Use as exit node を有効にします。承認はコンソールの切り替え操作で行い、サーバー上のコマンドでは実行できません。2 つ目の原因は異なる症状を示します。IP forwarding が無効なため、トンネルは確立し、tailscale ping で VPS には接続できますが、外部のすべてのアドレスがタイムアウトします。sysctl net.ipv4.ip_forward で確認してください。値は 1 である必要があります。
Exit node は毎回手動で承認する必要がありますか？
切り替え操作は、各マシンで 1 回だけ行います。VPS を頻繁に再構築する場合は、tailnet のポリシーファイルに autoApprovers ブロックを追加し、"exitNode": ["tag:exit"] を含めます。tagOwners の下に tag:exit を定義し、--advertise-tags=tag:exit で node を起動します。タグ付きデバイスはユーザーアカウントではなく tailnet によって所有されるため、そのデバイスに適用されるアクセスルールも変わります。
Exit node の使用中、ノート PC はどの DNS サーバーを使用しますか？
Exit node 自体です。Exit node を使用するデバイスは、すべての DNS クエリをそこへ送信します。これにより、tailnet に設定されたグローバル DNS および split DNS のネームサーバーが上書きされます。ローカルネットワークから、検索した名前を見られなくなります。tailnet のネームサーバーを 1 つ適用し続けるには、管理コンソールの DNS ページで、そのネームサーバーに対して Use with exit node を有効にします。MagicDNS の名前は引き続き解決されます。Tailscale クライアントが 100.100.100.100 でローカルに応答するためです。
1 台の VPS を Exit node と subnet router として同時に使用できますか？
はい。sudo tailscale set --advertise-exit-node と sudo tailscale set --advertise-routes=10.0.0.0/24 は独立しており、それぞれに Edit route settings の下で個別の承認切り替えがあります。VPS では両方とも IP forwarding を有効にする必要があります。ノート PC の自宅ネットワークと一致する範囲を広告しないでください。広告された route はデフォルト route より具体的であるため、ローカルデバイスに到達できなくなります。
Exit node によって VPS プロバイダーからネットワークトラフィックを隠せますか？
いいえ。トンネルは VPS で終端するため、トラフィックは宛先が要求する形式でサーバーから送信されます。そのため、サイト自体が暗号化していない範囲では、プロバイダーはトラフィックを平文で転送します。Exit node は、ネットワークトラフィックがインターネットへ接続する地点を、現在接続しているネットワークからレンタルしたサーバーへ移します。これにより、カフェの Wi-Fi や自宅の ISP から閲覧内容を隠せます。一方で、同じ閲覧内容はアカウント名とともに VPS プロバイダーから見える状態になります。