Caddy v2でOnion Serviceを運用する

Torとは

Torについての説明は必要ないかもしれないが，単純に言えば「通信経路を暗号化したネットワーク」である。技術としてのTorは既存のTCP/IPネットワークの上に乗っかる形で存在しており，OSI参照モデルでいうところのレイヤ5からレイヤ7にまたがる幅広い存在だ。

システムの構成

最終的にこんな構成にしたい:

作業内容

作業の内容は次のとおり:

1. CaddyのRuntimeDirectoryを追加する

2. Caddyifleを編集し，Unix Socket ListenerをCaddyに追加

3. Torをインストール

4. ACLを使ってユーザーのアクセス権限を設定

5. hidden_serviceディレクトリを作成しファイルを転送後，パーミッションを正しく設定

6. torrcを編集する

7. Torを再起動

ランタイムファイルとは

ランタイムファイルとはシステムの実行時に/run以下に生成されるファイルのことで，PIDファイル(.pid)，ソケットファイル(.sock)，ロックファイル(.lock)などがある。

ソケットファイルは異なるプロセス間での通信に使われるもので，通常のファイルシステム上のファイルではない。カーネルの機能に関わる領域というのもありパーミッションについては直感に反する決まりごとがある。通常のファイルシステム上のファイルなら+rは読み込みread()を，+wは書き込みwrite()をそれぞれ許可する。しかしソケットファイルはクライアントがconnect()によって通信チャネルを確立し，開かれたファイルディスクリプタに対してread()とwrite()を実行するという点が異なる。ソケットへのconnect()の操作の許可，すなわちソケットに接続するための権限としてwつまり書き込みの権限が使われる¹。

ソケットを使った通信はTCP/IPと比較して高速で，個別のポートを占有することもないというメリットがある。

今回はCaddyをソケットの受け手側として設定するのでCaddyのランタイムディレクトリにソケットを配置し，Torをソケットに接続させて両者の間の通信を行うことにする。つまりCaddyはサーバーでTorはクライアントという関係になる。まずは/run以下にCaddy専用のディレクトリを作る。

systemd drop-inファイルを使ってユニットを追加する

/runはtmpfs上にマウントされており再起動するとディレクトリも消えてしまう。systemdにはランタイムディレクトリを永続化するための設定があるのでそれを利用する。systemdにはdrop-inファイルで一部だけを上書きするという便利な機能がある。

既存のサービスの設定を変更する，あるいは追加する場合にもとのユニット設定ファイルを直接編集するのはおすすめしない。systemdには/etc/systemd/systemを使うものと/lib/systemd/systemを使うものがあって紛らわしいだけでなく，アップデートをすれば上書きされてしまうためだ。drop-inファイルなら上書きされることはないが，サービスを停止するとランタイムディレクトリも削除されるので注意。

$ sudo systemctl edit caddy

すぐさまエディターが立ち上がる。英語の部分を読めばわかるが，2行目の### Anything between here and the comment below will become the new contents of the fileから### Lines below this comment will be discardedまでの行の間に追加する項目を書いていく。ここに追加した内容はもとのユニット設定ファイルの項目を上書きする。

### Editing /etc/systemd/system/caddy.service.d/override.conf
### Anything between here and the comment below will become the new contents of the file

[Service]
RuntimeDirectory=caddy
RuntimeDirectoryMode=0750

### Lines below this comment will be discarded

### /lib/systemd/system/caddy.service
### (省略)

これで，次回の起動時にモード750の/run/caddy/が作成されるはずだ。

早速確認してみよう

$ sudo systemctl daemon-reload

$ sudo systemctl restart caddy

$ ls -ld /run/caddy
drwxr-x--- caddy caddy  /run/caddy

成功していれば，drwxr-x---の/run/caddyが見えるはずだ。

もし見えていなければ，systemctl status caddyがFailedになっていないか，drop-inが正しく適用されているかもう一度確認しよう。それからsystemdの再起動が必要な操作なのでcaddy reloadとも混同しないように注意。

Unix Domain Socketを追加

Caddyfileを編集して新たなSite blockにてUnix Domain Socket Listenerを追加しソケットからの通信を待ち受ける。極限まで単純化すると以下のような感じだ。普段使っているクリアネット向けのSite blockに続く形でhttp://で始まるブロックを追記する。

{
    # Global options block
    default_bind 203.0.113.1 [2001:db8::1]
}
example.org {
    # Site block for Clearnet (HTTP/HTTPS)
}
http:// {
    # Site block for Onion Service
    bind unix//run/caddy/onion.sock|0220
}

bind unix//run/caddy/onion.sock|0220によって，Caddyの再読込後にソケットが追加される。0220は所有者とグループに対して書き込み権限が与えられるモードである。ソケットのパーミッションについては前述の通りだが，0660にする必要はない。ちなみにCaddyのデフォルトの値も0200である²。

bindディレクティブを使うので，グローバルオプションでdefault_bindでクリアネット向けのIPアドレスを設定しておくことをおすすめする。このサイトではIPv4とIPv6どちらも利用できるので2つとも指定している。

なおアドレス部分のhttp//というのはHTTPによるcatch-allなブロックであることを示す。すなわちフォールバック的な動作を期待するものなので，クリアネット向けのサイトブロックの上に書いてはいけない。.onionで終わるアドレスを書いても良いのだが，プロトコルを省略するとHTTP 400 Bad Requestが返ってきてしまうので注意。この部分を:80とポート番号で指定しても一応動作はするのだが，それはTorネットワーク側から見えている論理的な:80であって，物理的なインターフェースに紐づいたlocalhost:80とは異なる概念であるため，紛らわしさを避けるためにあえてhttp//としている。それからこの方法だとHTTPのプロトコル指定になってしまうが，Onion Serviceの場合はHTTPが一般的なので問題ない。一応付け足しておくと，Torネットワークの内部では.onionのドメインそのものが公開鍵として接続の認証に使われているため，必ずしも外部の認証機関を必要としないためだ³。

HTTPをサポートするには

クリアネットの方でHTTPをサポートしたい場合はちょっと工夫がいる。CaddyではTLS証明書の取得，更新，リダイレクトまで自動でやってくれるので，上の例ではhttp://example.orgにアクセスすると１つ目のサイトブロックにマッチしたうえで308 Permanent Redirectが返ってくる。しかしCaddyfileのグローバルオプションにauto_https disable_redirectsを追記してリダイレクトを無効にするだけではうまくいかない。試してみると空の200 OKが返ってくるので，example.orgのブロックではなくTor用のフォールバックにマッチしてしまうのかもしれない。

この問題はサイトアドレスにプロトコルを明記することで解消する。

{
    # Global options block
    auto_https disable_redirects
    default_bind 203.0.113.1 [2001:db8::1]
}
https://example.org {
    # Site block for Clearnet (HTTPS)
}
http://example.org {
    # Site block for Clearnet (HTTP)
}
http:// {
    # Site block for Onion Service
    bind unix//run/caddy/onion.sock|0220
}

複雑になった設定を整理する

経路を完全に分離する流れでここまで進めてきたが，Onion Service，クリアネットのHTTP/HTTPS，プロトコルによらずアクセスされたときの挙動は共通にするのが当然だろう。

これまでかなり単純化された形のCaddyfileを扱ってきたが，実際の運用ではもっと複雑になるはずだ。こんなときは一部分だけを一般化できるCaddyfileのスニペット機能が便利だ。

共通部分をcommon_rulesetとしてスニペット化してみると一括で管理できるし，見た目にもわかりやすい。

{
    # Global options block
    auto_https disable_redirects
    default_bind 203.0.113.1 [2001:db8::1]
}
(common_ruleset) {
    root * /usr/share/caddy
    file_server
    encode gzip
    handle_errors {
        header Content-Type text/plain
        respond "{err.status_code} {err.status_text}" {
            close
        }
    }
}
https://example.org {
    import common_ruleset
    log {
        output file /var/log/caddy/access.log
    }
}
http://example.org {
    import common_ruleset
    log {
        output file /var/log/caddy/access.log
    }
}
http:// {
    # Site block for Onion Service
    bind unix//run/caddy/onion.sock|0220
    import common_ruleset
    log {
        output file /var/log/caddy/tor-access.log
    }
}

スニペットのブロックはグローバルオプションの直後，サイトブロックより前に置く必要がある⁴。

それから個人的な事情でログファイルを分割しているが，TorからのリクエストをUnix Domain Socket Listenerで受けるとクライアントのIPどころかポートすらログに残らなくなるので，Tor専用のログファイルに分けることを強くおすすめする。

抽象化はほどほどにしておき，caddy validateしてみてValid configurationと表示されることを確認したら次の工程に進む。

追加されるユーザー

インストールするとdebian-torいうユーザーが登録される。Torはこのユーザーで実行される。

$ id debian-tor
uid=110(debian-tor) gid=118(debian-tor) groups=118(debian-tor)

Torのsystemdユニットを確認

Debianの場合systemdからコントロールできる。systemdのユニット設定ファイルはインスタンスごとに分けて使うことを想定しているためか複数ある。

$ dpkg -L tor | grep '\.service'
/lib/systemd/system/tor.service
/lib/systemd/system/tor@.service
/lib/systemd/system/tor@default.service

tor.serviceは複数インスタンスをラッパーとして存在し，常にリターンコード0とステータスactiveを返しExecReloadを提供するだけの空のサービスである。ちなみにtor@.serviceというのは共通のテンプレートで，各インスタンスは<サービス名>@<インスタンス名>.serviceとして管理される。

tor.serviceの依存関係を覗いてみるとtor@default.serviceに依存しているのがわかる。

$ systemctl list-dependencies tor.service
tor.service
● ├─system.slice
● ├─tor@default.service
● └─sysinit.target
# (省略)

この場合，実際にTorをコントロールするのはtor@default.serviceである。したがって実際のステータスを確認するときは以下のコマンドを使う:

$ systemctl status tor@default.service

Vanity Addressについて

Onion Service用のv3アドレスはオフラインからリセマラすることができる。見た目以外に利益はないことからVanity Addressと呼ばれる。

私の場合はmkp224oというソフトウェアを使わせてもらった。詳細なやり方についてはリポジトリを見てほしい。

転送

先にディレクトリを作成して適切なパーミッションを設定しておく。

$ sudo mkdir -P /var/lib/tor/hidden_service

$ sudo chmod 700 /var/lib/tor/hidden_service

$ sudo chown -R debian-tor:debian-tor /var/lib/tor/hidden_service

$ sudo ls -ld /var/lib/tor/hidden_service
drwx------ debian-tor debian-tor

手元にファイルがあるなら，このような構成になっているはずだ。

~/keys/xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx.onion/
├── hostname
├── hs_ed25519_public_key
└── hs_ed25519_secret_key

hostnameと公開鍵は644，秘密鍵は600が設定されている。scpコマンドを使うとパーミッション関係が面倒なので，tarでアーカイブ化してssh経由でリモートに送る。

ここだけローカルのマシンで実行する。リモートのマシンのsudoにパスワードが求められる場合はうまくいかない。

$ sudo tar -C "~/keys/xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx.onion/" -cf - hostname hs_ed25519_public_key hs_ed25519_secret_key | ssh debian@host 'sudo tar -C /var/lib/tor/hidden_service -xf -'

所有者とパーミッションを設定する。

$ sudo chown debian-tor:debian-tor /var/lib/tor/hidden_service/*

$ sudo chmod 600 /var/lib/tor/hidden_service/hs_ed25519_secret_key

$ sudo chmod 644 /var/lib/tor/hidden_service/hs_ed25519_public_key

$ sudo chmod 644 /var/lib/tor/hidden_service/hostname

Can’t complete SOCKS5 connection

次のようなエラーが出る場合，TorとCaddyのプロセス間接続がうまくいっていないかもしれない。psコマンドでTorのプロセスを確認して:

• TorはどのUID/GIDで実行されているか

• /var/lib/tor/hidden_service以下のパーミッションはTorを実行中のUID/GIDと一致しているか

• /run/caddy/onion.sockに設定されたACLはそのユーザーに書き込み許可を与えているか

• TorのログにRendezvous circuitを切断した記録がないか

• AppArmorのステータスに”DENIED”が出ていないか

などを確認しよう。

curlのエラーコード4はプロトコルが見つからないという意味らしい⁵が，どうしてそういう処理になるのかまではわからない。

* Can't complete SOCKS5 connection to xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx.onion. (4)
* Closing connection 0
curl: (97) Can't complete SOCKS5 connection to xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx.onion. (4)

エラーコードが(4)ではなく(1)のときはクライアント認証が有効になっている可能性が高い。/var/lib/tor/hidden_service/authorized_clients以下にファイルがあるはずなので確認する。

* Can't complete SOCKS5 connection to xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx.onion. (1)
* Closing connection 0
curl: (97) Can't complete SOCKS5 connection to xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx.onion. (1)

Connection refused

そもそもSOCKSプロキシに接続できない場合，torrcでSocksPortの設定が変更されているはずなのでtorrcを確認する。何も指定されていなければデフォルトはlocalhost:9050のはずだ。

* connect to 127.0.0.1 port 9050 failed: Connection refused
* Failed to connect to 127.0.0.1 port 9050 after 0 ms: Couldn't connect to server
* Closing connection 0
curl: (7) Failed to connect to 127.0.0.1 port 9050 after 0 ms: Couldn't connect to server

HTTPのエラー

HTTP 400 Bad Requestや空のHTTP 200 OKが返ってきたらCaddyの設定に問題がある。Caddyfileを見直したり，クリアネット版にもリクエストを送ってみて結果を比較したりしてみよう。

その他

エラーは出ないがなかなかレスポンスが返ってこないときは一旦中断して，5分くらい待ってからもう一度実行しよう。

Torの特殊さ

Torのプロセスには今回かなり手を焼いた。

そもそもCaddyのソケットにTorを接続させるにあたってまず最初に試したのは「debian-torをcaddyグループに追加する」方法だった。通常なら実行ユーザーの補助グループもファイルアクセス判定に使われるのでこれだけで十分のはずだ。

$ sudo usermod -aG caddy debian-tor

$ id debian-tor
uid=110(debian-tor) gid=118(debian-tor) groups=118(debian-tor),997(caddy)

しかしtorのPIDを特定し補助グループの情報を表示してみると……

$ systemctl show --property MainPID tor@default.service
MainPID=1008

$ ps -o supgid,supgrp -p 1008
SUPGID               SUPGRP
118                  debian-tor

全く反映されていない。プロセスに反映されないのでは意味がない。

次にtorのsystemdにて補助グループを指定してみるのも試したがこれもうまくいかず。

[Service]
SupplementaryGroups=caddy

続いてtorrcに設定項目がないか調べてみた。torrcで指定可能なオプションはtor --list-torrc-options一覧することができる。しかしこの中に任意のユーザーで実行するための設定はあったが，結局のところプライマリグループでしか実行できないらしいので今回は見送った。

User Username

On startup, setuid to this user and setgid to their primary group. Can not be changed while tor is running.

– torrc(5) — tor — Debian bookworm — Debian Manpages

結論:

• Torは権限降格によって補助グループへの追加を意図的に外す設計をしている

• systemdからもtorrcからも手を加えることはできない

公式ドキュメント

• The Caddyfile — Caddy Documentation

• Tor Project | Onion Services

Socket

• ソケット通信を一緒に理解しよう！！ #Network - Qiita

• Socket()とかBind()とかを理解する #Linux - Qiita⁶

systemd

• 第598回　systemdユニットの設定を変える | gihyo.jp

• systemd のユニットを＠引数で再利用する。 - それマグで！

Tor

• 【図解】Torネットワークによる匿名化と、.onionドメインにアクセスする仕組みについて #Security - Qiita

• Tor - ArchWiki

ACL

• アクセス制御リスト - ArchWiki

コマンド類

• ログインユーザに権限のないディレクトリにscpをする | 俺的備忘録 〜なんかいろいろ〜

• [Linux] lsの結果から日付(タイムスタンプ)の列を削除する方法 – ラーメン屋になりたいシステムエンジニアのブログ

• I want to resolve onion addresses · curl/curl · Discussion #11125 · GitHub