Google Meet というビデオ会議システムの検証をしてみました。(ブラウザは最新のChromeを使ってます。)

しかし、接続後1分くらいで「ネットワークエラーのため、ビデオハングアウトを開始できませんでした。」というエラーが表示され切断されてしまいます。

まず、ネットワーク構成についてです。今回ハマったのは以下の構成のせいでした。

・FW:内→外はプロキシ経由以外は禁止。(端末直ではネットに出れない。FWはFortiGate使用)
・プロキシ:認証付きプロキシ。かつ、ホワイトリストにして許可URL以外通信禁止。(iFilterを使用)

G Suiteヘルプ：2. Meet 用にネットワークを最適化するをみると、プロキシは推奨されていないなのですが、セキュリティポリシー上仕方ありません。

G Suiteヘルプ：1. ネットワーク接続の要件では、以下のURLのホワイトリストが掲載されているので、これをiFilterの許可するURLリストに追加しました。

https://*.google.com/*
https://*.googleapis.com/*
https://*.gstatic.com/*
https://*.googleusercontent.com/*

これで試しましたが、やはり切断されます。少し詳しく調査が必要なようです。

GoogleMeetが使っているプロトコル - WebRTC

GoogleMeetはWebRTCというプロトコルを使っているようです。まずはこれについて少し調査。。。

WebRTCはリアルタイムコミュニケーションをプラグインレスで可能にするプロトコルです。
P2Pでの通信が可能であり、原則UDPを使います。P2Pのため、NAT超えの仕組みもあります。

WebRTCでは、まずSTUNサーバーによって自身の通信環境を確認し(NATのグローバルIPやマッピングされたポート等)相手に知らせます。(相手に知らせるときはシグナリングサーバーを使います。) これでP2P相手とのNAT情報がわかるので、後はクライアント同士がP2Pで接続しNAT超えすることができます。

FW等で直接P2Pが難しい場合は、P2PではなくTURNというサーバーがストリームデータの受け渡しに介入します。
つまり、Client - FW - TURNsv - FW - CLient となるわけですね。
しかしTURNもUDPを使いますし、TURNサーバおよびシグナリングサーバーとの通信ポートをFWに開けないといけません。

これを克服するために、さらにTURN over TCPというものがあるようです。TURNのUDPデータをTCPでカプセル化したものぽいです。

WebRTCの詳しい話は以下サイトが参考になります。
壁を越えろ！WebRTCでNAT/Firewallを越えて通信しよう | HTML5Experts.jp
エンタープライズ向けWebRTCの外堀が埋まってきている
 WebRTCの裏側 · GitHub
WebRTC コトハジメ · GitHub

通信の流れを追ってみた

3流PGの環境ではFWでクライアントは直接ネットに出れず、ホワイトリスト付きプロキシを使っています。
どのようなパケット流れて、どうブロックされてしまっているのかWireSharkで追っかけて見ました。

1.DNSでGoogleの複数のSTUNサーバの名前解決依頼。
2.クライアントはSTUNプロトコルで、Googleの複数のSTUNサーバに Binding Request(UDP) を投げる
3.FWでブロック
4.2.がタイムアウトしSTUNサーバ(IP)宛にプロキシ経由で通信試みる。(HTTPS)
5.iFilterにてブロック。
6.通信不可能。。。

WebRTCが利用できるかどうかのチェックサイトhttps://test.webrtc.org/があります。
現状のままでは、Network部分は Udp, Tcp 共に X でした。

対応方法1 FWに穴を開ける

ChromeのWebRTCが使うポートはデフォルトで、19302～19309です。
FWで、宛先:any , UDP:19302～19309 を許可してやるとうまくいきました。

この状態で、test.webrtc.org/ を実行すると、Network部分は Udp, Tcp 共に ○ でした。
この状態だと正常にMeetが使えます。

しかし、接続先はanyなのであまりよろしくないですよね。

接続先も指定できないか検討してみました。
WireSharkで調べると、Meetの時に使用しているのは、上述のMeetヘルプで掲載されているアドレス以外に、以下のホストにアクセスしているようでした。

stun.l.google.com
stun1.l.google.com
stun2.l.google.com
stun3.l.google.com
stun4.l.google.com

これらをFWのアドレスオブジェクトに追加し、ポートと合わせてフィルタするようにしました。
が、そうすると今度は正常に通信できなくなりました。
FQDN指定はだめなようです。おそらく理由は後述のiFilter使用時と同じで、Chrome側がFQDNアクセスではなくIPベースでアクセスしているからだと思います。FortiOSにDNS引きによるフィルタリング機能があればうまくいきそうですが、見つけることはできませんでした。

また、FWには穴を開けたくないので、少々パフォーマンス下がってもプロキシ経由で使えないものか試みました。

対応方法2 iFiter側で許可する(ホスト名DNS引き)

ChromeのWebRTCは直接接続がだめなら自動的にプロキシ経由でしてくれるので、単純にプロキシ(iFilter)側でGoogleMeetの通信を許可すればいいだけなのですが、これが意外と厄介でした。

なぜかというと、URL単位でのホワイトリスト形式を取っているからです。
Chromeがプロキシに送るリクエストは、URLではなくGoogleのSTUN,TRUNサーバのIPを送っています。
現時点でのサーバのホスト名とIPは以下の通りでした。(この中からランダムで接続先を選んでいるようです)

stun.l.google.com    74.125.23.127
stun1.l.google.com   108.177.98.127
stun2.l.google.com   173.194.199.127
stun3.l.google.com   173.194.196.127
stun4.l.google.com   64.233.177.127

Chromeからはstun.l.google.comというURLでアクセスするのではなく、直にIP=74.125.23.127でアクセスに行くわけですね。なので、stun.l.google.comをホワイトリストに登録してもだめなわけです。
まぁそのIPをホワイトリストに付け加えればいいんでしょうが、IPは変わる可能性があるのでなるべく避けておきたいところです。

iFilterの機能をいろいろ探していると、DNS引きした結果についてフィルタリングもしてくれるようです。つまり、stun.l.google.com を登録すると、DNS引きの結果のIP 74.125.23.127に対してフィルタリングを行う仕組みです。

その設定は、[ルールセット / ルールパーツ / 識別名リスト] にて、タイプ:DNS引きホスト(部分)にて登録できます。ここに上記のgoogleのサーバホスト名を登録します。

これでMeetが切断されず正常稼働するようになりました。

ただ、stun...のサーバが増えると、その分も登録してやる必要があります。。

余談(対応方法2 iFiter側で許可する(ポート)

余談ですが、iFilterにはポートをフィルタリングに加えることもできます。
その設定は、[ルールセット / ルールパーツ / アクセス情報セット]です。ただし、範囲指定ができないので1ポートずつ設定する必要があります。

ルール設定で、ポート19302ルールパーツ || ..(略).. || ポート19309ルールパーツ　と組み合わせれば、切断されずに正常稼動しました。

ポートともにアクセス先をフィルタリングできれば、よりセキュアじゃん!と思ったんですが、iFilterのルール設定側では、複数のルールパーツを組み合わせる際、AND と OR でしか設定できません。
つまり、stun.l.google.comルールパーツ && (ポート19302ルールパーツ || ..(略).. || ポート19309ルールパーツ ) という組み合わせができません。
なんので、DNS引き識別名リストか、ポートか、どちらかの条件しか設定できないようです。