緊急アクセス: ネットワークがすべてを遮断したとき
CreateYourVPNの緊急アクセス(OLCRTC): 許可リスト方式のネットワーク向けに、ビデオ通話を装った予備の経路 — サーバーへの負荷、Proと同時に自動で入るもの、そして利用者に前もって伝えるべきこと。
ここまでの話はすべて、ある前提の上に成り立っていました。ネットワークがまだあなたのサーバーを通してくれる、という前提です。ルートがサーバーを選び、インバウンドが接続をごく普通のHTTPSアクセスのように見せ、マルチホップが経路を複数の国にまたがらせる — どれも、通信が端末から出ていけることが前提です。
いつも出ていけるとは限りません。ネットワークが許可リストに切り替わると、許可された短いリストのサービスだけが動き、それ以外は — あなたのVPNも含めて — まったく通らなくなります。**緊急アクセス(OLCRTC)**は、まさにその時間のために作られています。
何であって、何でないのか
緊急アクセスは予備の経路であって、第二のプロトコルではありません。通常の接続はこれまでどおり、あなた自身のサーバー上のVLESS + Realityです。緊急アクセスは同じサーバーを使いながら、通信を、制限されたネットワークがまだ許しているサービスのビデオ通話の中に包み込みます — 外から見れば、ごく普通のビデオ会議です。
ここから三つのことが導かれます。何かを約束する前に、三つとも知っておく価値があります。
- 利用者が手動で開始します。 他に何も動かなくなったときだけです。自動フェイルオーバーはありません。通常の接続が勝手に「切り替わる」ことはありません。
- 遅いです。 下り約14 Mbit/s、上りは1メガビット未満、遅延175〜235 ms。読み書きや動画視聴には十分ですが、ファイル送信・ビデオ通話・ゲームには使えません。
- 一時的です。 1セッションは最大12時間で自動的に停止します。同時に持てるのは1利用者につき1セッションだけで、続けたければ新しく始めます。
この機能は実験的です。制限されたネットワークから外部のビデオサービスに到達できるかどうかに 依存するため、すべての国・すべてのネットワークで動くわけではありません。利用者には、 厳しいブロックに対する保険として伝えてください。保証された機能としてではなく。
利用者から見た流れ
- 対応サービスで新しいビデオ通話を作ります — Yandex Telemost、WB Stream、Jitsi Meetのいずれか。
- そのリンクを渡します。マイページの緊急アクセスブロックに貼り付けるか、自分専用のリクエスト用アドレスにメールで送るか。どちらも同じことをします — そしてメール経路は、あなたのストアフロントがすでにブロックされていても機能し続けます。
- あなたのサーバーの1台がゲストとしてその通話に入ります。1分ほどで、利用者は
olcrtc://で始まる接続リンクとQRコードを受け取ります。 - それを緊急クライアントolcboxに取り込み、接続します。
利用者に必要な二つのもの — アプリとリクエスト用アドレス — は、ブロックが起きる前に 手元になければなりません。許可リスト下ではアプリストアもダウンロードページもたいてい 到達できず、アドレスが表示されるマイページも開かないかもしれません。ブロックの最中に 緊急アクセスを知った人は、知るのが遅すぎたということです。
緊急アクセス
利用者向けのページ: 仕組み、対応しているサービス、ブロック中にすべきこと。
緊急クライアントのインストール
olcboxをAndroid、iPhone、Windows、macOS、Linux向けにどこから入手するか — そしてなぜ前もって行うのか。
あなたの側に必要なもの
- Proサブスクリプション — 月€0.99。 緊急アクセスはこのティアに付いてきます。Maxにも、ほかのすべてと一緒に含まれます(レッスン13)。
- 緊急ルート。 緊急と印を付けたルートのサーバーが、セッションの着地先となるプールを作ります。最初のサブスクリプション時にシステムが1つを自動で選んで印を付け(動作中のインバウンドが最も多いルート)、ついでにクラスターのスイッチも上げます。
- サーバー。 既定で参加します。ランタイムはバックグラウンドで自動的にインストール・更新されるので、SSHで作業することはありません。
つまり通常のケースでは設定するものは何もありません。契約すれば緊急アクセスは動きます。手動のスイッチは、必要になったときのために残されています — どのルートがプールを構成するか、1台あたり何セッションまで持たせるか、特定のサーバーを外すかどうか。
通常のルートとの違い
- 利用者は国を選びません。 プール自体が見えません。地理的な意図は、どのルートを緊急にするかであなたが表現します。複数に印を付けられます。プールはそれらを統合し、あるルートに適したサーバーがなければセッションは別のルートへ回ります。
- マルチホップのルートは参加しません。 緊急セッションには直通ルートだけが使われます。
- 1セッションは本当にCPUを食います。 通信を映像ストリームに詰め込む処理は、実測でおよそ**1コアの15%**とメモリ31 MBを消費しました(約5 Mbit/sの動画セッション)— VPN利用者が1人増えるのとは比べものになりません。目安は1コアあたり3セッション: 1コアのサーバーで3、2コアで6〜7、4コアで12〜14。
**「同時セッションの上限」**を空欄にすると無制限という意味になります。非力なサーバーでは これは罠です。緊急セッションが、通常の顧客が支払っているCPUを食い尽くします。1コアの マシンでは数値を明示的に入れてください。
実際に使えるのはどの利用者か
要件は見た目より厳しく、サポートへの質問はここから生まれます。
- 確認済みのメールアドレス。 アドレスなしで手動作成した利用者は、そもそもリクエストできません。
- 有効なアカウント。 一時停止・期限切れ・通信量上限に達したもの・初回支払い待ち(自分で登録してまだ支払っていない人すべて)は拒否されます。
寄せられる苦情は「リクエストしたのに何も起きない」という形になります。まずアカウントの状態と使った通話リンクを確認し、メール経路ならアカウントのアドレスから送られ、本文にリンクだけが入っていたかも確かめてください。
覚えておくこと
- 緊急アクセスは許可リスト方式のネットワーク向けの浮き輪であり、第二のプロトコルでも通常接続の代替でもありません。
- 通信はあなた自身のサーバーを通り、利用者自身が作ったビデオ通話に偽装されます。
- 遅く、最大12時間、利用者ごとに1セッション、開始は手動。
- Proと同時に自動で入ります: ルートが緊急に印を付けられ、クラスターのスイッチが上がり、サーバーは既定で参加します。
- 1セッション ≈ CPU1コアの15% — 非力なサーバーでは上限を明示的に設定を。
- 利用者には確認済みメール、有効なアカウント、そして前もって入れたクライアントが必要です。
次へ
緊急アクセスは、ネットワークが壊れたときの話でした。次のレッスンはもう半分の話です — あなたのサーバーが壊れたことを、システムはどうやって気づくのか。