自分だけのコントロールサーバー。
握っておく価値があるのは、地図そのものだ。

「自分のマシン同士を、プライベートに到達させたい」という要望に対する正直な答えは3つあり、このガイドはそのうちの1つでしかない。素のWireGuardが最小の答えだ——カーネルモジュール、ピアごとに1つの設定ファイル、インターフェース以外にデーモンはなく、OS以外に最新に保つべきものもない。デバイスが固定アドレスを持つサーバーで、片手で数えられる台数しかないなら、ここで読むのをやめてWireGuardガイドを読んでほしい。そのほうがソフトウェアは少なく、壊れうるものの一覧も短く済む。

Tailscale は最大手だ。内部は同じWireGuardに、コーディネーションサービス、ほぼどんな環境の裏側からでも機能するNATトラバーサル、複数の大陸にまたがるリレー網、Webコンソール、シングルサインオン、そしてサポート契約が加わる。純粋に優れたソフトウェアであり、無料枠だけで家庭用途は十分にまかなえる。対価は金銭ではない——所有するすべてのデバイスの地図と、それぞれがどこから接続しているかの記録が、一企業のデータベースに置かれるということだ。

Headscale は3つ目の答えであり、どちらよりも狭い範囲を扱う——コーディネーションサーバーをオープンソースで再実装したもので、あなた自身が運用し、同じ公式クライアントが話しかける相手になる。自動化とNATトラバーサルはそのまま手に入るが、その代わりに小さなサービスの運用、部分的な機能セット、そして読み込みが必要なアップグレードを背負うことになる。それを無料だと言い張るべきではない。手に入るのはただ一つ、しかしこのサイトが気にかけているのはまさにそれだ——他の誰も地図を握っていないということ。

後回しにせず今のうちに決めておくべきことがもう一つある。何をインストールするかが変わってくるからだ——このネットワークは自分専用なのか、それとも他の人も加わるのか。1人用のテイルネットなら、内部を全面的に開けっぱなしにしていても何も悪いことは起きない。同僚や契約社員、家族が加わるテイルネットには、最初の週から書き出されたアクセスルールが必要になる——ステップ05——そして全員が1つのログインを共有するのではなく、ユーザーを分けておく必要がある。それを最初に決めておくコストは段落1つ分だが、あとから作り直すコストは午後まる1日分だ。

HeadscaleとCaddy、それ以外は何もない。Headscaleは Docker ネットワーク内部で素のHTTPを待ち受け、CaddyがTLSを終端し、初回起動時に証明書を取得し、頼まれなくても更新する。メトリクスのリスナーはlocalhostにとどめておく——これは内部向けのデバッグ用の口であり、公開すべきものではないからだ。

ファイルの前にルールが1つある。イメージは正確なバージョンに固定すること。Headscaleは1.0未満のソフトウェアであり、マイナーリリースをまたいで設定キーとCLIサブコマンドの名前を一度ならず変えてきた。フローティングタグのままだと、ありふれたコンテナの再起動が、他のすべてに到達するための役目を担うサービスの障害に変わってしまう。

/srv/headscale/docker-compose.yml

services:
  headscale:
    image: docker.io/headscale/headscale:0.26            # pin it; never :latest
    container_name: headscale
    command: serve
    volumes:
      - ./config:/etc/headscale
      - ./data:/var/lib/headscale
    ports:
      - "3478:3478/udp"                                  # STUN, for your own DERP
    restart: unless-stopped

  caddy:
    image: caddy:2-alpine
    container_name: caddy
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - ./Caddyfile:/etc/caddy/Caddyfile:ro
      - caddy_data:/data
    restart: unless-stopped

volumes:
  caddy_data:

/srv/headscale/Caddyfile

vpn.example.com {
    reverse_proxy headscale:8080
}

プロキシの設定はこれで全部だ。Caddyは指示しなくてもHTTP/2を話し、長時間持続する接続をアップグレードする。これが重要なのは、すべてのクライアントがマップの更新を受け取るために接続を1本開いたままにしているからだ。固定したバージョンに同梱されているサンプル設定ファイルを取り、ゼロから書くのではなくそれを編集すること——ファイル自体は長いが、その大半は妥当な既定値であり、重要なキーは次のとおりだ。

/srv/headscale/config/config.yaml — the lines that matter

server_url: https://vpn.example.com          # exactly what clients will dial
listen_addr: 0.0.0.0:8080                    # inside the Docker network only
metrics_listen_addr: 127.0.0.1:9090          # debug surface, keep it local

prefixes:
  v4: 100.64.0.0/10
  v6: fd7a:115c:a1e0::/48

noise:
  private_key_path: /var/lib/headscale/noise_private.key

database:
  type: sqlite                               # postgres for a large fleet
  sqlite:
    path: /var/lib/headscale/db.sqlite

dns:
  magic_dns: true
  base_domain: ts.example.com                # NOT a parent or child of server_url
  nameservers:
    global:
      - 1.1.1.1                              # replaced by your own in step 05

立ち上げたら、推測ではなくログを読むこと。証明書を取得できない初回起動や、サーバーのホスト名と重なるという理由でDNSサフィックスを拒否する初回起動は、そのことをはっきりと告げたうえで停止する。

docker compose up -d
docker compose logs -f headscale

# From your laptop — a control server that is up answers this:
curl -s https://vpn.example.com/health

初回起動時に、秘密鍵データが /srv/headscale/data に生成される。1台のデバイスも登録する前に、今すぐ安全な場所へコピーしておき、最初の登録が終わったあとにもう一度コピーすること。この鍵を失えば、すべてのデバイスが信頼してきたサーバーを拒否するようになり、直す方法は全台を手作業で再登録する以外にない。ステップ06では、このコピーを本物のバックアップへと仕立てる。

すべてのデバイスが他のすべてのデバイスに到達できるテイルネットは、それだけですでに役に立つ。3つの機能を追加することで、それは単なるトンネルの集まりから一つのネットワークになる。そしてこの3つには、人がよくつまずく共通の性質がある——クライアント側が機能を広告し、サーバー側がそれを承認しなければならないということだ。広告されただけで承認されていないルートは、黙って存在しないままになる。症状としては、ルーターにはpingが通るのに、その先には何も届かないという形で現れる。

サブネットルーター——LAN全体をテイルネットに乗せる。 自宅やオフィスのネットワークにある1台のマシンが、そのネットワークのレンジを広告する。すると他のすべてのデバイスは、そこに何もインストールすることなく、その裏にあるプリンター、NAS、管理インターフェースに到達できるようになる。まずカーネルでフォワーディングを有効にしておくこと。さもないと、パケットはエラーメッセージも出さずにルーターで止まってしまう。

# On the machine that sits inside the LAN:
echo 'net.ipv4.ip_forward = 1'          | sudo tee /etc/sysctl.d/99-ts.conf
echo 'net.ipv6.conf.all.forwarding = 1' | sudo tee -a /etc/sysctl.d/99-ts.conf
sudo sysctl -p /etc/sysctl.d/99-ts.conf

sudo tailscale up --login-server https://vpn.example.com \
  --advertise-routes=192.168.1.0/24 --accept-routes

# On the control server — approve it, or it does not exist.
# The subcommand moved between releases; check `hs nodes --help` first.
hs nodes list
hs nodes approve-routes --identifier 3 --routes 192.168.1.0/24

エグジットノード——すべてをVPS経由で送り出す。 同じ仕組みを、より広いルートで使う——自分をエグジットノードとして広告するデバイスは、別のデバイスのインターネット接続をまるごと運ぶことを申し出る。信頼できないカフェやホテルのネットワークでは、まさにそれこそが欲しいものであり、このガイドの中で個人用VPNに最も近いものである。

# On the VPS that will do the exiting (forwarding must be on, as above):
sudo tailscale up --login-server https://vpn.example.com --advertise-exit-node

# Approve it on the control server, then on the laptop:
tailscale set --exit-node=100.64.0.1 --exit-node-allow-lan-access
tailscale set --exit-node=                    # turn it off again

エグジットノードは商用VPNではないし、自分自身にそう売り込むべきでもない。そのアドレスはあなただけのものであり安定している——カフェのWi-Fiに対しては優秀だが、複数サイトにまたがる長期的な相関に対しては無力だ。このトレードオフは柱となるガイドで詳しく説明している。なお、エグジットノードは2台目の安いVPSで動かし、コントロールサーバーは転送トラフィックと完全に無縁のままにしておくこともできる。

アクセスルール——2人目が加わる前に書いておく。 既定のポリシーは全許可であり、これは1人用のテイルネットには正しいが、他の誰かが加わった瞬間に誤りになる。ポリシーは小さなHuJSONドキュメントで、ユーザーのグループ、マシンのタグ、そしてどの送信元がどのポートでどの宛先に到達してよいかを示すルールの一覧からなる。設定でそのファイルを指すようにし、ファイルはバージョン管理に置き、編集のたびにリロードすること。

{
  "groups": {
    "group:admin":     ["alice"],
    "group:contractor":["bob"]
  },
  "tagOwners": {
    "tag:server": ["group:admin"],
    "tag:exit":   ["group:admin"]
  },
  "acls": [
    // Admins reach everything.
    { "action": "accept", "src": ["group:admin"], "dst": ["*:*"] },

    // The contractor reaches one machine, on two ports, and nothing else.
    { "action": "accept", "src": ["group:contractor"],
      "dst": ["tag:server:22,443"] }
  ],
  "autoApprovers": {
    "routes":   { "192.168.1.0/24": ["tag:server"] },
    "exitNode": ["tag:exit"]
  }
}

そのファイルについて、注意点が2つある。ポリシー言語はTailscaleのものであり、Headscaleはそのすべてではなく、大きく、なお拡大し続けている部分集合を実装している——変わったルールに頼る前に、使っているバージョンのドキュメントを確認すること。もう1つ、ポリシーの置き場所も変わってきた。古いリリースではトップレベルの設定内にパスを指定していたが、新しいリリースではpolicyセクションの下にまとめられ、ルールをデータベースに保持できるモードも用意されている。どちらもドキュメント化されているが、重要なのは、固定したバージョンが実際に採用しているほうだ。

MagicDNS——短い名前と、どこでも自前のリゾルバー。 MagicDNSを有効にすると、すべてのデバイスがステップ02で選んだサフィックスの中の短い名前に応答するようになり、hostsファイルなしでssh nasがどこからでも動くようになる。面白いのは後半のほうだ——コントロールサーバーはすべてのクライアントにネームサーバーの一覧もプッシュする。つまり、プライベートDNSリゾルバーガイドで構築したリゾルバーが、モバイル回線上のスマートフォンにも——フィルタリングし、キャッシュし、何も記録せずに——サービスを提供できるということだ。しかもそれは、インターネットからはまったく到達できないテイルネットのアドレスで待ち受けたままである。

dns:
  magic_dns: true
  base_domain: ts.example.com
  override_local_dns: true          # beat whatever DHCP handed the device
  nameservers:
    global:
      - 100.64.0.5                  # your resolver, on the tailnet

コントロールプレーンをセルフホストすることは、具体的で本物の改善であり、目くらましの手品ではない。ここまでのすべてを終えたあとでも変わらず真実である5つのことがある。それを知っているかどうかが、本当の防御と、心地よいだけの物語との違いになる。

コントロールサーバーは、公開された、名前を持つエンドポイントである。 すべてのデバイスがそこに接続しにいく以上、ホスト名を持つことになり、そのホスト名は証明書が発行された瞬間に証明書透明性ログへ公開される。どこにもリンクしていなくても発見可能であり、そのアドレスは所有するすべてのデバイスに共通する唯一の定数になる。それが何であるかを説明するような名前ではなく、すでに公開している名前のサブドメインを使うこと。

Headscaleは再実装であり、そのことを自ら明言している。 Tailscale自身が開発しているわけでもサポートしているわけでもなく、機能の同等性はもとから部分的であり、ホスト型製品が売りにしているものの一部——Webコンソール、公開リレー網、洗練されたシングルサインオンの経路——は、ここには存在しないか、誰も監査していないサードパーティ製プロジェクトでしか手に入らない。ある機能に計画を頼る前に、それが存在するかどうかをプロジェクトのドキュメントで確認すること。そしてアップグレードは、バックグラウンドで勝手に進む処理ではなく、一つのタスクとして扱うこと。

既定のリレーは、いまも他人のものだ。 組み込みのDERPサーバーを有効にするまでは、直接接続できない通信は公開リレー網にフォールバックする。ペイロードはそれでもエンドツーエンドで暗号化されており、誰にも読むことはできない——だが、2台のデバイスが話しているという事実そのものと、その通信量は、あなたが所有していないインフラを通過する。ここが、たいていの人が最初の午後に見落とす、信頼の連鎖の部分だ。

エグジットノードが与えるのは安定したアドレスであり、人混みではない。 自分のVPS経由でトラフィックをルーティングすれば、カフェのネットワークやISPによるプロファイリングは無力化できる。だが相関分析は無力化できない。そのアドレスはあなただけのものであり、変わらないからだ。商用VPNの共有アドレスは、あらゆる点で劣るが、この特定の脅威に関しては唯一そこだけが優れている。

そのマシンは、いまも1棟の建物の中にある。 レンタルサーバーは、扉があり、スタッフのいるデータセンターの、物理的なハードウェア上で動いている。変わるのは、あなたのデバイスを製品レベルで索引化する仕組みがないこと、それぞれの接続元を記録する企業のデータベースがないこと、そして来四半期に改定されうるプライバシーポリシーが存在しないことだ。変わらないのは、ディスクが物理的に存在し、それがあなたの家の中にはないということである。

実際に手に入れたものを正確に言えば——所有するすべてのマシンの一覧、それぞれの接続元の記録、そして新しいマシンを追加する権限は、すべて、特定の名前を名乗らずに借りているサーバーの上に置かれている。これは狭い主張であり、同時に本物の主張でもある。その価値が費用に見合うのは、ステップ06を済ませた場合だけだ——検証済みの復元を伴わないセルフホストのコントロールプレーンは、プライバシーの改善ではなく、見栄えの良い単一障害点にすぎない。