個人で VPS を動かしていると、いつか必ずぶつかるのが「SSH をどう守るか」です。公開ポートのまま鍵認証にしておく、fail2ban を入れる、接続元 IP を絞る……どれも有効ですが、自宅や出先の回線が変わるたびにメンテが必要になります。そこで導入したのが Tailscale です。

Tailscale とは何か

Tailscale は、端末どうしを仮想的なプライベートネットワークでつなぐサービスです。裏側では WireGuard を使い、各端末に 100.x.y.z 形式のアドレスが振られます。自分の PC・スマホ・サーバーを同じ「tailnet」に入れると、インターネット越しでもあたかも同じ LAN にいるようにアクセスできます。

従来の VPN のように「社内ゲートウェイに全部つなぐ」イメージではなく、端末同士が直接（またはリレー経由で）つながる点がわかりやすいです。個人用途でも、無料枠で十分試せます。

うれしいところ

  • ルーターのポート開放や固定 IP がなくてもつながる
  • 端末ごとにログインして参加するだけなので、設定が軽い
  • ACL で「誰が何に触れるか」を後から整理しやすい

逆に、コントロールプレーンは Tailscale 側に置くことになるので、「完全に自前で閉じて運用したい」人には向かない面もあります。個人サーバー運用では、そのトレードオフを受け入れやすいと感じました。

自分がやりたかったこと

やりたかったのは単純で、SSH（22番）をインターネットに晒さないことです。ファイル転送用の SFTP は別ポートで公開する必要がある場面もありましたが、通常ログイン用の SSH は Tailscale 経由だけにしました。

公開側に出す面を減らすと、スキャナからのノイズが減り、鍵の扱い以外の心配がかなり軽くなります。「どこからでも同じ手順で入れる」状態を保ちつつ、入口を絞れるのが魅力でした。

システム構成図

導入後のイメージは次のとおりです。PC（やスマホ）は Tailscale の仮想 LAN 経由でのみ VPS の SSH に届き、インターネットからの :22 は閉じます。

導入後のシステム構成。PCとスマホがTailscale経由でVPSのSSHに接続し、インターネットからの公開SSHは遮断される
導入後のシステム構成図

導入の流れ

サーバーは Ubuntu、クライアントは PC です。公式の手順どおりに進めました。

1. サーバーに入れる

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

tailscale up のあと、表示される URL をブラウザで開き、アカウントで認証します。成功すると Tailscale の管理画面に端末が現れ、100. で始まるアドレスが割り当てられます。

2. 自分の PC にも入れる

PC 側も同様にインストールし、同じアカウントでログインします。両方が online になれば、サーバーの Tailscale アドレスへ SSH できます。

ssh user@100.x.y.z

名前解決が有効なら、マシン名ベースでもつながりやすいです。普段使いでは、公開 IP を覚える必要がなくなりました。

3. SSH の待ち受けを絞る

ここが本番です。sshd がすべてのインターフェースで待っていると、結局インターネットからも叩かれます。自分の環境では、通常の SSH を Tailscale のアドレス側だけに寄せました。イメージとしては次のような方針です。

# 例: Tailscale インターフェース側だけで 22 を受ける
# 公開 NIC 側では 22 を閉じる（UFW / クラウドの SG も合わせて確認）
sudo ufw allow in on tailscale0 to any port 22 proto tcp
sudo ufw deny 22/tcp

実際の設定は環境差が大きいので、切る前に Tailscale 経由の別セッションを確保するのが安全です。ロックアウトすると復旧が面倒になります。

もう少し踏み込んだ使い方

つなげるだけでも十分便利ですが、端末が増えると「全部が全部に届く」状態は雑になります。自分の環境では、そのあと ACL と サブネット経路 まで踏み込みました。

ACL（誰が何に触れるか）

管理画面の ACL で、端末にタグを付けて通信を絞っています。たとえば信頼できる手元端末は tag:trusted、VPS は tag:vps、別用途のサーバーは別タグ、という分け方です。許可は「端末どうし」ではなく「タグとポート」で書きます。

{
  "grants": [
    {
      "src": ["tag:trusted"],
      "dst": ["tag:vps"],
      "ip": ["tcp:22", "tcp:20022"]
    }
  ]
}

実際にハマったのは、SSH（22）は通るのに SFTP（20022）だけ落ちる、というケースでした。ログを見ると Tailscale 側で no rules matched になっており、サーバーや UFW ではなく ACL のポート許可漏れ が原因でした。つながるつもりだった経路が、ACL で静かに落ちることがある、と覚えておくと安心です。

サブネット経路

Tailscale に直接参加していない機器（同じ LAN 内の NAS や開発用ホストなど）へ届きたいときは、サブネット経路を使います。ゲートウェイ役の端末が「自分経由ならこの LAN に届く」と Tailscale に知らせ（--advertise-routes）、管理画面でその経路を承認します。

# 例: 自宅 LAN 192.168.1.0/24 への経路を知らせる（ゲートウェイ役の端末で）
sudo tailscale set --advertise-routes=192.168.1.0/24

これで、出先の PC からでも「その LAN の中にいるように」届ける運用ができます。ただし、知らせる範囲は最小限に、ACL とセットで「誰がその経路を使えるか」まで決めるのが安全です。広く通しすぎると、入口を絞った意味が薄れます。

使ってみて感じたこと

いちばん大きかったのは、心理的な負担が減ったことです。「いま自宅の IP は何か」「出先から入れるか」を毎回考えなくてよくなりました。アプリ開発やファイル整理のついでに、いつものコマンドでサーバーへ入れる。それだけで運用の摩擦が下がります。

注意点もあります。端末を紛失したときは、管理画面からその端末を外す運用が必要です。また、SSH を閉じても別サービスを広く公開していればリスクは残ります。ACL やサブネット経路まで含めると便利さは増えますが、設定の見直しもセットです。Tailscale は銀の弾丸ではなく、「入口を減らす道具」として使うのがちょうどよいと思いました。

まとめ

Tailscale は、個人の VPS 運用で「安全に、でも面倒なく届く」ための現実的な選択肢でした。導入そのものに加えて、ACL でタグとポートを絞り、サブネット経路で LAN 内の機器にも届けるところまで使っています。入口を減らしつつ、自分の作業導線は残す。そのバランスが、いちばん気に入っているところです。