セルフホスティングによるデータ主権：リバースプロキシとIngressトンネルのオープンソースシフト
Quick answer
セルフホストngrok代替案：frp、Zrok & Inletsによるデータ管理: quick answer
If free tunnel limits interrupt your workflow, compare session length, stable URLs, concurrent tunnels, and paid-plan pricing before choosing a localhost tunnel tool.
What free tunnel limits should developers check first?
Check session duration, URL stability, concurrent tunnels, custom subdomains, bandwidth or request limits, and whether webhook callbacks survive restarts.
How does InstaTunnel handle longer development sessions?
InstaTunnel Free is designed around 24-hour sessions, with Pro available for higher limits and MCP endpoint tunnel workflows.
はじめに：エンタープライズIngressのジレンマ
現代のクラウドネイティブアーキテクチャでは、開発者や運用チームはしばしば次の課題に直面します：内部サービス、ステージング環境、エッジデバイス、またはローカルKubernetesクラスターを外部ネットワークやクライアントトラフィックに安全に公開するにはどうすればよいか？
長年にわたり、ngrokのようなマネージド開発者ツールが標準となってきました。シンプルなコマンドライン呼び出しで、エンジニアはNAT（Network Address Translation）をバイパスし、CGNAT（Carrier-Grade NAT）と交渉し、ローカルポートに直接マッピングされた公開HTTPS URLを確立できました。
しかし、組織の規模拡大やクラウドネイティブワークロードの成熟に伴い、サードパーティのSaaS ingressトンネルへの依存はアーキテクチャや規制の摩擦を引き起こします。内部トラフィックがサードパーティ管理のSaaSサーバーを経由すると、そのインフラは直接データパスに位置し、企業のセキュリティアーキテクト、コンプライアンスマネージャー、インフラエンジニアにとって懸念事項となります。
GDPR、HIPAA、SOC 2 Type II、PCI-DSS、EUのNIS2指令などのデータ保護フレームワークは、組織がペイロードデータ、サードパーティの露出、インシデント対応をどのように扱うかを規定しています — ただし、下記の通り、すべてが同じことを規制しているわけではなく、何の法律が何を規制しているかを正確に理解しておくことが重要です。
代替案はセルフホスト型のデータ主権です：コントロールプレーンとデータプレーンの両方を自組織で管理し、サードパーティのテレメトリーを排除し、ゼロトラストアクセス制御を実施し、自組織のコンプライアンス義務を直接満たすことです。本ガイドでは、そのシフトを推進する4つの本番レベルのオプション — frp（Fast Reverse Proxy）、zrok（OpenZitiを基盤）、Inlets、そして新たに登場したPangolin — を、2026年8月時点の各プロジェクトのドキュメントとソースコードに基づき解説します。
1. データ主権に向けたコンプライアンスとアーキテクチャの推進
SaaS ingressトンネルがコンプライアンスを複雑にする理由
マネージドトンネリングSaaSプラットフォームはマルチテナントのリバースプロキシシステムとして動作します。ローカルエージェントがSaaSプラットフォームにトンネルを作成すると：
- トラフィックのインターセプトと復号化： TLSは一般的にSaaS提供者のエッジで終了し、リクエスト検査やWebhookログ、Webダッシュボードなどの機能統合を可能にしますが、そのために一時的にアプリケーションデータの復号化された状態がメモリに保持されます。
- 制限されたテレメトリーと監査コントロール： 組織は、トランジットログの保存場所やリクエスト/レスポンス本文の保持期間を完全に確認できないことが多いです。
- サプライチェーンと単一障害点リスク： SaaS提供者の障害やセキュリティインシデントは、内部エンドポイントの可用性と機密性に影響を及ぼす可能性があります。
これは厳密には二進法的な問題ではありません — 例えばngrokは、「Bring Your Own Cloud」（BYOC）展開モデルや、顧客の環境内で動作する専用プライベートエディションなど、この種の懸念に対応したエンタープライズ層のオプションも提供しています。セルフホスティングは、コントロールプレーンとデータプレーンを完全に自組織の運用下に置きたいチームにとって、より完全な解決策ですが、サードパーティの露出を減らす唯一の方法ではありません。
[ 従来のSaaSトンネルフロー - 主権リスク ]
ローカルサービス --- ローカルトンネルエージェント --- [ 管理されたSaaSクラウド ] --- 公開ユーザー / クライアント
(TLS終了
データパス露出)
[ セルフホストトンネルフロー - 完全なデータ主権 ]
ローカルサービス --- ローカルトンネルエージェント --- [ エンタープライズセルフホストゲートウェイ ] --- 公開ユーザー / クライアント
(完全なセキュリティ運用とコンプライアンスポリシーの下)
規制環境を正しく理解する
GDPR、HIPAA、PCI-DSS、SOC 2、NIS2を「データ主権が必要な理由」とまとめたくなるところですが、それぞれが果たす役割は異なり、混同すると適切なコントロールを構築しづらくなります：
- GDPRは、個人データの流れと保存場所に最も直接関係し、越境転送制限やデータ居住性の期待が中心です。
- HIPAAは、米国の医療分野における保護された健康情報（PHI）を規制し、アクセス制御や監査証跡、輸送中および静止中のPHIの保護を規定します。
- PCI-DSSは、カード保持者データに特化し、ネットワークのセグメント化、輸送中の暗号化、第三者を含むアクセス制御を規定します。
- SOC 2 Type IIは、信頼サービス基準（セキュリティ、可用性、機密性など）に基づく認証フレームワークであり、法律ではなく、時間をかけてコントロールが効果的に機能していることを示すためのものです。
- NIS2（EU指令2022/2555）は、EUの重要・重要インフラ事業者に対するサイバーセキュリティリスク管理とインシデント報告の指令です — リスク管理措置、24時間以内のインシデント報告、サプライチェーンのセキュリティ要件、経営層の責任を義務付けています。GDPRのようにデータ居住性法として機能するわけではありませんが、そのサプライチェーン規定は、サードパーティの露出リスクに直接関係し、トンネリングの議論とも関連します。
実務的なポイントは、これらすべてのフレームワークに対して、第三者の数を最小化することでリスクを同時に低減できることです。ただし、特定の規制をコンプライアンスチームに伝える場合は、実際に何を規制しているかを正確に示す必要があります。
エッジとトンネリングアーキテクチャにおけるデータ主権の定義
リモートアクセスとサービス露出のアーキテクチャで真のデータ主権を実現するには、一般的に次の3つが必要です：
- コントロールプレーンの分離 — 認証ポリシー、IDプロバイダー統合、ルーティング設定はすべて自組織のインフラ内で行う。
- データプレーンの分離 — ペイロードトラフィックは、クライアントまたはIngressプロキシからバックエンドまでエンドツーエンドの暗号化を維持し、非契約第三者を経由しない。
- 監査性とゼロトラストガバナンス — 接続イベント、バイト転送、認証決定は直接自組織のSIEMやIDスタックにフィードされる。
2. セルフホスト型ngrok代替の技術評価基準
セルフホスト型ngrok代替を選定する際は、次の点を考慮してください：
- プロトコルとレイヤーの柔軟性 — Layer 7（HTTP/1.1、HTTP/2、gRPC、WebSockets）およびLayer 4（TCP、UDP、データベースワイヤープロトコル）に対応しているか？
- ゼロトラストネットワークアクセス（ZTNA）統合 — 公開リッスンポートを使用するか、アウトバウンドのみでIDベースのアクセスが可能か？
- Kubernetesネイティブ機能 — Ingressコントローラー統合、CRD、自動プロビジョニングはあるか？
- パフォーマンスと多重化のオーバーヘッド — コネクションプール、キープアライブ、並列時のレイテンシはどうか？
- ライセンスとサポート体制 — オープンソースか、ソースコード利用可能か、商用サポートはあるか？
3. セルフホストソリューションの詳細
3.1 frp（Fast Reverse Proxy）
frpはGoで書かれた成熟した高性能なリバースプロキシで、fatedierと貢献者によって管理されています。NATやファイアウォール背後のローカルサーバーを公開するために設計されており、エッジコンピューティング、IoT管理、ハイブリッドエンタープライズ環境で広く展開されています。Apache License 2.0のオープンソースであり、その点は正しいです。
+----------------------------------+
| セルフホストクラウド / VPS |
| |
クライアント =======| frps (FRPサーバー) |
(インターネット) | - パブリックポート待ち受け |
| - TLS / 多重化処理 |
+----------------------------------+
^
| 暗号化制御
| データトンネル（多重化）
v
+----------------------------------+
| プライベートエンタープライズネット |
| |
| frpc (FRPクライアント) |
| | |
| v |
| 内部アプリ / API / DB |
+----------------------------------+
アーキテクチャ。 frpは二重バイナリモデルを採用：frpsはパブリックサーバー上で動作し、ポートマッピングとルーティングを担当。frpcはプライベートネットワーク内で動作し、frpsへのアウトバウンド接続を維持します。
トランスポートオプション。 frpはTCPリレー以上のトランスポートをサポートし、transport.protocolフィールドはtcp、kcp（UDPベースの低遅延プロトコル）、quic、websocket、wssを受け入れます。特にQUICは高遅延や損失の多いリンクに有効で、UDP上でストリームを多重化し、ヘッド・オブ・ラインブロッキングを回避します。
プロキシタイプ。 frpは以下のモードをサポートします：
- TCP / UDP — データベース、SSH、カスタムソケットのLayer 4直接公開
- HTTP / HTTPS — ドメインベースの仮想ホスティングとヘッダー/URL書き換えを伴うLayer 7公開
- STCP（Secret TCP） — 共有キーの証明を必要とし、ポートスキャナーからサービスを隠す
- XTCP（P2P TCP） — STUNスタイルのネゴシエーションを用いて、クライアント間の直接P2P接続を試みる
新機能。 frpにはα段階のVirtualNet機能があり、featureGates = { VirtualNet = true }フラグで有効化可能です。これはTUNインターフェースを作成し、マシン間のIPレベルのルーティングを行うもので、従来のポートフォワーディングよりも軽量なメッシュネットワークに近いです。現在はroot/admin権限が必要で、LinuxとmacOSでサポートされています。別途、開発者はfrpのv2をEnvoyのような拡張性の高いL4/L7プロキシコアを中心に構築中と公表していますが、v1とはワイヤ互換性はなく、開発初期段階です。今後の展望として、プロダクションでの運用は避けてください。
設定例（現行TOMLフォーマット）：
# frps.toml (サーバー)
bindPort = 7000
vhostHttpsPort = 443
auth.method = "token"
auth.token = "SUPER_SECRET_ENTERPRISE_TOKEN_CHANGE_ME"
webServer.addr = "127.0.0.1"
webServer.port = 7500
webServer.user = "admin"
webServer.password = "STRONG_DASHBOARD_PASSWORD"
transport.tls.force = true
# frpc.toml (クライアント)
serverAddr = "tunnel-gateway.yourcompany.com"
serverPort = 7000
auth.method = "token"
auth.token = "SUPER_SECRET_ENTERPRISE_TOKEN_CHANGE_ME"
transport.protocol = "quic" # "tcp", "kcp", "websocket", "wss"もサポート
transport.tls.enable = true
[[proxies]]
name = "internal-api-service"
type = "https"
customDomains = ["api-staging.yourcompany.com"]
強み。 軽量でシングルバイナリのランタイム、外部依存なし、リソース負荷が低い、多層L4/L7ルーティングとP2P（XTCP経由）、Apache-2.0ライセンスのオープンソース、アクティブなメンテナとリリースサイクル。
トレードオフ。 ID/アクセス管理の組み込みがなく、L7ルートのセキュリティはNginxやTraefik、Caddy、OAuth2プロキシと併用する必要があります。VirtualNetはα版であり、商用運用には適していません。
3.2 zrok（OpenZitiを基盤としたゼロトラスト）
zrokはNetFoundryが管理するオープンソースプロジェクトで、OpenZitiを基盤としています。OpenZitiとzrokのコアはApache License 2.0のオープンソースであり、NetFoundryの公式ドキュメントから直接確認済みです。NetFoundryは、OpenZitiの運用支援やエンタープライズサポートを提供するライセンス管理スイートも販売していますが、ファブリック自体にはライセンスコストはかかりません。
+---------------------------+
| OpenZiti Fabric |
| (セルフホストコントローラー |
| Zitiルーター) |
+---------------------------+
/ \
出口制御とデータチャネル / \ 出口制御とデータチャネル
v v
+-------------------------------+ +----------------------------------+
| クライアントデバイス / 消費者 | | プライベートサービス環境 |
| | | |
| zrokアクセス（mTLSエフェメラル）|===| zrok共有（ダークエンドポイント） |
| インバウンド攻撃なし | | 開放されたインバウンドファイアウォールポートなし |
| サーフェス | | ネイティブマイクロセグメンテーション |
+-------------------------------+ +----------------------------------+
モデル。 zrokは開放されたインバウンドファイアウォールポートを排除します。共有側（プライベートAPIやアプリ）と消費側のクライアントは、アウトバウンドのみのmTLSでOpenZitiファブリックに接続し、アクセスはIDによって管理されます。
共有モード。 zrokは複数のバックエンドモードをサポートします：proxyはターゲットアドレスへのフォワード、webはディレクトリを静的サイトとして提供、driveはWebDAV経由でディレクトリを仮想ネットワークドライブとして公開し、zrok copyコマンドで一方向同期も可能です。
セルフホスティングの正確な説明。 本番環境のセルフホスト展開は、「Dockerコンテナをいくつか立ち上げる」だけではありません。現在のガイドは、OpenZitiコントローラーとルーター、次にzrokコントローラー、複数のzrokフロントエンド、メトリクスブリッジ（PostgreSQL、RabbitMQ、InfluxDBをバックエンドに）を立ち上げる手順を解説しています。これは実際のマルチコンポーネントシステムであり、ライセンス表の操作上のトレードオフを正しく示しています。
セキュリティの微妙なポイント。 zrokのデフォルト設定では、公開・非公開の共有は「オープン」の権限モードを使用します：zrokインスタンスのユーザーは、共有トークンを知っていればアクセス可能です。zrok shareの--closedフラグ（--access-grant <email>と併用して特定アカウントを指定）を付けると、プライベート共有は明示的に許可されたIDだけに制限されます。ゼロトラストのストーリーを意識して展開する場合は、--closedと明示的アクセス許可の設定が必要です。デフォルトは「ゼロトラスト」にはやや緩い設定です。
CLI例の修正例。 元の例はトークン形式が非代表的で、クライアントの--bindフラグも不要でした。より正確な例は次の通りです：
# 1. CLIをセルフホストインスタンスに向けて認証
zrok login --api-endpoint https://zrok.yourcompany-internal.net <api-token>
# 2. ローカルサービスをプライベートに共有（特定アカウントに制限）
zrok share private --headless --closed --access-grant teammate@yourcompany.com 127.0.0.1:9090
# 出力に共有トークン例（例：wr3hpf2z5fiy）
# 3. 承認済みマシンからプライベート共有にアクセス
zrok access private wr3hpf2z5fiy
強み。 真のゼロポートモデルで、ネイティブのmTLSとマイクロセグメンテーションを実現。Apache-2.0ライセンスの完全オープンソースで、HTTP以外のバックエンドモード（ファイル、WebDAV）もサポート。共有ごとに細かくアクセス制御できるパーミッションモードも備えています。
トレードオフ。 単一バイナリのリバースプロキシよりも運用の複雑さが高く、コントローラー、ルーター、フロントエンド、メッセージブローカー、メトリクスストアなどの分散システムを運用する必要があります。デフォルトのパーミッションモードは、「ゼロトラスト」フレームに比べて緩い設定です。
3.3 Inlets
こちらが最も大きな修正を要した部分です。Inlets Proはオープンソースではありません。 もともとのHTTP限定の「inlets OSS」プロジェクト（v1/v2）は無料でオープンソースでしたが、そのGitHubリポジトリは既に廃止され、更新も停止しています。現在積極的にメンテナンスされている製品はInlets Proで、Alex Ellis（OpenFaaS創設者）が開発したクローズドソースのバイナリで、商用エンドユーザーライセンス契約の下で配布されています。ソースコードは公開されていません。周辺ツールのinlets-operator（KubernetesのLoadBalancerサービス用の出口ノードVM自動プロビジョニング）やinletsctl（出口サーバ作成用CLI）は別途オープンソースですが、それらが管理するトンネルエンジンは商用ソフトウェアです、「デュアルライセンスのオープンソース」ではありません。
+-------------------------------------------------------------------------+
| パブリッククラウドVPS / エッジゲートウェイ |
| |
| +-----------------------------------------------------------------+ |
| | inlets-pro出口ノード（パブリックトラフィック受信） | |
| | ポート80 / 443で待ち受け | |
| +-----------------------------------------------------------------+ |
+-------------------------------------------------------------------------+
^
| セキュア制御＆データトンネル
| 暗号化WebSocket / TLS
v
+-------------------------------------------------------------------------+
| プライベートエンタープライズKubernetesクラスター |
| |
| +-----------------------------------------------------------------+ |
| | inlets-operator（出口ノード自動プロビジョニング） | |
| +-----------------------------------------------------------------+ |
| | |
| +-------------------------------+---------------------------------+ |
| | inlets-proクライアント（多重化トラフィック） | |
| +-----------------------------------------------------------------+ |
| | |
| v |
| +-----------------------------------------------------------------+ |
| | Ingress-Nginx / Traefik / Envoyサービス（ClusterIP） | |
| +-----------------------------------------------------------------+ |
+-------------------------------------------------------------------------+
得意な点。 inlets ProはLayer 4 TCPを暗号化WebSocket経由でトンネルし、TLS SNIの検査やmTLS、cert-managerの自動化に必要な生のTCPを扱います。inlets-operatorはクラウドのロードバランサが利用できない環境で、LoadBalancerタイプのServiceを監視し、サポートされたクラウド上に小規模なVMを自動作成し、トンネルを自動設定します。これは、ベアメタルやオンプレミス、エッジKubernetesに非常に有効です。
apiVersion: v1
kind: Service
metadata:
name: ingress-nginx-controller
namespace: ingress-nginx
annotations:
dev.inlets.operator/provider: "digitalocean"
dev.inlets.operator/region: "ams3"
dev.inlets.operator/plan: "s-1vcpu-1gb"
spec:
type: LoadBalancer
ports:
- name: http
port: 80
targetPort: http
- name: https
port: 443
targetPort: https
selector:
app.kubernetes.io/name: ingress-nginx
新しい点。 Alex Ellisのチームは、Inlets Uplinkも提供しており、これはSaaSやプラットフォームチーム向けに、多数の顧客向けトンネルをKubernetesコントロールプレーンから運用できるように設計されています。料金は定額のコントロールプレーン費用とトンネルごとの課金で、商用ライセンスによる提供です。
強み。 Kubernetesに最適化されており、L4 TCPの透過性とcert-manager統合、主要クラウドへの自動出口ノードプロビジョニング、商用サポート体制があります。
トレードオフ。 商用ソフトウェアのライセンスを取得する必要があり、監査やフォーク、無償運用はできません。完全にオープンソースの依存を避けたい場合は、OpenFaaSのinletsと比較して検討してください。
3.4 Pangolin — 新しい注目のプレイヤー
比較のタイミングで追加すべきは、Pangolinです。これはWireGuard（カスタムユーザースペースクライアントNewt経由）とTraefikを基盤とし、IDとアクセス管理を最初から組み込んだセルフホスト型のリバースプロキシプラットフォームです。Cloudflare Tunnelのセルフホスト版として位置付けられ、急速に注目を集めています。GitHubスターは12,600以上、インストール数は140,000超（5ヶ月以内）と報告されています。オープンソースであり、付加的に自動フェイルオーバーを可能にするマネージドクラウド層も提供しています。
frp、zrok、Inletsとの比較。 Pangolinは、上記のfrpのギャップを埋めることを目的としています。自己ホスト型のトンネルで、SSO認証、ロールベースアクセス制御、TOTP、リソースごとのアクセスルールを標準装備し、OAuth2プロキシやOpenZitiの導入なしにこれらを実現します。zrokのゼロポート純粋性（中央サーバーが接続を終了し到達可能である必要がある）を一部犠牲にし、frpの最小限性と比べてID管理機能を内蔵しています。
4. アーキテクチャ比較マトリクス
| 機能 | ngrok（SaaS） | frp | zrok（OpenZiti） | Inlets Pro | Pangolin |
|---|---|---|---|---|---|
| データ主権 | デフォルトは制限付き、エンタープライズプランでBYOC/プライベートエディション利用可能 | 完全制御 | 完全制御 | 完全制御（エンジンは商用ソフト） | 完全制御 |
| ライセンス | プロプライエタリSaaS | オープンソース（Apache 2.0） | オープンソース（Apache 2.0） | 商用（クローズドソース、ライセンスキー） | オープンソース |
| ネットワーク層サポート | L4 & L7 | L4（TCP/UDP）、L7（HTTP/S）、P2P、実験的IPレベルVirtualNet | L4 & L7 overゼロトラストファブリック、ファイル/WebDAVも | L4 TCP & L7 HTTP/WebSockets | L4（WireGuard） & L7（Traefik経由） |
| インバウンドファイアウォールポート | 不要（SaaS） | frps側で開放必要 |
不要（デフォルトはダーク） | Exitノード側で開放必要 | 保護対象リソース側で不要 |
| Kubernetes連携 | カスタムIngressコントローラー | 手動/Helm | Operator / SDK | inlets-operatorネイティブ |
Kubernetes非ネイティブ |
| ID/アクセス制御 | SaaS OAuth / IPホワイトリスト | トークン認証、外部IdP必要 | ネイティブmTLS、パーシェア許可モード | ライセンスキー認証、TLS | 組み込みSSO、RBAC、TOTP |
| 展開規模 | クラウドSaaS +ローカルエージェント | 二重シングルバイナリ（frps/frpc） |
コントローラー＋ルーター＋フロントエンド＋メトリクス | ExitノードVM＋クライアント | 中央サーバ＋Traefik＋Newtクライアント |
5. セルフホストIngressトンネルのセキュリティ強化ブループリント
セルフホストゲートウェイの導入は、セキュリティガバナンスを完全に内部のSecOpsチームに委ねることになります。運用チェックリスト例：
+---------------------------------------------------------------------------------------------------+
| 本番環境セキュリティ強化チェックリスト |
+---------------------------------------------------------------------------------------------------+
| [1] TLS 1.3厳格適用 -- TLS 1.3を終了またはパススルーし、レガシー暗号を無効化 |
| [2] IDプロキシ＆OIDC -- OAuth2-Proxy / Keycloakで公開L7エンドポイントをゲート |
| [3] レートリミット＆DDoS -- eBPF/Nginxで接続制限とバースト制御 |
| [4] 監査テレメトリー連携 -- JSON接続ログをSIEMに直接送信（Splunk/Datadog） |
| [5] 最小権限のセグメンテーション -- Docker / AppArmor / SELinuxでトンネルエージェントを隔離 |
+---------------------------------------------------------------------------------------------------+
- OAuth2/OIDCをゲートウェイレベルで強制。 管理パネルや未認証のステージングAPIを直接公開しない。
frpsやInlets出口ノードをOAuth2-Proxy、Authelia、またはAuthentikと連携させ、企業のIdPをバックエンドに設定します。（zrokやPangolinは、よりネイティブにIDを強制します — 上記参照） - 爆発範囲のセグメント化。 トンネルクライアントは隔離されたコンテナネットワークや非特権Linuxユーザー内で動作させ、Kubernetesの
NetworkPolicyで侵害されたポッドが隣接サービスをスキャンできないようにします。 - 監査ログの集中化。 接続ライフサイクルのログ（送信元IP、TLSハンドシェイクパラメータ、バイト数、トークンID）を不変のログストアやSIEMに送信します。
[ トンネルゲートウェイ ] --- [ Syslog / Vectorエージェント ] --- [ SIEM：Splunk / Elastic / Datadog ]
6. 戦略的推奨事項
- ローカル開発・ステージング・IoTフリート： frpは、内部APIやSSHソケット、エッジハードウェア向けの軽量・ゼロコスト・真のオープンソーストンネルの最速ルートです。
- 厳格なゼロトラスト／規制環境で、インバウンドポート不要な場合： zrokは、
--closed共有を意図的に設定し、--openのデフォルト権限モードに頼らず、OpenZitiファブリックの運用に同意できる場合に適します。 - クラウドネイティブ、オンプレミス、ハイブリッドKubernetes ingress： Inlets Proは、商用ソフトウェアのライセンスを理解した上で導入してください。
- 少人数チームやセルフホストユーザーで、OpenZitiやKubernetesを立ち上げずにSSOゲートアクセスを実現したい場合： Pangolinは最も新しく、特定のユースケースにおいて最も低摩擦の選択肢です。
結論
マネージドSaaS ingressトンネルからの脱却は確かに進んでいますが、その理由付けもアーキテクチャと同じくらい厳密であるべきです。すべてのコンプライアンスフレームワークが想定通りの規制をしているわけではなく、Inlets Proのように完全にクローズドソースの製品もあります。frp、zrok、Pangolinは、実際にオープンソースであり、データパスを完全に自組織の管理下に置いています。一方、Inlets Proはデータパスを管理しつつ、そのエンジンは有料のクローズドソース製品です。どちらがどちらかを理解することは、正確なコンプライアンス議論と、ベンダーセキュリティレビューの際に重要です。
参考資料
- fatedier/frp — GitHubリポジトリ、README、リリース
- frp公式ドキュメント（gofrp.org）
- zrok概要 — NetFoundryドキュメント
- zrok — オープンソースライセンスページ、NetFoundryドキュメント
- zrokセルフホスティング展開ガイド（Linux） — NetFoundryドキュメント
- zrokパーミッションモード — openziti/zrok GitHubドキュメント
- OpenZiti — ゼロトラストネットワーキング、アイデンティティによる保護
- inlets PRO — GitHubリポジトリとライセンス条件
- inlets.dev — 製品サイト
- Inlets Uplink料金 — OpenFaaS Gumroadリスト
- Pangolin — GitHubリポジトリ
- Pangolin — Y Combinatorローンチページ
- NIS2指令 — 欧州委員会、欧州のデジタル未来の形成
- ngrok BYOC / プライベートエディション — AWSマーケットプレイス
更新履歴
編集作業 — 2026年8月28日
- 削除：冒頭のメタディスクリプション行（記事本文の一部ではない）
- frp:
fatedier/frpリポジトリからApache 2.0ライセンスを直接確認（正規のアップストリーム）。サポートされているトランスポートプロトコル（quic、kcp、websocket、wss）を追加（元の草稿にはなかった）。α版のVirtualNetTUN機能と、進行中のv2開発についても記載（READMEとリリースノートから）。 - zrok: ライセンスとコンポーネントの正確性を確認し、自己ホスティングの説明を実際の構成に更新。CLI例も修正（トークン形式、
--closed/--access-grantフラグ追加）。また、zrokのデフォルト設定は「オープン」権限モードであり、最初から閉じた設定ではない点を明記。 - Inlets: 最大の修正点。Inlets Proはオープンソースではなく、商用ソフトウェアです。従来のHTTP限定の
inlets OSSは廃止済み。比較表と説明を更新し、新製品のInlets Uplinkの料金も追加。 - 規制枠組みの解説: GDPR、HIPAA、SOC 2、PCI-DSS、NIS2の役割と範囲を明確化。特にNIS2はデータ居住性を規制しないことを記載。
- ngrokの補足: BYOCやプライベートエディションのエンタープライズ層提供を追記し、「SaaSは制御なし」の誤解を修正。
- Section 3.4 (Pangolin)追加: WireGuard + Traefik、組み込みSSO/RBACのセルフホスト型トンネルプラットフォーム。比較に加え、draftで指摘されたID管理のギャップを埋める。
- 比較表と戦略推奨の更新: 上記内容を反映し、ASCII表をMarkdown表に変換。
- 参考資料の追加・修正: すべての修正・追加ポイントに対応したドキュメントリンクを掲載。
Related InstaTunnel pages
Continue from this article into the most relevant product guides and workflows.
Related Topics
Keep building with InstaTunnel
Read the docs for implementation details or compare plans before you ship.