ZVMがLANでは動作するのに、トンネル経由では失敗する理由
コミュニティで報告されたケースでは、ZVM仮想マシンはローカルネットワーク経由では正常に表示されましたが、DDNSまたはCloudflare Tunnel経由では表示されませんでした。このスレッドでは、ZVMコンソールが最初のWebページ以外にも追加の通信を必要とする可能性が指摘されています。その後の返信ではWireGuardやポート5700のTCPパススルーに言及されていますが、すべてのZimaOSバージョンに共通する解決策が確立されたわけではありません。
現在のリモートアクセス構成については、公開トンネルを追加する前に、まず最新のZima Client接続ページとZima Clientリモートアクセスガイドを確認してください。
DDNSとCloudflare Tunnelは異なる層を解決する
DDNSはホスト名をIPアドレスに対応付けるだけです。Cloudflare Tunnelは、cloudflaredを通じて対応するアプリケーションプロトコルをプロキシします。どちらも、VM管理インターフェースで使用されるすべての複数ポート通信やインタラクティブコンソールプロトコルを自動的に認識するわけではありません。
Cloudflareの現在のプロトコルドキュメントでは、公開アプリケーションのTCPサービスはWebSocket経由でストリーミングされ、HTTP以外のアクセスにはクライアント側のcloudflaredが必要と説明されています。詳しくはCloudflare Tunnelのプロトコルドキュメントと、最新のCloudflare Tunnel FAQを参照してください。
ポートを変更する前にZVMの経路を診断する
- LANからZVMが完全に動作することを確認します。
- ブラウザーの開発者ツールを開き、トンネル使用時に失敗しているWebSocketまたは追加リクエストを特定します。
- 正常に動作するLANセッションとリモートセッションで、接続先のホスト名とポートを比較します。
- 現在のZVMビルドがコンソール経路に実際にポート5700を使用していることを確認しない限り、ポート5700だけで十分だと考えないでください。
- ZimaClient、WireGuard、またはその他の対応オーバーレイなどのプライベートネットワーク方式を試し、プロトコル変換なしで完全なプライベートサービスが機能するか確認します。
TCPパススルーが役立つ可能性がある場合
コミュニティの返信では、ポート5700に対するNGINX StreamのTCPパススルーが提案されていました。これは公式のZVMネットワーク仕様ではなく、コミュニティによる回避策として扱ってください。必要なコンソール通信がそのポート上のプレーンTCPであることを確認し、認証境界を安全に維持できる場合にのみ役立ちます。
セキュリティ境界
VMコンソールの公開は、静的なWebページの公開よりも慎重な対応が必要です。管理インターフェースにはプライベートネットワークを優先して使用し、すべての層で認証を必須にするとともに、管理ポートを直接パブリックインターネットに公開しないでください。
現在の公式ZimaOSリモートアクセスドキュメントでは、組み込みのリモートアクセス方法と標準プロトコルを使用したリモートアクセス方法について説明しています。
FAQ
コンソールが表示されないのに、なぜVMは起動するのですか？
管理リクエストとインタラクティブコンソールの通信では、異なるリクエストやチャネルが使用されることがあります。VMプロセスは正常に起動していても、ブラウザーが表示用の経路を確立できない場合があります。
ポート5700をポートフォワーディングすれば、ZVMは必ず直りますか？
いいえ。コミュニティのスレッドにはポート5700の転送に失敗した例も含まれているため、1つの固定ポートを前提にせず、実際の通信を確認してください。
リモートZVMにはDDNSだけで十分ですか？
いいえ。DDNSが提供するのは名前解決だけです。VMコンソールへ安全かつプロトコル互換の経路を確保する必要があります。
