オープンソースなWeb会議システム Jitsi Meet Server インストール

コメントはこちらから お気軽にどうぞ ～ 投稿に関するご意見・感想・他

1. なるよしのり より:

   2020年4月15日 14:48

   役立つ記事をありがとうございます。
   クローム　や　FireFox でアクセスしても　Windows10　のカメラの許可が設定できなくて困っています。
   貴殿の記事「クロームでカメラが使えない」のとおり操作しても許可になりません。
   ご指導いただければありがたいです。

   返信
   • nobby より:

     2020年4月15日 20:16

     もしdebianやubuntuにサーバー版を入れたのでしたらpackageが更新されているかチェックしてみてください。
     sudo apt-get update
     sudo apt-get upgrade

     返信
   • rohhie より:

     2020年4月15日 23:05

     コメントありがとうございます。
     マイクやカメラを要求されないということは、サーバーが正しくマイクとカメラを要求できていない→サーバーが正しく動いていない、という可能性があります。
     たまたま今日、そんな事象を引き起こしまして…

     (1) 「通信帯域を減らす」の項目で書いている箇所が中途半端で、最後の }, が抜けている。
     結果として、サーバーが正しく起動していない場合があります。
     ※直しておきます。
     (2) 認証機構で、サーバーのFQDNを正しく設定できていない。
     guestと書いたり書かなかったり、設定がややこしいのですが、つじつまが合わない状態になるとサーバーが正しく動作しない場合があります。

     見直しのポイントはこれくらいで、後は…

     (3) ApacheやNGIXの前にJitsiをインストールした。
     不思議ですが何度やっても上手く動かなかったです。Jitsiをアンインストールして、インストールし直したらばきれいに動きました。

     頂いたコメントから想像する確認ポイントはこれくらいです。お試し頂き、結果を教えて頂けますと幸いです。

     返信
   • rohhie より:

     2020年4月17日 08:09

     昨日、システムを新たに構築した際に同じ現象が発生しました。
     Prosodyの認証設定に誤りがあったためです。サーバー名っぽいところに guest と書いているところがあるのですが、これがないとVideoBridgeとの連携が上手くいかないためのようです。
     本文中の記事で太字にしておきますので、設定をご確認頂けたらと思います。

     返信
2. nobby より:

   2020年4月15日 17:32

   参考になる記事有難うございました。
   ユーザーが会議室を勝手に作ってしまう仕様を、貴殿の記事を参考にホストのみが作成できるように変更できました。

   返信
   • rohhie より:

     2020年4月15日 23:02

     コメントありがとうございます。
     お役に立てたようで何よりです。

     返信
3. たこすけ より:

   2020年4月17日 09:27

   インストール中のダイアログで、

   The hostname of the current installation:
   → temp.hogeserver.hogeddns.jp

   とありますが、一度インストールしてしまうと、全消ししてもこの部分がもう出てこなくなります。
   最初www.hogehoge.comに設定して、やはり他のホスト名にしたいと思って変更しようとしましたが、ここが変更できないせいか、SSL設定なども全部このホスト名になってしまうようです。
   全部手作業で直したものの、うまく動いてくれません。
   ここを変更（削除？）する方法はないのでしょうか。

   返信
   • rohhie より:

     2020年4月17日 19:50

     アンインストールしてから、もう一度インストールしてください。
     アンインストールの手順も記載しております。

     返信
4. たこすけ より:

   2020年4月18日 10:05

   アンインストールの件、解決しました。
   本サイトに記載のアンインストール方法ではだめでした。
   正確には下記の通りです。

   apt purge jigasi jitsi-meet jitsi-meet-web-config jitsi-meet-prosody jitsi-meet-turnserver jitsi-meet-web jicofo jitsi-videobridge2

   jitsi-videobridgeがjitsi-videobridge2に変わっているようです。

   返信
   • rohhie より:

     2020年4月18日 17:32

     アンインストールでFQDNの問題が解決したということですかね。まずは良かったです。
     videobridgeの件はその通りです、今月立てたサーバーの再構築をした際に気付いてはいました。
     tabキーを押せば補完されるような変更なのでまぁいいかと放っておきましたが、せっかくご指摘をいただきましたので更新しておきます。

     返信
5. イカの刺身 より:

   2020年5月19日 11:22

   初めまして
   テレビ会議について情報を集めている中で、rohhie様の当サイトにたどり着き、
   自前で構築してみようと始めたのですが、サーバ構築後、Windowsからアクセスすると問題なく接続してビデオ会話できるのですが、ipad,iphoneからはミーティングには参加できずに『あなたは切断されました。ネットワーク接続を確認することができます。〇〇秒で再接続します。』との表示がでます。
   jitsi.orgなどで原因を探っているのですが、さっぱりです。
   もしかして、インターネットに出ないとだめなのでしょうか？
   関連するような情報をお持ちでしたら、ご教授ください。

   返信
   • イカの刺身 より:

     2020年5月19日 14:58

     連投で申し訳ありません。
     前出の中で『インターネットに出ないとだめ』としましたが、
     meet.jit.siにしか行かれない？と考えています。

     返信
   • rohhie より:

     2020年5月19日 20:28

     コメントありがとうございます。
     もしかしてサーバーで「自前の証明書」を使っているのではないでしょうか？

     モバイル版のアプリケーションは、いわゆるオレオレ証明書に対応していないという投稿がコミュニティにありました。
     私が試したときにも同じ表示がされました。

     Androidの場合ですが、Chromeでアクセスしてオプションから「PC版サイト」をチェックするとブラウザからアクセスができます。
     iPhoneだと操作が厳しいかもしれませんが、iPadの大きさがあれば回避策になるかもしれません。

     ご参考まで。

     返信
     • イカの刺身 より:

       2020年5月19日 23:03

       貴重な情報ありがとうございます。
       ご指摘の通りopensslにて自前の証明書を作成しております。証明書まで考えが至りませんでした。自前の証明書の用意だけで四苦八苦してここまで到達しましたが、なかなか厳しい予感がほのかにして参りました。引き続き対応していきたいと思っていますのでアドバイス頂ければ幸いです。
       また最終目標はビデオ会話のレコーディングまで行きたいと考えていますので、チョイチョイアドバイス頂けると幸いです。
       ありがとうございました。

       返信
6. にっぱー より:

   2020年5月19日 13:56

   初めまして、にっぱーと申します。
   jitsi-meetを設定する上でこのサイトが非常に役立っております。
   ありがとうございます。

   Ubuntu20.04にjitsi-meetをインストールし、hamachiを使ってVPNで接続されたパソコンでビデオチャットできるか試しています。
   しかし、以下のようなエラーが出てしまいます。

   Waring! Could not resolve your external ip address! Error:^
   Your turn server will not work till you edit your /etc/turnserver.conf config file.

   You need tu set your external ip address in extarnal-ip and restart coturn service.

   hamachiのipアドレスが外部IPアドレスとして認識されてないことが原因であると思うのですが、解決策がわかりません。
   お知恵を貸していただけると幸いです。

   返信
   • rohhie より:

     2020年5月19日 21:14

     コメントありがとうございます。hamachiを使ったことがなくよく分からないところがあるので、全て想像・仮定で書きます。

     (仮定)
     会社でJitsi Meetサーバーを立てて、社内ではビデオ会議ができることを確認した。
     在宅ワークをしている方とhamachiを使ってVPNでつないだので、その人にも会議に参加して欲しいが、External IP addressを解決できないと怒られた。
     (仮定があっているとしたら)
     Jitsi MeetサーバーもhamachiのVPNに参加する必要があるのかなと思いました。
     hamachiというのは「ソフトをインストールして、サーバーにログインして、登録済みのVPNに参加する」仕掛けになっているようなので、VPNに参加している人達だけが通信できるようになるのではないでしょうか。

     あくまでも勘で書いちゃってますので、違っていたらすみません。
     うまく会議ができると良いですね。

     返信
7. にっぱー より:

   2020年5月19日 21:13

   連投失礼します。
   hamachiのIPアドレスをDNSと関連付けして再度jitsi-meetをインストールし、hostnameにDNSを設定すればエラーは消えました。
   よって上記の質問は答えていただかなくても大丈夫です。

   hamachiを使用してもDNSとの関連付けは必要そうですね。
   VPN接続してDNS使わずにできないか模索しています。

   返信
   • rohhie より:

     2020年5月19日 21:26

     入れ違いにコメントをいただいてました。
     DNSと関連付ける、hostnameにDNSを設定する、ということそのものが未経験で…駄目ですね、答えが出せませんでした。

     イントラネットやVPN接続している方だけに見せたいIPアドレスというのはあります。
     私は自宅でDNSサーバーを稼働させて、インターネットからはグローバルIPアドレスが戻り、イントラネットからはローカルIPアドレスが戻るようにしています。

     上手く設定ができたらぜひ教えてください。

     返信
8. にっぱー より:

   2020年5月19日 21:58

   ご丁寧な返信ありがとうございます。

   私の目的としてはhamachiのVPNでVPNネットワークに参加した人だけが繋げることのできるjitsi-meetのサーバを作ることです。

   hamachiはjitsi-meetのサーバ(Ubuntu20.04)にも入っており、専用のVPNのIPアドレスが割り振られているのですが、そのIPをJitsi-meetインストール時のhotsnameに入れてサーバを起動しても、ほかのパソコンからアクセスができない状態です。

   ネットワークの設定はなかなか難しいですね。
   進展すればまたこちらに書き込ませていただきます。

   返信
   • rohhie より:

     2020年5月19日 23:16

     Jitsi Meetをインストールしたサーバーにhamachiが入っていて、インストール時のホスト名にIPアドレスを指定したなら、Jitsi Meetはきっと正しくインストールされていると思います。アクセスできない原因はルーティングなのかもしれないですね。
     基本的なところになってしまいますが、
     $ ip addr
     $ ip route
     で念のため設定を見つつ、
     /var/log/apache/access.log や error.log、あるいは、
     /var/log/nginx/access.log や error.log で実際に利用者PCからのアクセスが届いているのか、その結果どうなったのかを見てみるところからでしょうか。
     パケットが到着しているけれど、返事を投げていないのか、投げているけれども届かないのか、投げているつもりが違う経路に投げちゃっているのか、というところを見極めていく感じでしょうか。
     さらっと探してみたら、こんな記事もありました。
     https://community.logmein.com/t5/LogMeIn-Hamachi-Discussions/Route-all-the-traffic-through-Hamachi/td-p/120734

     返信
9. イカの刺身 より:

   2020年5月19日 23:10

   貴重な情報ありがとうございます。
   ご指摘の通りopensslにて自前の証明書を作成しております。証明書まで考えが至りませんでした。自前の証明書の用意だけで四苦八苦してここまで到達しましたが、なかなか厳しい予感がほのかにして参りました。引き続き対応していきたいと思っていますのでアドバイス頂ければ幸いです。
   また最終目標はビデオ会話のレコーディングまで行きたいと考えていますので、チョイチョイアドバイス頂けると幸いです。
   ありがとうございました。

   返信
   • rohhie より:

     2020年5月19日 23:32

     返信してみて良かったです。オレオレCA証明書を端末にインストールしても効果がないので探してみたら、対応していないけどLet's Encryptがあるじゃん、という「確かに」的な回答だった記憶です。オープンソースですから自分で変更を入れてコンパイルすればいいのかもしれませんが、ハードルがかなり上がってしまいますよね。

     Let's Encryptは無料で良いのですが、取れない環境(イントラネットでIPアドレス運用しているとか、dynamic dnsを利用していて思い通りに取れないとか)もあったりすると思いますので、どちらを選択するのかは難しいところです。

     レコーディングはJigasiでしょうか？試してみようと思いながらも、なかなか時間が取れずにいました。録画はローカルマシンでWindowsの標準機能を使って…という経験だけですが、とりあえずは上手くいきました。お手軽ではあります。

     それにしても、自前の証明書が用意できただけでも凄いことだと思うのですよね、経験からするとあれはなかなか大変ですから。

     無事ゴールにたどり着けると良いですね。

     返信
     • イカの刺身 より:

       2020年5月20日 12:20

       返信ありがとうございます。
       今回の件では証明書でハマるとは思っていませんでした。引き続きトライしていきます。
       録画についてはjibriを入れてみようと考えていて、理由はyoutubeで検索した際に最初にお手本動画に当たったためです。jitsiの構成を十分把握していないのですがjigasi でも行けるのなら試してみたいですね。引き続き何かありましたら、ぜひご教授お願います。

       返信
       • rohhie より:

         2020年5月20日 22:47

         失礼しました、JibriがYouTubeとの連携モジュールですね。
         JigasiはSIPサービスなので全然違ってました。

         コメントをいただいたことで、この記事を元に環境構築すると、自前の証明書ってことになるのかと、改めて気付かされました。
         今のところ記事の修正は考えていませんが、今後投稿する記事では意識していきたいと思います。

         Let's Encryptで証明書を取得できる環境なら差し替えは可能です。
         Apacheかnginxで参照する証明書を変えるだけで動くはずです。

         今後も何かありましたら気軽にコメントしてください。

         返信
10. イカの刺身 より:

    2020年5月21日 00:07

    いろいろご教授頂き申し訳ありません。
    そもそも私が目指すゴール地点、前提をお伝えしていなかったため貴重なお時間を頂く結果となり申し訳ありませんでした。ゴール地点、前提は全てのサーバ、クライアントがインターネットには出れない環境下においてビデオ通話と録画を実現したい。但し構築時はインターネット接続は可とする。非常に手前勝手なゴールになっております。
    自分でやっていて、なんだかな？と思うところもありますが、これに懲りずにお付き合い頂ければ幸いです。

    返信
    • rohhie より:

      2020年5月21日 06:23

      時間については大丈夫です。できる範囲でしかやりませんので。

      ゴール地点をそこに置いているのだとすると、Jibriの利用は難しいように思いました。私の理解では、Jibriの録画先はYouTubeなので。

      ローカルネットワークでの運用で録画が必須ならば、私の知る範囲ではOpenmeetingsなのかもしれないと思いました。
      セットアップはJitsi Meetより少しハードルが高く、ユーザー管理も必要になってきますが(自動登録機能はありますが)、良いシステムだと思います。ホワイトボード機能もあるので、喜ばれるかもしれません。
      少なくともVersion4時代には録画機能があり、かなり使い込んでいましたが、便利でした。多分5.0.0.M4にも録画機能はあると思います。

      そういう需要もあるかと思いまして、記事を投稿したりもしています。
      https://rohhie.net/ubuntu18-04-clean-install-of-openmeetings5-0-0-m4/

      既に証明書が準備できているのであれば、やれることの範囲は広がっています。

      返信
11. イカの刺身 より:

    2020年5月22日 07:52

    仕事の都合で返信できず申し訳ありませんでした。
    確かにJibriはYouTubeを録画先にしているようなのですが、せっかくなので少し弄ってから決めようと思います。Openmeetingsなるものがあるのですね。自分のゴール地点に近いです！jibrをやりつつOpenmeetingsもやってみようと思います。貴重な情報ありがとうございます。

    Jitsiの方で一つ作業工程を飛ばしていたことがありました。Jitiを始めたころは様子見でLet's Encryptを選択していたのです。Let's Encryptは最後に証明書のインストールが必要だったのですね。インストールしなくてもしっかり動いていたので気が付きませんでした。もう一度Let's Encryptでやってみます。

    結果はまた報告させていただきます。ではでは。

    返信
    • rohhie より:

      2020年5月22日 22:20

      証明書は誰でも作ることができますが、誰がお墨付きを与えてくれるのか、というのがポイントです。

      Let's Encryptは一般的なシステムで「安全」とされた認証機関で、それが署名してくれているので普通にアクセスできるのですが、署名されていない場合や自己署名(オレオレ認証局で署名したオレオレ証明書)だとユーザーに警告が表示されます。

      ActiveDirectoryでドメイン管理された環境なら、利用者のPCに「安全な認証局」として管理者が用意したオレオレ認証局を登録できますので、その認証局に署名された証明書を使ったサイトは、ユーザーにとってみると安全に見えます。

      証明書の部分は「危険を承知でアクセスする(実際我々が用意するサーバーなので安全ですけど)」という形で回避することができますので、ユーザーの理解が得られれば運営できるような気がします。私の職場はそうはいかなかったので、安全に見えるように細工をしました。

      ・LAN内に立てたサーバーはドメイン管理者の用意した認証局に署名してもらった証明書を利用。
      ・インターネットに立てたサーバーはLet's Encryptで取得した証明書を利用。(ワイルドカードの証明書)

      どちらもインストーラーで自動取得できないタイプなので、インストール時には証明書を自分で用意する選択して、手動で設定しています。

      返信
12. にっぱー より:

    2020年5月25日 16:30

    こちらのHPを参考にさせていただき、質問をした後に試行錯誤した結果、クライアントがJitsiサーバを読み込もうとするところまで来ました。

    しかし、現況は以下のようなエラーがnginxのエラーログに出力されている状態です。

    2020/05/25 16:08:50 [crit] 10333#10333: *44 SSL_read() failed (SSL: error:14191044:SSL routines:tls1_enc:internal error) while processing HTTP/2 connection, client: 127.0.0.1, server: 0.0.0.0:4444

    SSL認証がクライアント側で読み込めていないと認識しているのですが、どこを直せばいいかがわかりません。
    お忙しい中恐縮ですが、お知恵を借りられれば幸いです

    構成は以下のとおりです

    OS:Ubuntu20.04
    webサーバ:nginx/1.17.10

    SSLの設定については以下のサイトを参考にし、Common Nameを書き込むところをVPNのIPアドレスにしました。

    https://www.server-world.info/query?os=Ubuntu_20.04&p=ssl&f=1

    返信
13. にっぱー より:

    2020年5月25日 16:32

    上記の続きですが、クライアント側からクロームやFirefoxでVPNのIPアドレスに接続すると警告が出て、そちらを無視して進むと読み込みこもうとするのですが、画面が切り替わらないといった状態です。

    返信
    • rohhie より:

      2020年5月25日 23:23

      これは恐らくですが、nginxが証明書を正しく読み込めないために、クライアント(ChromeやFirefox)との通信を暗号化できない、というエラーが出ているように思われました。

      書いて頂いた内容からすると、まだ、署名要求(リクエスト)までしかできていないように思われます。

      最後の署名をすればnginxは暗号化をはじめると思います。

      ---

      実はちょうど今、証明書に関する記事をまとめ直しているところなのですが、恐らく証明書っていうのは、こういうことなんだろうと思うんです。

      秘密鍵がある(これが人だったり目的だったりを表す)。
      ↓
      秘密鍵からリクエストを作る(僕は○○がしたいんだ)。★今はここですね。
      ↓
      リクエストに署名すると証明書になる。

      署名をする人が権威のある人だと、世の中的に安心アクセスするための証明書になるし、ActiveDirectoryの管理者なら管理するAD範囲の人が安心してアクセスできる証明書になる。
      自分で署名すると、自己署名証明書、ということになります。どのシステムからも全く信用されないけれども、ユーザーが「アクセスする」と決めればアクセスできるサイトで使われる証明書です。

      私が過去に書いた記事では、自分で署名するんだけれども、署名するのはオレオレ認証局ですよ、と宣言しています。ユーザーにオレオレ認証局の証明書を信用してもらえれば(ルート認証局として登録してもらえれば)、オレオレ認証局が署名した証明書ならば安心、とシステムが理解するようになります。
      https://rohhie.net/certification-authority-to-make-at-company/

      前置きが長くなりましたが…今回にっぱーさんに示して頂いたサイト(私もよく教えてもらっているサイトです)では、オレオレ認証局を作っていませんので、ユーザーに「それでも僕はアクセスする」という操作をしてもらう必要がありますが、暗号化ができるようになりますので、ビデオ会議はできるようになります。

      緑色の箇所が管理者が入力する箇所で、解説すると

      (1) /etc/ssl/privateに移動(ここで作業をします)
      (2) openssl genrsa で秘密鍵を作ります。
      (3) openssl rsa で秘密鍵からパスフレーズを削除 ★ここで秘密鍵完成
      (4) openssl req で僕は何かがしたいというリクエストを作ります。ここでやりたいことは宣言していないように見えます。
      (5) openssl x509 でリクエストに署名して証明書にします。★ここができていないと思います。

      という具合だと思います。

      ここまでできたら、nginxでは証明書として server.crt(csrではありません) を、秘密鍵として server.key を読み込むようにすれば、暗号化通信ができるはずです。

      認証局を作った方がよりユーザーに安心感が出てくると思うのですが、まずは通信できるようにすることが先ですよね。

      長くなってしまいました。結果が出ることをお祈りしております。もう一息です。

      返信
      • にっぱー より:

        2020年5月26日 18:48

        詳しい説明ありがとうございます。

        ＞ここまでできたら、nginxでは証明書として server.crt(csrではありません) を、
        秘密鍵として server.key を読み込むようにすれば、暗号化通信ができるはずです。

        nginxに証明書を読み込むようにするというのは/etc/nginx/nginx.confにcrtとkeyの
        パスを書き込むという認識でよろしいでしょうか？

        nginx.confのhttpの枠内に以下のような設定を追加しました。

        http {
        ...（略）

        server {
        listen 443 ssl;
        server_name ;
        ssl_certificate /etc/ssl/private/server.crt;
        ssl_certificate_key /etc/ssl/private/server.key;
        }
        }

        しかし、現在上記の設定を行ってnginxを再起動し、ステータスを確認すると以下のエラーが発生します。

        nginx: [emerg] bind() to 0.0.0.0:443 failed (98: Address already in use)

        443ポートが既に使われているというエラーだと認識していますが、lsofコマンドを使っても443を
        使用しているプロセスはありませんでした。そして、nginx.confの設定を元に戻すと正常に動作しました。

        そもそもnginx.confを編集することが間違っているのか、それとも別の要因があるのかが分かりません。
        お手数ですがお知恵を貸していただければ幸いです。

        返信
        • にっぱー より:

          2020年5月26日 18:49

          なお。(1)～(5)の手順は全てやっており、正常な結果が得られていることは確認済みです。

          返信
        • rohhie より:

          2020年5月26日 19:23

          それは、追加する場所が違っていると思います。前回回答の私の想定が間違っていました。

          nginx.confはNginXの基本動作が書かれていますが、恐らく、最後の方に

          include /etc/nginx/conf.d/*.conf;
          include /etc/nginx/sites-enabled/*;
          }

          という行があると思います。Jitsi Meetの証明書関連の設定は、
          /etc/nginx/sites-enabled/hogehoge.conf
          から読み込まれます。(hogehogeはにっぱーさんのサイトに読み替えてください)

          ここに、server の設定があって、Jitsi Meetの設定が書いてありますので、
          ssl_certificate /etc/ssl/private/server.crt;
          ssl_certificate_key /etc/ssl/private/server.key;
          に修正します。

          既に使われているというエラーが出るのは、nginx.confに新しいサイトを追加し、そこで443を先に使ってしまった後に、include文でJitsi Meetの設定が読み込まれ、さあ443を使おうと思ったら既に使っていた…という状況だからだと思います。

          どうしても上手くいかない場合は、nginxとJitsi Meet関連のファイルをアンインストール(purge)して、nginx→Jitsi Meetの順でインストールし直します。
          途中で証明書について聞かれるので、
          /etc/ssl/private/server.key
          /etc/ssl/private/server.crt
          と回答すれば正しく設定し直してくれるので、動作すると思います。

          ※NginXについてあまり知らないので、今、Ubuntu20.04環境にインストールしてみましたが、Jitsi Meetのダウンロードに結構時間が掛かります。
          世界的にユーザーが増えているのでしょうね。ですので、最初は設定修正を試し、駄目なら再インストールって感じかなと思いました。

          ※ただ、設定修正を頑張りすぎる必要はありません。インストールしなおせば必要な設定をしてくれますので。

          あと一歩ですね。

          返信
          • にっぱー より:

            2020年5月27日 11:20

            お忙しい中、迅速な返信ありがとうございます。
            もう少しだろうという手応えはあるのですがなかなか前に進めません。

            とりあえずすべてアンインストールして以下の手順で設定し直してみました。

            ①apt updete および upgrade

            ②SSL承認の手順(1)～(5) （前回貼ったURLの手順）

            ③こちらのサイトにあるJitsi-meetのインストール手順 ufw enableからrebootまで
            ・インストール中の問い合わせではVPNのIPアドレスを指定し、crtとkeyは
            /etc/ssl/private配下のserver.crtとserver.keyを指定

            reboot後、友人の家にあるパソコンからIPアドレスを入力してもらって接続しても読み込みはするのですが
            画面が切り替わりませんでした。
            エラーログを確認すると以下のようなエラーが出ています。

            2020/05/27 06:45:05 [crit] 756#756: *24 SSL_read() failed (SSL: error:14191044:SSL routines:tls1_enc:internal error) while processing HTTP/2 connection, client: 127.0.0.1, server: 0.0.0.0:4444

            ＞Jitsi Meetの証明書関連の設定は、/etc/nginx/sites-enabled/hogehoge.conf
            から読み込まれます。

            ということをアドバイスいただきましたので、confを確認したのですが、
            ssl_certificateおよびkeyは既にprivate配下のcrtとkeyが指定されていました。
            内容は以下のとおりです。

            server {
            listen 80;
            listen [::]:80;
            server_name ＜VPNのIPアドレス＞;
            （略）
            }
            server {
            listen 4444 ssl http2;
            listen [::]:4444 ssl http2;
            server_nameserver_name ＜VPNのIPアドレス＞;

            （略）

            ssl_certificate /etc/ssl/private/server.crt;
            ssl_certificate_key /etc/ssl/private/server.key;

            これで行けるかと思ったのですが、現状はやはりエラーログの通りSSLが読み込めていない状況です。
            お忙しい中、大変恐縮ですが、お知恵を貸していただければ幸いです。

            あと、関係ないかもしれませんが listen 443を指定してある内容が
            /etc/nginx/modules-enabled/60-jitsi-meet.confにありました
            内容は以下の通りです。

            stream {
            upstream web {
            server 127.0.0.1:4444;
            }
            upstream turn {
            server 127.0.0.1:4445;
            }

            （略）

            server {
            listen 443;
            listen [::]:443;

            こちらのserverにもcrtとkeyのパスを書き込んだほうがいいでしょうか？
            以上、長文で失礼いたしました。

            返信
14. にっぱー より:

    2020年5月27日 14:53

    追記ですが
    できたserver.crtはクライアント側に証明書としてインポートして実行しました。

    返信
15. rohhie より:

    2020年5月27日 22:10

    色々と試して頂いて恐縮です。
    示して頂いた情報からすると、証明書に問題があるという印象です。
    ※ご友人の家からのアクセスはまた別の要素が入り込み得るので、まずは置いておきます。
    　色々な技術が絡んでいるので、1つ1つ解決したいと思います。

    サーバーをIPアドレス指定でインストールし直したのですが、どうにも問題が再現できない…

    ServerWorld様の1～5の手順を実施し、その上で、Jitsi Meetを再インストールして/etc/ssl/private/～.crt と key を設定したのであれば、Jitsi Meetの設定を修正する必要は恐らくないと思います。それを設定するためのインストール中の問いかけなんですね。

    ※アンインストールについてやってみて1つ不足していることが分かりました。apt purege nginx を実行しておく必要がありました。Jitsi-meetのインストールで問いかけがあったということは、恐らくこれは実行して頂いているものと想定しています。

    VPNのIPアドレスと書かれている部分が何を示しているのかちょっと分からないところがあったのですが、少なくともUbuntu20.04をインストールしたサーバーのIPアドレスを指定する形でインストールし直したところ、問題なく起動しています。

    可能なら、Contactのページから key, csr, crt の中身(テキストになっていると思います)を送って頂ければ、証明書が作られた過程をある程度確認させて頂くことはできます。
    その他できることといえば、時間を合わせてWeb会議しながら問題を1つ1つ解消していくことくらいでしょうか。
    ※key, csr, crt はここに書くとインターネットに公開されてしまいますので、送る場合は必ず Contact から送ってください。
    念のため、
    https://rohhie.net/contact/
    です。

    server.crtは正しく作成したのであれば、クライアント側にインストールしても効果はありません。
    クライアント側にインストールして効果が出るのは 1)CAの証明書(ルート認証局とかいわれてますね) 2)クライアント証明書(アクセスしてくる人を制限したいときに使います) のいずれかです。
    これらは秘密鍵から作ること自体は変わらないのですが、作るためのパラメーターが違ってきます。

    返信
    • にっぱー より:

      2020年5月27日 22:54

      早速の回答、ありがとうございます。

      ＞VPNのIPアドレスと書かれている部分が何を示しているのかちょっと分からないところがあったのですが、少なくともUbuntu20.04をインストールしたサーバーのIPアドレスを指定する形でインストールし直したところ、問題なく起動しています。

      VPNのIPアドレスとは、hamachiをUbuntuにインストールし、ネットワークに接続することで払い出されるIPアドレスを指しています。
      Jitsi-meetをVPNで接続することが目的なのでこちらのIPアドレスを設定していますが、それが間違いだったのかもしれません。検証してみます。

      Contactのページから key, csr, crt の中身を送信しましたのでご確認いただけると幸いです。

      返信
16. にっぱー より:

    2020年5月28日 00:12

    Jisti-meetおよびnginxをインストールし直し、IPアドレスはローカルIPの192.168・・・を設定
    /etc/turnserver.confのexternal-ip=にhamachiのVPNアドレスを設定してreboot後接続を試しました。

    ローカルIP内であれば external-ipをアドレス欄に入力すれば接続できるのですが、やはり外部からexternal-ipをアドレス欄に入力しても
    SSL_read() failedと、前回と同様のエラーが出る状況です。

    返信
17. rohhie より:

    2020年5月28日 08:12

    コメントありがとうございます。

    にっぱーさんに送っていただいた秘密鍵とサーバー証明書を実際にNGINXに設定して起動してみました。
    ・秘密鍵と証明書はできあがっていて、暗号化に使える状態になっていました。
    ・上手く接続できる環境で証明書だけを差し替えてテストし、アクセスできることが確認できました。
    ・UbuntuにIPアドレスを追加(証明書に含まれていたサーバーのIPアドレス、hamachiのIPアドレスですね)し、Jitsi Meetをインストールし直し、クライアントPCにIPアドレス(証明書のIPアドレスにアクセスできるもの)を登録、証明書に含まれていたサーバーのIPアドレスでアクセスできることが確認できました。

    以上のことから、JItsi Meetのインストールには成功しており、証明書にも問題はなく、NGINXも問題なく動作していることが分かります。hamachiがVPN接続で、VPN接続したPC同士が無制限に接続できるものならば、問題なく動作するはずですが、そうなっていない…と。

    今、この状態にいたって、最初にコメントをいただいたときからここまでは上手くいっていたものと思いました。
    (ここまで理解したところで過去をたどると、情報がつながりました)

    ろっひーはようやくここでスタートラインに立ったようです。

    インストールし直した際の/etc/turnserver.confは以下です。これは変えないように書かれていますね。
    (Apacheで構築した環境にはないファイルなのでなんだろ？と思っていましたが、これもここで分かりました)
    ---------------------------
    # jitsi-meet coturn config. Do not modify this line
    use-auth-secret
    keep-address-family
    static-auth-secret=*ここはインストールするたびに変わります*
    realm=2**.***.***.*** *ここは送っていただいた証明書に含まれたhamachiのIP*
    cert=/etc/ssl/private/server.crt
    pkey=/etc/ssl/private/server.key

    no-tcp
    listening-port=4446
    tls-listening-port=4445
    external-ip=127.0.0.1

    syslog
    ------------------

    再度整理すると…
    [Jitsi Meet] <-> [NGINX] <-> クライアントPC は接続OK。
    [Jitsi Meet] <-> [NGINX] <-> [hamachi] <-localnet-> [hamachi] <-> クライアントPC は接続OK。
    [Jitsi Meet] <-> [NGINX] <-> [hamachi] <-internet-> [hamachi] <-> クライアントPC が接続NG。
    ということなのかと思います。

    接続NGの場合は、NGINXがSSLでエラーを出力しているということな訳ですが、エラー番号でGoogle検索をしても何が起きているのかということを突き止めることができていません。

    NGINXはエラーが発生するその手前、エラー直後にもいくつかログを出していると思われます(日頃使っていないので断言はできませんが、要求と何をしようとしていたか、エラー、その後どうしたか…を普通なら出力するだろうと思います)。error.logではなくaccess.logに出ているかもしれません。

    その前後の情報も併せて調査するか、あるいは…
    ～[hamachi] <-localnet-> [hamahci]～であれば上手くいき、
    ～[hamachi] <-internet-> [hamachi]～ではエラーが出るのだとすると、出力されるログの違いを手がかりに問題を解消していくようになると思います。

    このあたりの情報がもらえると(プライバシー情報を含むならContactからでお願いします)、もう少し調査ができるかもしれません。

    NGINXの情報交換を色々と眺めていると、SSL通信をProxyするあたりで条件を緩和して上手くいったというような記述もあったように思います。どこかにもう少し追加の設定が必要になりそうです。

    返信
    • にっぱー より:

      2020年5月28日 08:34

      こんな朝早くから回答。ありがとうございます。

      ＞再度整理すると…
      ＞[Jitsi Meet] [NGINX] クライアントPC は接続OK。
      ＞[Jitsi Meet] [NGINX] [hamachi] [hamachi] クライアントPC は接続OK。
      ＞[Jitsi Meet] [NGINX] [hamachi] [hamachi] クライアントPC が接続NG。
      ＞ということなのかと思います。

      まさに仰るとおりで、ローカル同士なら接続できるのですが、インターネット間での接続ができない状態です。

      >このあたりの情報がもらえると(プライバシー情報を含むならContactからでお願いします)、もう少し調査ができるかもしれません。
      こちらはnginxのaccess.logとerror.logをContactでお送りすればよいでしょうか？
      送ってはいけないプライバシー情報は使用していないと思うので大丈夫だと思います。

      返信
      • にっぱー より:

        2020年5月28日 08:44

        1点質問なのですが、rohhie様は

        [Jitsi Meet] [NGINX] [hamachi] [hamachi] クライアントPC

        こちらの接続もできているという認識でよろしいでしょうか？
        それともこちらはまだ試されていないでしょうか？

        返信
        • にっぱー より:

          2020年5月28日 08:49

          書き間違えました

          [Jitsi Meet] [NGINX] [hamachi] [hamachi] クライアントPC

          こちらのインターネット間の接続ができていたかどうかをお聞きしたいです。

          返信
          • rohhie より:

            2020年5月28日 20:25

            ログに関してはContactから送ってください。
            hamachiを使ったインターネット間接続は試していません。

            hamachiはインストールしていません。インストールすればどういうものなのかもっと理解が進むと思うのですが、自分的には深みにはまりそう(色々と調べたくなる)で怖くてできないでいます。そこで、1つのNICにVPNのIPアドレスを追加で持たせてサーバーを構築して擬似状態を作り出し、クライアントはVPNっぽいIPアドレスだけを持たせてテストしてみました。

            もらったログから何も分からず…という状態になったら、インストールしてみようかと思っていたところです。同じことをすれば、同じ結果になるはずですから。

            返信
18. にっぱー より:

    2020年5月28日 21:56

    ありがとうございます。
    Contactにログを送信しましたので、ご確認いただけると幸いです。

    返信
    • rohhie より:

      2020年5月29日 07:45

      ログを確認しましたが、接続要求があってすぐにエラーが出るのではなく、数秒経ってからエラーが発生したり、アクセス要求の前にエラーが発生したりしていました。後者は置いておいて前者を考えると、インターネットを介した接続でもポータルは表示され、そこから会議室に入るときに問題が発生？とか想像しています。

      とりあえず、Ubuntuにhamachiをインストールして匿名でログインしてみたところ、ham0というインターフェースが追加され、IPアドレスが払い出されました。
      3: ham0: mtu 1404 qdisc fq_codel state UNKNOWN group default qlen 1000
      link/ether 7a:79:00:00:00:00 brd ff:ff:ff:ff:ff:ff
      inet 2n.nnn.nnn.nnn/8 brd 25.255.255.255 scope global ham0
      valid_lft forever preferred_lft forever
      ※ログオフしても払い出されたIPアドレスは残ってました。

      これを使って問題再現するか試してみようと思います。

      返信
      • にっぱー より:

        2020年5月29日 09:51

        お忙しい中ご尽力いただき、ありがとうございます。
        こちらでも試行錯誤してみます

        返信
        • rohhie より:

          2020年5月30日 12:47

          試しました。

          [Ubuntu20.04 Jitsi Meet x NGINX] <-hamachi-> [家Router] <-internet-> [スマホテザリング] <-hamachi-> [Ubuntu20.04 Chrome]

          仮想PCで実行するより他ないため、ローカルPC同士ではあるものの、
          ・スマホテザリングの方はLANを無効化し、スマホテザリングのみでネット接続
          ・念のためFirewallでお互いのパケットをDeny指定
          という形で切り分けてやってみましたが、接続できています。ビデオ通話までは試せていないのですが、Videobridgeとつながったであろう動作をしています。

          Jitsi MeetとNGINXはアンインストールし、最初にNGINXをインストールし、その後にJitsi Meetをインストール。
          インストール時の問い合わせには、ホスト名として hamachi のIPアドレスを入力し、鍵と証明書はニッパーさんのものを指定しました。

          ネットワークID(？っていうのでしょうか)とパスワードををメールでお送りしますので、気が向いたら接続を試してみてください。
          しばらく立ち上げっぱなしにしておきます。

          ただし…以下は失敗しています。
          [Ubuntu20.04 Jitsi Meet x NGINX] <-LAN-> [Windows Chrome]
          ページは表示されますが、会議室に入ったあとVideobridgeとの接続が確立できませんでした。
          ただこれは、今、にっぱーさんが直面している問題とは別の問題ととらえて、一旦切り離します。

          返信
19. にっぱー より:

    2020年5月30日 14:59

    おぉ！いけましたか！
    それは希望が持ててきました。

    しかし、とするなら何が原因なのか・・・

    とにかくあたってみます！
    検証ありがとうございます。

    返信
    • rohhie より:

      2020年5月31日 12:02

      昨日はどうもありがとうございました。
      テスト環境とは言え、お互いのサーバーに入るというのはエキサイティングな体験でした。
      そして、実はITにかなり詳しい方だということが分かり、良い経験をさせていただきました。

      Web会議システムは安定性が一つの判断ポイントになるので、どうにか安定通信を確保したいところです。
      にっぱーさんの環境では解決しなければならない課題がありそうに見えました(まだ見極められていませんが)。
      症状からすると、MTUに関連する何らかの問題のようにも見え、Ubuntuにはそれに関わる問題があるようです。
      https://qastack.jp/server/488893/how-do-i-prevent-tcp-connection-freezes-over-an-openvpn-network

      ここの「回答」のところに
      $ sudo ip link set dev tun0 mtu 1350
      というのがあります。今回でいうと、サーバー側のham0をこのくらいまで落としてみると状況が改善するかもしれません。
      (hamachiにおける正しい設定方法はこれから調べる感じですが…)

      ご検討ください。

      返信
      • にっぱー より:

        2020年5月31日 19:23

        返信はメールのほうで送らせていただきました。
        本当にありがとうございました。

        返信
20. rohhie より:

    2020年6月1日 23:37

    その後、Contactからいただいたことも含めて、にっぱーさんからいただいたお問い合わせを整理します。

    まず、結論。
    hamachiで作るVPN環境でJitsi Meetを使ったWeb会議環境の構築は可能。
    Jitsi Meetのインストール時にhamachiのIPアドレスを指定すればシステムは問題なく動作し、自作の秘密鍵・サーバー証明書で問題なくアクセスができる。

    正確なところは分からないものの、
    ・/etc/turnserver.conf の設定値はファイルに書かれているとおり変更不要で、external-ip=127.0.0.1のままで良い。当初は一部だけ何かをカスタマイズしてインストールしていて、経路上の何らかの問題を引き起こしていた。
    ・nginxで証明書が読み込めないエラーは発生しない。ご提示いただいた証明書と、エラー発生時の証明書は違っている可能性が高い。
    ・接続ができない問題はMTU値を上手く処理できないUbuntuのバグにはまっている、経路の途中に何かある。
    というところだったのかと想像します。

    全部自分でやってみた構築結果に基づく想像ですが…。
    最後のMTU値については解決をプラットフォーム変更(Hyper-V→VMware)で実現したものと思われます。
    SSHでログインした後にファイルを開くとフリーズしたり、Jitsi Meetインストール中の問い合わせ画面で必ずフリーズしたりする問題は、Hyper-VだけでなくPCに直接インストールしたというUbuntuでも発生していましたから、経路の途中にIPv6があってみたり、何らかMTU値の低い装置があったりすることで、Ubuntuの潜在バグを顕在化させたのかなという印象です。

    スピード感と問題原因の究明は相反するものに感じます。とりあえずシステムが構築できてしまって、運用できちゃっているものとしてのおごりかもしれませんが書くと、問題原因をはっきりさせて対策しないと、利用者の不便を作り出してしまったり、問題の原因を利用者に求めてしまったりして、長い目で見てみんなをハッピーにできないようなことになりかねません。自戒を込めて書きますが、そのシステムを使う・使わないは利用者が決めるもので、気持ちよく利用するためには少なくともシステムを安定的に稼働させておく必要があります。そのために1つ1つの問題を丁寧に解決している感じです。
    その上で…ビデオ会議システムのエクスペリエンスは、利用者の回線品質によって大きく左右されます。一人が駄目だと、他の全員に影響が出るのもその特徴で、実は例えばTeamsでも一人の回線品質によって会議の質は大きく下がったりします。地味ですが、丹念に調べて整理しています。

    実際には、利用者が本当に駄目な使い方をしていることもあります。でも、問題を解決する方法を教えてあげるだけでとても感謝されたりもします。聞いてくれるということは使おうとしてくれているってことですから、頑張りどころだったりもするんですよね。これも自戒ですが。

    ところで…このシステムはメモリは最大でも3GB程度しか消費しません(デフォルト設定では)。とにかくCPUを消費しますが、hamachi無料範囲の5人であればCPU1つでも余裕があると思います。

    そろそろ本格稼働するでしょうから、経験を踏まえて思ったことを書いてみました。
    また、お気軽にコメントいただけましたら幸いです。

    返信