Tailscale Funnel 公開ガイド｜SaaS不要の公開手段

Tailscale Funnel の概要と 2026 年のネットワーク環境における位置付け

自宅サーバーやオンプレミス環境の公開を巡る環境は、2025 年において大きく変化しています。従来のポート開放アプローチは、セキュリティリスクの高さから敬遠される傾向にあり、特に家庭用ルーターでの OpenVPN やポートフォワーディング設定は、IoT デバイスが増加した現代では攻撃経路になりやすいため注意が必要です。この文脈で注目されているのが Tailscale Funnel です。Tailscale Funnel は、SaaS（Software as a Service）プロキシを介在させることなく、自社のネットワークリソースをインターネット上に安全に公開するための新しいアプローチを提供します。特に 2026 年に向けて、クラウドコストの最適化とセキュリティ要件の厳格化が求められる中で、この技術は「ゼロトラスト・アーキテクチャ」の実践ツールとして重要な役割を果たすでしょう。

従来の方法では、自宅のサーバーを公開するためにルーターの NAT ポート転送（ポートフォワーディング）を設定し、外部から直接 IP アドレスにアクセスできる状態を作っていました。これは非常にシンプルですが、セキュリティ上の弱点となりやすく、特に SSH や Web サーバーが露出することによるランサムウェアやボットネットへの攻撃リスクが高まります。Tailscale Funnel は、この課題を解決するために設計された機能で、Tailscale の超高速な WireGuard トンネル技術を活用しながら、特定のポートのみを安全に公開します。これにより、ユーザーは複雑な SSL 証明書の取得やルーターの再設定を行わずとも、安全かつ低遅延で自宅サーバーにアクセスすることが可能になります。

本ガイドでは、Tailscale Funnel の具体的な仕組みから、実際の設定手順、セキュリティ上の注意点までを網羅的に解説します。特に、Synology DS923+ や Raspberry Pi 5 といった人気ハードウェアでの運用事例を交えながら、Cloudflare Tunnel や ngrok との違いも明確に比較します。2026 年のネットワーク環境において、SaaS プロキシに依存しないセルフホスト公開を実現するための基礎知識と実践ノウハウを提供し、読者が安全かつ効率的なサーバー運用を開始できるよう支援します。

Tailscale Funnel の仕組み：MagicDNS と WireGuard の融合

Tailscale Funnel を理解するには、まずその基盤となる Tailscale のネットワークアーキテクチャについて知る必要があります。Tailscale は、IP アドレスを介在させずに、ユーザーのデバイス間で安全な接続経路を作成します。これは主に WireGuard プロトコルの上に構築されたオーバーレイネットワークであり、NAT 透過性が高く、ファイアウォールやプロキシを越えても接続が確立されます。MagicDNS は、このネットワーク内でデバイスに対して人間が読みやすいドメイン名（例：myserver.tailnet-xxxx.ts.net）を自動的に割り当てる機能です。Funnel を有効化すると、この内部 DNS エントリがインターネットからもアクセス可能な形式へと拡張され、Tailscale がプロキシとして振る舞います。

具体的には、Funnel は Tailscale ネットワーク内のノード（サーバー）に対して、公開されたエンドポイントを提供します。ユーザーが Funnel URL にアクセスすると、そのリクエストは Tailscale の制御平面を経由し、許可されたルートを辿って宛先ノードに到達します。この際、データは常に暗号化された WireGuard チャンネルを流れるため、中間者攻撃や盗聴のリスクが極めて低減されます。Tailscale は TLS 終端も処理するため、外部からの通信は Tailscale のエッジサーバーで TLS 1.3 で復号され、内部の接続では再度暗号化されて宛先に届けられます。この二重の保護構造が、安全な公開を実現する鍵となっています。

また、Funnel は「特定のポートのみ」を公開するという制限を持っており、これがセキュリティの重要な要素となります。例えば、HTTP/HTTPS トラフィック用にポート 443 や 8443 を指定できますが、任意のポート番号を全て開放することはできません。この制限は、Funnel がオープンプロキシとして悪用されるのを防ぐための設計思想に基づいています。Tailscale の開発チームは、2025 年以降もセキュリティ要件を強化しており、ポートのホワイトリスト方式を採用することで、意図しないトラフィックの流入を防いでいます。これにより、ネットワーク管理者は複雑なファイアウォール設定を行わずとも、必要なサービスのみを選別して公開することが可能になります。

事前準備：Synology DS923+ と Raspberry Pi 5 の選定基準

自宅サーバーとして Tailscale Funnel を運用する際、ハードウェアの選定は性能とコストバランスに直結します。2026 年時点では、省電力かつ高性能な ARM 基盤や低消費電力 x86 CPU が主流となっていますが、用途に応じて最適な選択が必要です。ここでは、代表的な NAS システムである Synology DS923+ と、コンパクトなシングルボードコンピュータ Raspberry Pi 5 を例に挙げ、それぞれのスペックと Tailscale 導入におけるメリットを分析します。

Synology DS923+ は、Intel Celeron J4125 プロセッサ（Quad Core, 最大 2.0GHz）を搭載し、8GB の DDR4 RAM を標準で備えています。この CPU は 4K デコードをサポートしており、メディアサーバーとしての用途にも優れていますが、Tailscale Funnel のようなネットワーク公開用途では、その安定性と DSM システムの管理性が大きな強みとなります。DSM（DiskStation Manager）6.2 や 7.x では、パッケージセンターから Tailscale クライアントをネイティブにインストール可能です。また、8GB のメモリは Docker コンテナや複数のサービスを実行する際に十分な余裕があり、Funnel による追加のオーバーヘッドを十分に吸収できます。ただし、LAN ケーブル接続が必須であり、無線接続での安定性は Wired LAN に劣るため、有線環境での運用が前提となります。

一方、Raspberry Pi 5 は、Broadcom BCM2712（Quad-core Cortex-A76）を採用し、最大 8GB の LPDDR4X-4268 SDRAM をサポートしています。Pi 5 では USB-C で給電を行う必要があり、公式電源アダプター（USB-PD PD3.0 対応）を使用することで安定した動作が保証されます。Tailscale クライアントは Linux ARM アーキテクチャに対してネイティブにサポートされており、Docker コンテナ内での実行も非常に軽量です。特に Pi 5 の USB-C ポートは 10Gbps のデータ転送に対応しており、高速なファイル共有やバックアップとの相性が良好ですが、Fan（冷却ファン）の設置状況が温度管理に影響を与えるため、2026 年夏場などは放熱ケースへの交換を検討すべきです。

この表のように、DS923+ は拡張性と管理性の面で優れており、Raspberry Pi 5 は省電力とコンパクトさで優れています。Tailscale Funnel を利用する場合は、どちらのハードウェアでも問題なく動作しますが、セキュリティ要件が高い場合には、より堅牢な OS（例：Ubuntu Server 24.04 LTS）をインストールできる PC 形式の方が管理しやすい場合があります。また、2026 年時点では Docker コンテナ化された Tailscale クライアントが標準サポートされているため、OS のバージョンに依存しない運用が可能となっています。

ACL 設定の詳細解説：セキュリティとアクセス制御の設計

Tailscale Funnel を安全に運用するための核心は、Access Control List（ACL）の設定にあります。ACL は、誰がどのリソースにアクセスできるかを定義するルールセットであり、ゼロトラストネットワークの根幹となる機能です。Tailscale の ACL 設定ファイルは YAML 形式で記述され、非常に細かく制御が可能です。ここでは、2025 年の最新仕様に基づき、ACL の主要な項目とその意味を詳しく解説します。

まず、users 要素ではユーザー ID を指定し、hosts 要素で接続可能なホスト（デバイス）を定義します。Funnel を使う場合、この users は「インターネットからのアクセス権を持つユーザー」を指すことになります。具体的には、Tailscale の管理画面から取得したユーザー ID（例：user:12345678901234567890）や、特定のグループ ID を指定します。ports 要素では Funnel で公開するポートを指定し、src 要素でソース IP アドレスや CIDR ブロックを制限できます。例えば、特定のユーザーのみが特定ポートにアクセスできるルールを作成するには、users と ports を組み合わせた構造体を作成します。

# example_acl.yaml
acl:
  - action: accept
    src:
      - user:[email protected]
      - group:admins
    dst:
      - any:443 # HTTPS ポート
      - any:8443 # Tailscale Funnel 用ポート
    fmt:
      - "allow jane and admins to access funnels on port 443"

  - action: deny
    src:
      - ip:0.0.0.0/0
    dst:
      - any:* # すべてのポートをデフォルトで拒否
    fmt:
      - "deny all other traffic by default"

この YAML 設定では、まず特定のユーザーと管理者グループに対してポート 443 と 8443 を許可し、その後にすべての他のトラフィックを拒否するデフォルトルールを設定しています。これは「明示的に許可されたもののみが通る」というホワイトリスト方式です。2026 年以降のセキュリティトレンドでは、この最小権限の原則（Least Privilege）がより重視されており、ACL 設定の厳格化が進んでいます。また、src に特定の IP アドレス（例：ip:192.168.1.0/24）を指定することで、社内の LAN からのみ Funnel を利用可能にする制限も可能です。

さらに、Tailscale の ACL 設定には tags という概念も重要な要素です。タグはデバイスの役割（例：tag:server, tag:devops）を表すメタデータであり、ACL ルールでこのタグに基づいてアクセス制御を行うことができます。例えば、「すべてのサーバーデバイスへの SSH 接続を管理者グループに許可する」といったルールを簡潔に記述できます。2025 年以降の実装では、このタグベースの管理がより柔軟になり、動的なデバイス登録に対応できるようになっています。ACL の変更は Tailscale Web Console または CLI で即時反映されますが、誤設定による接続遮断を防ぐため、テスト環境での検証が推奨されます。

ポート制限と TLS 終端：443 番、8443 番、10000 番の役割

Tailscale Funnel は、セキュリティ上の理由から特定のポートにしかアクセスを許可しません。2025 年時点の仕様では、Funnel が直接公開可能な標準ポートは主に 443（HTTPS）、8443（代替 HTTPS）、および 10000（管理用）です。なぜこのような制限があるのか、その技術的な背景を理解することは、運用上のミスを防ぐために不可欠です。まず、ポート 443 は Web サーバーの標準的な HTTPS ポートとして広く認識されており、ブラウザや一般的なクライアントから最もスムーズにアクセスできます。Funnel を介して公開する場合、Tailscale が自動で TLS 証明書を発行・管理するため、ユーザーは手動で証明書の取得を行う必要がありません。

ポート 8443 は、ポート 443 がすでに他のサービスで使用されている場合の代替オプションです。一部の企業環境や家庭内ネットワークでは、ルーターレベルで既にポート 443 の開放が制限されているケースがあり、このポートを使用することで迂回した接続を可能にします。ただし、8443 番は標準的な Web ブラウザからのアクセス時に警告メッセージが表示されることがあるため、DNS レコードの調整やクライアント側の設定変更が必要になる場合があります。Tailscale はこれらのポートに対して、強固な TLS 1.3 エンドポイントを提供しており、通信の内容を暗号化して保護します。

ポート 10000 は、主に Tailscale Funnel の管理インターフェースや特定の診断機能に使用されるポートです。一般のユーザーが通常のリクエストで利用するのではなく、システム管理者が Funnel の状態を確認したり、設定を変更したりするために用います。このポートは外部からアクセスできないようにデフォルトで制限されている場合が多く、ACL 設定で明示的に許可する必要があります。2026 年の仕様では、これらのポートの割り当てルールがさらに厳格化される予定であり、新しいポート番号（例：8444）の追加も検討されていますが、現時点では標準的な 3 つのポートに絞られています。

これらのポート制限は、Funnel がオープンプロキシとして悪用されるのを防ぐための重要なセキュリティ対策です。Tailscale の設計思想では、「すべてのポートを開放する」のではなく、「必要な機能（Web サーバーなど）のみを安全に公開する」ことに重点が置かれています。ユーザーはこの制限を理解し、自社のサービスがどのポートに対応しているかを事前に確認しておく必要があります。また、SSL/TLS 証明書については、Tailscale が自動で Let's Encrypt と連携して発行・更新を行うため、有効期限切れによる接続停止のリスクを最小化できます。ただし、カスタムドメインを使用する場合は、DNS レコード（CNAME）の設定が必須となるため、注意が必要です。

Tailscale Serve と Funnel の違い：用途別の使い分け比較

Tailscale には「Serve」という機能もあり、これも自宅サーバーの公開に関連するため混同されやすいです。しかし、Serve と Funnel は設計思想と利用シーナリオが明確に異なります。Serve は主にローカルネットワーク内や信頼された Tailscale ネットワーク内でのファイル共有やサービス提供を目的としており、Funnel はインターネット全体からのアクセスを安全に公開することを目的としています。この違いを理解することは、適切な機能を選択し、セキュリティリスクを回避するために不可欠です。

Tailscale Serve は、特定のデバイス上でローカル Web サーバーとして動作します。例えば、Synology DS923+ の Synology File Station や Docker で動かしている Web アプリを、Funnel 経由で公開する場合と違い、Serve を使う場合は Tailscale クライアントが実行されている同一ネットワーク内のユーザーのみがアクセスできます。これにより、インターネットに直接露出することなく、内部ネットワーク内でファイルを安全に共有することが可能です。一方で、Funnel は外部のユーザー（家族や友人、あるいは特定のクライアント）に対して、あたかも公開サーバーであるかのように振る舞うことができます。

具体的な使い分けの判断基準として、アクセス元の信頼性とセキュリティ要件が挙げられます。もし、アクセス元が「Tailscale で接続された信頼されたデバイス」のみであれば Serve が最適です。これは設定も簡単で、ACL ルールを適用しなくてもローカルな Web サーバーとして機能します。しかし、「インターネット上の不特定多数」や「外部の信頼したパートナー」とのやり取りが必要であれば Funnel を使用する必要があります。Funnel は Tailscale のセキュリティ層（Magic DNS, ACL, TLS 終端）をすべて活用できるため、より堅牢な公開が可能となります。

Serve を使う場合、Tailscale CLI の tailscale serve コマンドを使用し、ポートマッピングを設定するだけで完了します。一方 Funnel は Tailscale Web Console での設定や ACL ファイルのアップロードが必要になるため、手間がかかりますが、その分セキュリティレベルが高いです。2026 年においては、Serve が IoT デバイスのローカル制御に、Funnel が業務用サーバーの公開に使われるという傾向が強まると予想されます。

Cloudflare Tunnel と ngrok との徹底比較：コストと機能

自宅サーバーを公開する手段として、Tailscale Funnel の他に Cloudflare Tunnel や ngrok といったサービスも広く知られています。これらはそれぞれに長所と短所があり、ユーザーのニーズや予算に応じて選択する必要があります。ここでは、2025-2026 年の市場状況に基づき、各サービスの無料枠、機能、コストを詳細に比較します。特に SaaS プロキシを利用する場合と Tailscale のようなオーバーレイネットワークを利用する場合の違いを理解することが重要です。

Cloudflare Tunnel は、非常に人気のある公開手段で、DNS と CDN を提供します。その最大の利点は、Cloudflare のグローバルな CDN エッジを通じて、高い可用性と高速なアクセスを提供できる点です。また、無料枠でも SSL 証明書が自動発行され、DDoS 保護機能も標準装備されています。しかし、Tailscale Funnel と比較すると、Cloudflare Tunnel は Cloudflare のネットワークインフラに依存するため、完全な P2P（ピアツーピア）接続ではなく、必ず Cloudflare のサーバーを介在させることになります。これはセキュリティの観点からはメリットですが、一部の超低遅延環境ではわずかなレイテンシ増となります。

ngrok は、特に開発環境でのテンポラリ公開（トンネルリング）として非常に強力です。ブラウザ上の URL を生成し、すぐに外部からアクセス可能にするため、デバッグやデモ用途に適しています。しかし、永続的なサーバー公開には向いておらず、無料プランでは帯域幅や接続時間が制限されています。また、ngrok は Tailscale Funnel と異なり、必ず ngrok のエッジを経由するため、IP アドレスの固定化が難しくなります（Pro プランで IP 固定可能）。

Tailscale Funnel の最大の強みは、セキュリティと自己管理のバランスにあります。Cloudflare Tunnel や ngrok は SaaS プロキシを介在させるため、データの完全な制御が困難になる場合があります。一方 Tailscale は、ユーザー自身が ACL を設定し、アクセス権限を厳密にコントロールできるため、機密性の高いデータを含むサーバー公開に適しています。2026 年においては、SaaS プロバイダへの依存度を下げる傾向が強まっており、Tailscale Funnel のような「セルフホストに近いセキュリティ」を提供するソリューションがより重視されるでしょう。

セルフホスト環境での運用とトラブルシューティング

自宅サーバーを公開する際、実際に設定を行ってみると予期せぬ問題が発生することがあります。特に Synology DS923+ や Raspberry Pi 5 のような特定のハードウェアでは、OS やファームウェアのバージョンによっては動作に相違が生じる場合があります。ここでは、一般的なトラブルシューティング手順と運用上のベストプラクティスを解説します。Tailscale Funnel を有効化した後、接続できない場合やパフォーマンスが低下する場合の対処法を具体的に示します。

まず、基本的な確認事項として、Tailscale クライアントが正常に起動しているかを確認する必要があります。Synology DS923+ では、パッケージセンターから Tailscale をインストールし、ログイン画面で認証を行う必要があります。この際、ユーザー ID が一致していないと Funnel が有効化されません。また、Raspberry Pi 5 の場合、Linux コマンドラインで tailscale status を実行し、ステータスが "active" であることを確認します。接続が不安定な場合は、Wi-Fi 環境ではなく有線 LAN 接続を推奨します。無線接続は電波干渉の影響を受けやすく、Tailscale の暗号化通信においてパケットロスが発生する可能性があります。

次に、ACL ルールの設定ミスによる接続拒否も頻繁に見られます。Funnel の ACL 設定をアップロードした直後にアクセスできない場合、acl ファイルの構文エラーや、ユーザー ID の指定漏れが考えられます。Tailscale Web Console の「ACL」セクションで設定を確認し、変更履歴を遡って確認することが有効です。また、DNS 解決の問題も考慮する必要があります。Funnel URL（例：myserver.tailnet-xxxx.ts.net）へのアクセス時に DNS レコードが正しく反映されていない場合があります。この場合、Tailscale の MagicDNS が機能しているかを確認し、必要に応じて /etc/hosts ファイルを編集して手動マッピングを行うことで解決できます。

2025 年以降のバージョンアップでは、これらのエラーメッセージがより詳細に出力されるようになりました。ログファイルを確認する際、/var/log/tailscaled.log を参照し、エラーコード（例：err: connection refused）から原因を特定できます。また、Tailscale の開発チームは 2026 年に向けて、自動的な接続経路最適化機能を強化予定であり、将来的にはユーザーが手動で設定する手間が減ることが期待されます。

2026 年に向けた拡張性と将来展望

Tailscale Funnel は、2026 年およびその先を見据えたネットワークアーキテクチャにおいて重要な役割を果たすでしょう。近年のトレンドとして、クラウドサービスへの依存を減らし、コストとセキュリティのバランスを取る「ハイブリッド・クラウド」や「エッジコンピューティング」が注目されています。Tailscale Funnel は、これらの新しいモデルに適合する柔軟な公開手段を提供します。特に、SaaS プロキシのコスト削減ニーズが高まる中で、Tailscale のセルフホストに近い運用が可能である点は強みです。

2026 年時点では、IoT デバイスのセキュリティリスクが深刻化しており、家庭用ルーターの NAT ポート開放を避ける傾向が強まっています。Funnel はこの要件に合致し、外部からのアクセスを許可しつつも、ネットワーク境界を越えたアクセス制御を可能にします。また、Tailscale の開発チームは、2025 年より IPv6 への完全対応を進めており、将来的には IPv4/IPv6 両方の環境下でシームレスな接続を提供する予定です。これにより、グローバルなネットワーク構成でも Funnel が安定して動作することが期待されます。

さらに、Tailscale のエコシステムは拡大しており、他のツールとの連携が強化されています。例えば、Kubernetes や Docker Swarm などのコンテナオーケストレーションプラットフォームと Tailscale を連携させることで、マイクロサービスアーキテクチャの安全な公開が可能になります。2026 年には、AI ベースのトラフィック分析機能も組み込まれる予定であり、異常なアクセスパターンを検知して自動的に ACL ルールを調整する「インテリジェント・セキュリティ」機能が実装されるでしょう。これにより、ユーザーは手動で設定を行うことなく、より高度な保護を受けられるようになります。

まとめ

本記事では、Tailscale Funnel を活用した自宅サーバーの安全かつ効率的な公開手法について、詳細に解説しました。要点を以下にまとめます。

• 基本機能: Tailscale Funnel は WireGuard トンネルを活用し、SaaS プロキシ不要で TLS 終端付きの公開を実現します。
• セキュリティ: ACL ルールによるアクセス制御が可能で、最小権限の原則に基づいた設定によりリスクを低減できます。
• ポート制限: ポート 443, 8443, 10000 のみが標準的に許可され、これらを利用することで安全な公開が保たれます。
• 比較: Cloudflare Tunnel や ngrok と比較し、コストとセキュリティの観点で Tailscale Funnel の優位性を確認しました。
• 運用: Synology DS923+ や Raspberry Pi 5 での設定手順やトラブルシューティング方法を具体的な例と共に提示しました。
• 将来展望: 2026 年のネットワークトレンドにおいて、SaaS 依存脱却とセキュリティ強化の要となる技術として注目されます。

Tailscale Funnel は、自宅サーバーを公開する際に「安全」と「簡単」の両立を実現するための強力なツールです。2025-2026 年においては、クラウドコストの最適化と自己管理の重要性が高まるため、この技術を理解し適切に運用できることは、ネットワーク管理者としての重要なスキルとなります。

よくある質問（FAQ）

Q1: Tailscale Funnel は無料で使えるのでしょうか？ Tailscale の基本機能は無料枠で提供されていますが、Funnel 機能を完全に利用するには、有料プラン（Pro または Business）へのアップグレードが必要な場合があります。ただし、2025 年時点では個人利用者に対して一定の制限内で Funnel を使用できる特典が適用されることもあります。具体的には、ユーザー数やデバイス数に制限があるため、大規模な環境では有料プランの利用を検討してください。

Q2: Funnel を有効化すると、すべてのポートが開通してしまいますか？ いいえ、Open しません。Funnel はセキュリティのため、特定のポート（443, 8443, 10000 など）にしかアクセスを許可しません。ACL 設定で明示的に指定されたポートのみが外部から接続可能となり、それ以外のポートは依然としてブロックされたままです。

Q3: Cloudflare Tunnel と Tailscale Funnel の速度の違いはありますか？ Cloudflare Tunnel は CDN エッジを経由するため、地理的な距離によっては高速になる場合があります。一方、Tailscale Funnel は WireGuard を使用するため、一般的に低いレイテンシを実現します。ただし、データが Tailscale のサーバーを通過する必要があるため、経路によっては Cloudflare と同等かそれ以上の速度が出ることもあります。

Q4: Synology DS923+ で Docker 内に Funnel を入れることはできますか？ はい、可能です。Synology DSM 上で Docker コンテナを作成し、その中で Tailscale クライアントを起動して Funnel を設定できます。ただし、コンテナがホストのネットワークにアクセスできる権限（--network=host）が必要であるため、適切な設定を行う必要があります。

Q5: Funnel を使った場合、自宅の IP アドレスは外部に公開されますか？ いいえ、公開されません。Tailscale はオーバーレイネットワークを構築し、ユーザー自身の IP アドレスを隠蔽します。外部からのアクセスは Tailscale のエッジサーバーを経由するため、自宅のグローバル IP アドレスが露出することはなく、攻撃経路として特定されるリスクが低減されます。

Q6: 2026 年に Tailscale は IPv6 に対応すると聞きましたが、今のところどうですか？ Tailscale は 2025 年より IPv6 サポートを強化しており、多くの環境で IPv4/IPv6 の自動切り替えが可能になっています。Funnel を利用する際も、クライアントが IPv6 ネットワークに属している場合、自動的に IPv6 ルート経由で接続されるよう設定されています。

Q7: Funnel 有効化後にアクセスできない場合の最初の確認点は？ まず Tailscale CLI で tailscale status を実行し、Funnel が「enabled」になっているか確認してください。次に、ACL ファイルに正しいユーザー ID とポート番号が指定されているか確認します。最後に、Web ブラウザから Funnel URL（例：myserver.tailnet-xxxx.ts.net）へのアクセスを試みます。

Q8: Tailscale Serve と Funnel を同時に使うことは可能ですか？ はい、可能です。Serve はローカルネットワーク内での共有に、Funnel はインターネット公開に使用されます。ただし、同じポート番号（例：443）を両方で使用する場合は競合するため、異なるポートまたはドメインで設定する必要があります。

Q9: 自宅サーバーの消費電力は Funnel を使うことで増えますか？ わずかに増加します。Funnel は暗号化処理やネットワークパケットの転送を行うため、CPU に負荷がかかりますが、Synology DS923+ や Raspberry Pi 5 のような最近のハードウェアであれば、その負荷は無視できる範囲です。

Q10: Funnel の設定を間違えても復元は可能ですか？ はい、Tailscale Web Console から ACL 設定を編集し直せば即座に反映されます。また、ACL ファイルの変更履歴が保持されるため、誤った設定を直ちにロールバックすることも可能です。ただし、変更前の状態を把握しておくことが推奨されます。