緊急アクセスを有効にする
ユーザー向けに緊急アクセス (OLCRTC) を設定する方法: Pro サブスクリプション、緊急ルート、クラスターのスイッチ、サーバーごとの Runtime — 正しい順序で手順を追って説明します。
このページはサービスの運営者であるあなた向けです。ユーザーが緊急アクセスを頼りにできるよう、機能を有効にする方法を説明します。ユーザー自身に向けたページは別にあります: 緊急アクセス — 仕組みとブロック中の対処 — と、緊急クライアントのインストール — アプリの入手先とインストール方法です。
緊急アクセス (OLCRTC) は、通常の接続がまったく通らない許可リスト方式のネットワークのための予備のチャネルです。トラフィックは引き続きあなた自身のサーバーを通りますが、許可されたサービス上のビデオ通話に偽装されます。これは2つ目のプロトコルでも、メインの置き換えでもありません。速度は遅く、短いセッション向けで、ユーザーが手動で開始するもので、ほかのすべてが機能しなくなったときのためだけのものです。
この機能は実験的で、段階的に展開中です。すべてのスイッチをオンにしても、緊急 Runtime がまだあなたのサーバーにインストールされておらず、セッションの開始も有効になっていないことがあります。アクセスは徐々に開かれていきます。有効にしたあと、サーバーの状態が長く「正常」にならない場合は、単に展開の順番がまだ回ってきていない可能性が高いです。
また、すべてのネットワークや国で動作するわけではなく、外部の動画サービスとメールに到達できることが前提です。保証された機能として約束はせず、強いブロックに対する保険として案内してください。
必要なもの
- Pro サブスクリプション（または Max。Pro のすべてを含みます）。
- 緊急として指定されたルートが少なくとも1つ。
- クラスターで有効になっている OLCRTC のスイッチ。
- そのクラスター内で Runtime が有効になっているサーバーが少なくとも1台。
- 確認済みのメールアドレスとアクティブなアカウントを持つユーザー（下の制限の節を参照）。
操作の順序
スイッチは3か所に3つあり、そのうち2つは名前がほとんど同じなので混同しやすいです。
| 有効にする対象 | 場所 | 名称 |
|---|---|---|
| ルート | ルートの設定（編集時） | 「緊急ルート (OLCRTC)」 |
| クラスター | クラスターのページ、ルート一覧の上 | 「このクラスターで OLCRTC を有効にする」 |
| サーバー | サーバーのパネル、「編集」ボタン | 「このサーバーで OLCRTC を実行」 |
順序が重要です。緊急ルートが1つもない状態では、クラスターで OLCRTC を有効にできません。先にルート、次にクラスターです。
Pro を契約する。 請求 → サブスクリプションのブロックへ進みます。有効な Pro がなければ緊急アクセスのスイッチはそもそも表示されず、クラスターのページには代わりに「緊急アクセス (OLCRTC)」のカードと **「アップグレード」**ボタンが表示されます。
ルートを緊急として指定する — ルート自身の設定で。 ルートを編集用に開き、「緊急アクセス (OLCRTC)」のブロックで **「緊急ルート (OLCRTC)」**をオンにします。
このスイッチは既存のルートを編集するときにだけ表示されます。新規ルートの作成フォームにはありません。まずルートを作成し、その設定を開いてから緊急として指定してください。
そのルートのサーバーが緊急プールに加わります。ルートは複数指定できます。プールはそれらをすべてまとめ、あるルートに適したサーバーがなければ、別のルートのサーバーへ接続が回ります。指定されたルートには、ルート一覧で緊急のバッジが付きます。
クラスター全体で OLCRTC を有効にする。 これは2つ目の、別のスイッチで、ルート内のものとは違います。クラスターのページの、OLCRTC のバッジが付いた「緊急アクセス」ブロック内、ルート一覧のすぐ上にあり、名称は **「このクラスターで OLCRTC を有効にする」**です。
これがメインスイッチです。オフの間は、いくつのルートを緊急として指定していても、そのクラスターのユーザーは何もリクエストできません。スイッチの下では、すでにプールに入っている緊急ルートの数を確認できます。
サーバーでセッションを許可する。 サーバーをクリックしてパネルを開き、緊急 Runtime (OLCRTC) のブロックを見つけ、**「編集」**を押して **「このサーバーで OLCRTC を実行」をオンにし、「保存」**を押します。
Runtime はバックグラウンドで自動的にインストール・更新されるため、サーバーにログインする必要はありません。インストールされて報告が届くまで、状態は**「異常」**と表示されます。これは正常な挙動なので、「正常 · N/M アクティブ」になるまで待ってください。
このブロックは通常のインターフェースモードでのみ表示されます。簡易モードの Single（サーバー1台）にはありません。
容量を設定する。 同じブロック内の **「最大同時セッション数」**です。空欄のままでも構いませんが、そうしないほうがよいでしょう。次の節を参照してください。
ユーザーに知らせる。 すでにブロックされてから知らされる緊急アクセスは役に立ちません。クライアントは事前にインストールしておく必要があります。緊急アクセスとクライアントのインストールを案内し、インターネットがまだ正常に動いているうちに一度通しで試してもらってください。
サーバーが受けられるセッション数
緊急セッションは「VPN ユーザーが1人増える」のとは違い、かなりコストが高くなります。サーバーがトラフィックを動画ストリームに詰め込むため、CPU 時間を消費するからです。
実際のセッション（Full HD の動画、約5 Mbit/s）で測定したところ、1セッションあたり1コアの約15%と31 MB のメモリーを使いました。メモリーはほとんど問題になりません。実際の限界は CPU です。
| サーバーのコア数 | 妥当な容量 |
|---|---|
| 1 | 3 |
| 2 | 6〜7 |
| 4 | 12〜14 |
専用サーバーであっても、これらの数値を超えないでください。1コアで4セッションというだけで、すでにコアの約60%に加えてバックグラウンドの負荷がかかります。また、この測定は動画の視聴中（約5 Mbit/s）に行ったものです。ユーザーがトンネルを目一杯使えば、1セッションのコストはかなり高くなり得ます。
容量の欄が空だと「制限なし」を意味します。 その場合に残る唯一の保護は、ひどく過負荷になったサーバーへ新しいセッションを配置しなくなる自動制御だけです。ただしこれは遅れて反応するため、非力なサーバーではその時点で通常のユーザーがすでに影響を受けています。シングルコアのサーバーでは、容量を明示的に設定してください。
バランシングもある程度は助けになります。ルートがトラフィック最小負荷のアルゴリズム（既定値）を使っている場合、CPU 使用率の高いサーバーは空き帯域を少なく報告し、新しい通常ユーザーは負荷の低いサーバーへ振り分けられます。とはいえこれは CPU 全体の負荷に基づく補正であって、緊急セッションの数を数えているわけではなく、数分の遅れもあります。明示的な容量の代わりにはなりません。
インターフェースの表示
各サーバーの緊急 Runtime (OLCRTC) ブロックには次が表示されます。
- 機能 — このサーバーでセッションを実行してよいかどうか。
- 容量 — 同時セッション数に対するあなたの上限（「未設定」= 制限なし）。
- Runtime — 状態: 「正常 · N/M アクティブ」「異常」または「まだ報告なし」。
有効にした直後は**「異常」**が表示されるものと考えてください。これは正常で、サーバーはまだ Runtime をインストール中で報告していないだけです。その状態が長く続く場合は、そもそもサーバーに到達できるかを確認してください。「まだ報告なし」はページの読み込み中に一瞬表示されるだけです。
事前に知っておくべき制限
セッションは最大12時間続き、その後は自動的に停止します。延長はできません。ユーザーが新しい通話を作成し、新しいメールを送ります。
ユーザーごとに1セッション。 2通目のメールでは何も作成されず、返信もありません。故障だと思われないよう、あらかじめユーザーに説明しておくとよいでしょう。
下りは約14 Mbit/s、上りは1メガビット未満で、遅延は175〜235 msです。動画の視聴やメールの処理は快適ですが、大きなファイルの送信、ビデオ通話、ゲームには向きません。これはメイン接続ではなく、現在のトンネル構成の上限です。
ユーザーに対する要件は見た目より厳しいです。 確認済みのメールアドレスが必須のため、メールなしで手動作成したユーザーはアクセスを要求できません。アカウントもアクティブである必要があります。一時停止中、期限切れ、通信量の上限に達したもの、そして初回の支払い待ち（on_hold — 自分で登録してまだ支払っていないすべての人）のアカウントは拒否されます。メールは送信者認証を通過する必要があり、回数はユーザーあたり1時間に5回、サービス全体で100回に制限されています。
これらのチェックによる拒否は通知されません。ユーザーにはまったく返信が届きません。「メールを送ったのに何も返ってこない」という問い合わせがあった場合は、まずアカウントの状態と、正しい通話リンクが送られたかどうかから確認してください。
マルチホップのルートは対象外です。 緊急セッションには直接ルートのみが使われます。
iPhone はより難しいです。 iOS クライアントは sideload でしかインストールできず、Apple は取り扱っていません。iPhone を使うユーザーは、より入念に事前準備をする必要があります。詳しくはインストールガイドで説明しています。
無効にする方法
**「このクラスターで OLCRTC を有効にする」**はいつでも解除できます。解除すると新しいセッションは開始されなくなります。すでに動作中のセッションは、その期限まで続きます。
OLCRTC が有効な間は、最後の緊急ルートの指定を外すことも削除することもできません。先に別のルートを指定するか、クラスターの OLCRTC を無効にしてください。
Pro サブスクリプションが終了している場合でも無効にすることはできますが、再び有効にするには更新が必要です。