1. 直接接続とTunnelの違い#
以前の構成では、サーバーのIPv6アドレスをDDNSスクリプトでCloudflare DNSのAAAAレコードへ更新し、利用者がサーバーへ直接接続していました。この方式は経路が単純ですが、利用者側のネットワークやISPによって速度が大きく変わり、サーバーのIPv6アドレスも公開されます。
Cloudflare Tunnelを使うと、サーバーからCloudflareへアウトバウンド接続を作り、利用者はCloudflareのエッジ経由でAlistへアクセスします。オリジンのIPアドレスをDNSへ直接公開せずに済む点が大きな利点です。
2. 古いDDNSスクリプトを使う場合の注意#
DNS APIをスクリプトから呼ぶ場合は、グローバルAPIキーではなく、対象ゾーンのDNS編集だけを許可したAPIトークンを使います。トークンやメールアドレスをMarkdownやGitリポジトリへ直接書かないでください。
export CLOUDFLARE_API_TOKEN='replace-with-a-token'
export ZONE_ID='replace-with-zone-id'
export RECORD_ID='replace-with-record-id'
export IPV6_ADDRESS='2001:db8::1'トークンが漏れた場合は、Cloudflareダッシュボードから直ちに失効させ、新しいトークンを発行します。既存の記事やGit履歴に実際の認証情報がある場合は、ファイルを消すだけでなく、必ず鍵をローテーションしてください。
3. cloudflaredをインストールする#
Arch Linuxの例です。
sudo pacman -S cloudflaredDebian/Ubuntuでは、ディストリビューションとCloudflareの公式配布手順に合わせてインストールします。
sudo apt install cloudflared4. Tunnelを作成する#
cloudflared tunnel login
cloudflared tunnel create alist-tunneltunnel createの出力に表示されたTunnel IDと認証ファイルの場所を控えます。
5. Tunnelの設定ファイルを作る#
通常は~/.cloudflared/config.yml、サービスとして実行する場合は/etc/cloudflared/config.ymlを使います。
tunnel: 12345678-aaaa-bbbb-cccc-123456abcdef
credentials-file: /home/<user>/.cloudflared/12345678-aaaa-bbbb-cccc-123456abcdef.json
ingress:
- hostname: alist.050626.xyz
service: http://localhost:5244
- service: http_status:404Alistが実際にlocalhost:5244で待ち受けていることを確認します。
ss -ltnp | grep 5244
curl -I http://localhost:52446. DNSとTunnelを接続する#
cloudflared tunnel route dns alist-tunnel alist.050626.xyz
cloudflared tunnel run alist-tunnelsystemdサービスとして登録する場合は、cloudflaredの公式手順に従ってから状態を確認します。
sudo systemctl enable --now cloudflared
sudo systemctl status cloudflared7. Alist側で確認すること#
TunnelでTLSを終端し、AlistへHTTPで接続する構成では、Alist側のforce_httpsがリダイレクトループを作らないように確認します。
force_https: falseCloudflare Accessを使う場合は、Tunnelの公開ホスト名に対して認証ポリシーを設定します。管理画面、アップロード、APIなどのパスを用途ごとに確認してください。
まとめ#
- IPv6のAAAAレコードによる直接接続は単純だが、IP公開と経路品質の影響を受ける。
- Cloudflare Tunnelは、オリジンIPを直接公開せずにAlistを公開できる。
- DNS APIを使う場合は最小権限のAPIトークンを利用し、認証情報を記事やGit履歴へ残さない。
- Tunnelが高速化するとは限らないため、地域、帯域、アップロード制限、ログを実測して判断する。
