Menghidupkan akses kecemasan
Sediakan akses kecemasan (OLCRTC) untuk pengguna anda: langganan Pro, laluan kecemasan dan runtime setiap pelayan — langkah demi langkah, mengikut susunan yang betul.
Halaman ini untuk anda, pemilik perkhidmatan. Ia menerangkan cara menghidupkan akses kecemasan supaya pengguna anda boleh bergantung padanya. Untuk pengguna itu sendiri ada halaman berasingan: Akses kecemasan — bagaimana ia berfungsi dan apa yang perlu dilakukan semasa sekatan — dan Memasang klien kecemasan — di mana hendak memuat turun aplikasinya dan bagaimana memasangnya.
Akses kecemasan (OLCRTC) ialah saluran sandaran untuk rangkaian bersenarai dibenarkan, di mana sambungan biasa langsung tidak menembusi. Trafik tetap berjalan melalui pelayan anda sendiri, tetapi disamarkan sebagai panggilan video pada perkhidmatan yang dibenarkan. Ia bukan protokol kedua dan bukan pengganti yang utama: ia lebih perlahan, ditujukan untuk sesi pendek, dimulakan secara manual oleh pengguna, dan hanya untuk ketika segala yang lain sudah berhenti berfungsi.
Ciri ini dilancarkan berperingkat. Walaupun setiap suis telah dihidupkan, runtime kecemasan mungkin belum dipasang pada pelayan anda dan pemulaan sesi mungkin belum aktif: akses dibuka secara beransur-ansur. Jika sebuah pelayan lama tidak menjadi "sihat" selepas anda menghidupkannya, kemungkinan besar pelancaran itu memang belum sampai kepada anda.
Ia juga tidak berfungsi pada setiap rangkaian atau di setiap negara, dan ia bergantung pada perkhidmatan video luaran yang boleh dicapai (dan, bagi jalan e-mel, pada e-mel yang berjaya sampai). Jangan janjikannya sebagai keupayaan yang terjamin — perkenalkan ia sebagai insurans terhadap sekatan yang keras.
Apa yang anda perlukan
- langganan Pro (atau Max, yang merangkumi semua isi Pro);
- sekurang-kurangnya satu laluan yang ditandai kecemasan;
- sekurang-kurangnya satu pelayan dalam laluan kecemasan dengan runtime dihidupkan;
- pengguna dengan e-mel yang disahkan dan akaun aktif (lihat bahagian had di bawah).
Susunan langkah
Terdapat dua suis, di dua tempat berbeza:
| Apa yang anda hidupkan | Di mana ia berada | Apa namanya |
|---|---|---|
| Laluan | tetapan laluan (semasa menyunting) | "Laluan kecemasan (OLCRTC)" |
| Pelayan | panel pelayan, butang "Edit" | "Jalankan OLCRTC pada pelayan ini" |
Kluster tidak mempunyai suisnya sendiri: akses kecemasan untuk kluster aktif selagi sekurang-kurangnya satu laluannya ditandai.
Dengan langganan Pro pertama anda, sistem menanda laluan dengan paling banyak inbound berfungsi sebagai kecemasan untuk anda, dan akses kecemasan untuk kluster serta-merta aktif. Pelayan menyertai secara lalai dan runtime tersebar sendiri. Justeru langkah di bawah kebiasaannya ialah semakan, bukan urutan wajib: lalui jika anda mahu memilih laluan lain, menetapkan kapasiti atau mengecualikan pelayan tertentu.
Langgan Pro. Pergi ke Pengebilan → blok langganan. Tanpa Pro yang aktif, suis kecemasan langsung tidak dipaparkan: halaman kluster sebaliknya memaparkan kad "Akses kecemasan (OLCRTC)" dengan butang "Naik taraf".
Tandai satu laluan sebagai kecemasan — dalam tetapan laluan itu sendiri. Buka laluan itu untuk disunting dan hidupkan "Laluan kecemasan (OLCRTC)".
Suis itu hanya muncul semasa menyunting laluan sedia ada. Borang laluan baharu tidak mempunyainya: cipta laluan dahulu, kemudian buka tetapannya dan tandai ia sebagai kecemasan.
Pelayan pada laluan itu menyertai kumpulan kecemasan. Anda boleh menandai beberapa laluan — kumpulan itu menggabungkan kesemuanya, dan jika satu laluan tiada pelayan yang sesuai, sambungan itu pergi ke pelayan daripada laluan lain. Laluan yang ditandai mendapat lencana kecemasan (OLCRTC) dalam senarai laluan.
Sebaik sahaja laluan pertama ditandai, akses kecemasan untuk kluster aktif dengan sendirinya: tiada apa-apa lagi yang perlu dihidupkan.
Benarkan sesi pada pelayan. Klik sebuah pelayan untuk membuka panelnya, cari blok Runtime kecemasan (OLCRTC), tekan "Edit", hidupkan "Jalankan OLCRTC pada pelayan ini" dan tekan "Simpan".
Runtime memasang dan mengemas kini dirinya sendiri di latar belakang — tidak perlu log masuk ke pelayan. Sehingga ia dipasang dan melapor, keadaannya dipaparkan sebagai "tidak sihat"; itu normal, tunggu sehingga "sihat · N/M aktif".
Blok itu hanya muncul dalam mod antara muka biasa — mod Satu pelayan yang dipermudah tidak mempunyainya.
Tetapkan kapasitinya. Dalam blok yang sama — Maks. sesi serentak. Anda boleh membiarkannya kosong, tetapi lebih baik jangan: lihat bahagian seterusnya.
Beritahu pengguna anda. Akses kecemasan tidak berguna jika orang mengetahuinya setelah mereka disekat: kliennya perlu dipasang lebih awal. Tunjukkan mereka Akses kecemasan dan Memasang klien, dan minta mereka melalui keseluruhan alirannya sekali semasa internet masih berfungsi seperti biasa.
Berapa banyak sesi yang mampu ditanggung sebuah pelayan
Satu sesi kecemasan bukanlah "seorang lagi pengguna VPN" — ia jauh lebih mahal: pelayan mengemas trafik ke dalam strim video, dan itu memakan masa CPU.
Diukur pada sesi sebenar (video Full HD, kira-kira 5 Mbit/s), satu sesi mengambil lebih kurang 15% satu teras dan 31 MB memori. Memori hampir tidak penting; CPU ialah had yang sebenar.
| Teras pada pelayan | Kapasiti yang munasabah |
|---|---|
| 1 | 3 |
| 2 | 6–7 |
| 4 | 12–14 |
Jangan melebihi angka-angka ini walaupun pada pelayan khusus: empat sesi pada satu teras sudah pun kira-kira 60% daripadanya ditambah beban latar. Dan perhatikan bahawa pengukuran itu diambil sambil menonton video (~5 Mbit/s); jika seorang pengguna menepukan terowong itu, satu sesi boleh menelan kos yang jauh lebih tinggi.
Medan kapasiti yang kosong bermaksud "tiada had". Satu-satunya perlindungan yang tinggal ialah automasi yang berhenti meletakkan sesi baharu pada pelayan yang terlalu sarat. Namun ia bertindak balas dengan lengah, dan pada pelayan yang lemah pengguna biasa anda sudah pun terjejas menjelang itu. Pada pelayan berteras tunggal, tetapkan kapasitinya secara jelas.
Pengimbangan membantu sedikit sebanyak: jika laluan itu menggunakan algoritma "Paling kurang trafik" (lalai), pelayan dengan penggunaan CPU yang tinggi melaporkan lebar jalur bebas yang lebih kecil dan pengguna biasa yang baharu dihalakan ke pelayan yang kurang sarat. Tetapi itu ialah pembetulan berdasarkan CPU keseluruhan, bukan kiraan sesi kecemasan, dan ia lewat beberapa minit — ia bukan pengganti kapasiti yang jelas.
Apa yang dipaparkan oleh antara muka
Dalam blok Runtime kecemasan (OLCRTC) setiap pelayan:
- Fungsi — sama ada sesi boleh berjalan pada pelayan ini;
- Kapasiti — had sesi serentak yang anda tetapkan ("tidak ditetapkan" = tiada had);
- Runtime — keadaan: "sihat · N/M aktif", "tidak sihat", atau "belum melapor".
Sebaik anda menghidupkannya, jangkakan "tidak sihat" — itu normal, pelayan masih memasang runtime dan belum melapor. Jika ia kekal begitu untuk masa yang lama, periksa sama ada pelayan itu boleh dicapai langsung. "Belum melapor" hanya berkelip semasa halaman sedang dimuatkan.
Had yang wajar diketahui lebih awal
Satu sesi hidup sehingga 12 jam, kemudian berhenti dengan sendirinya. Ia tidak boleh dilanjutkan — penggunanya mencipta panggilan baharu dan meminta sambungan sekali lagi.
Satu sesi bagi setiap pengguna. Permintaan kedua tidak mencipta apa-apa selagi satu sesi sedang berjalan: dalam panel akaun, pengguna akan melihat "sesi sudah berjalan", manakala e-mel kedua tidak mendapat balasan — berbaloi dijelaskan kepada pengguna lebih awal supaya ia tidak kelihatan rosak.
Kelajuan internet lebih rendah berbanding sambungan melalui Xray.
Perkhidmatan video mesti boleh dicapai dari negara pelayan. Yang menyertai panggilan ialah pelayan anda, jadi yang menentukan ialah negara pelayan, bukan negara pengguna. Contohnya, di Latvia Yandex dan Wildberries disekat — melalui pelayan Latvia, Telemost dan WB Stream tidak akan naik. Ambil kira perkara ini semasa memilih pelayan mana yang mengaktifkan akses kecemasan.
Syarat ke atas pengguna lebih ketat daripada yang kelihatan. E-mel yang disahkan diperlukan — pengguna yang anda cipta secara manual tanpa e-mel tidak boleh meminta akses. Akaun itu juga mesti aktif: akaun yang dijeda, tamat tempoh, kehabisan had dan yang menunggu pembayaran pertama (on_hold — semua orang yang mendaftar sendiri dan belum membayar) akan ditolak. E-mel itu mesti lulus pengesahan pengirim dan hanya mengandungi pautan panggilan.
Dalam panel akaun, setiap penolakan dipaparkan bersama sebabnya; melalui e-mel, balasan dihantar apabila kami dapat mengenal pasti pengirim sebagai pengguna anda (pengirim yang tidak disahkan atau tidak dikenali tidak mendapat balasan). Jika seseorang mengadu "saya minta, tetapi tiada apa-apa berlaku", mulakan dengan status akaun dan pautan panggilan yang digunakan; bagi jalan e-mel, periksa juga bahawa e-mel itu dihantar daripada alamat akaun dan hanya mengandungi pautan bilik.
Laluan berbilang lompatan tidak menyertainya. Hanya laluan terus digunakan untuk sesi kecemasan.
Klien kecemasan ialah Ghostlane, termasuk untuk iPhone. Ia tersedia di App Store dan Google Play, serta mempunyai binaan untuk Windows, macOS dan Linux. Pengguna yang memasang olcbox lama perlu beralih: olcbox tidak lagi dikemas kini serta tidak mengenali SaluteJazz dan VK Calls, dan versi lamanya tidak mempunyai penyulitan baharu. Lihat panduan pemasangan.
Cara mematikannya
Matikan "Laluan kecemasan (OLCRTC)" pada setiap laluan kecemasan kluster, atau padam laluan-laluan itu — akses kecemasan untuk kluster dimatikan dan sesi baharu berhenti dimulakan. Sesi yang sudah berjalan akan menghabiskan tempohnya.
Jika langganan Pro anda telah tamat, anda masih boleh mematikan semuanya, tetapi menghidupkannya semula memerlukan pembaharuan.