A vészhelyzeti hozzáférés bekapcsolása
A vészhelyzeti hozzáférés (OLCRTC) beállítása a felhasználói számára: Pro-előfizetés, vészhelyzeti útvonal és a kiszolgálónkénti runtime — lépésről lépésre, a helyes sorrendben.
Ez az oldal Önnek, a szolgáltatás tulajdonosának szól. Arról szól, hogyan kapcsolja be a vészhelyzeti hozzáférést, hogy a felhasználói számíthassanak rá. Maguknak a felhasználóknak külön oldalak szolgálnak: Vészhelyzeti hozzáférés — hogyan működik, és mit kell tenni blokkolás idején — és A vészhelyzeti alkalmazás telepítése — honnan tölthető le az alkalmazás, és hogyan telepíthető.
A vészhelyzeti hozzáférés (OLCRTC) tartalék csatorna az engedélyezési listát használó hálózatokhoz, ahol a szokásos kapcsolat egyáltalán nem jut át. A forgalom továbbra is az Ön saját kiszolgálóin megy keresztül, de egy engedélyezett szolgáltatásban zajló videohívásnak álcázzuk. Ez nem második protokoll, és nem a fő protokoll helyettesítője: lassabb, rövid munkamenetekre való, a felhasználó kézzel indítja, és csak akkor, amikor minden más már nem működik.
A funkciót szakaszosan vezetjük be. Még ha minden kapcsoló be is van kapcsolva, a vészhelyzeti runtime még nem biztos, hogy telepítve van a kiszolgálóira, és a munkamenetek indítása sem feltétlenül aktív: a hozzáférés fokozatosan nyílik meg. Ha egy kiszolgáló a bekapcsolás után sokáig nem kerül „rendben” állapotba, nagy valószínűséggel a bevezetés egyszerűen még nem ért el Önhöz.
Emellett nem működik minden hálózaton és minden országban, és függ egy külső videószolgáltatás elérhetőségétől (az e-mailes útnál pedig attól is, hogy átjutnak-e a levelek). Ne ígérje garantált képességként — helyesebb a kemény blokkolások esetére szóló biztosításként bemutatni.
Mi szükséges hozzá
- Pro-előfizetés (vagy Max, amely mindent tartalmaz a Próból);
- legalább egy vészhelyzetinek jelölt útvonal;
- egy vészhelyzeti útvonal legalább egy kiszolgálója bekapcsolt runtime-mal;
- megerősített e-mail-címmel és aktív fiókkal rendelkező felhasználók (részletesen a korlátozásokról szóló szakaszban alább).
A bekapcsolás sorrendje
Két kapcsoló van, két különböző helyen:
| Mit kapcsol be | Hol található | Mi a neve |
|---|---|---|
| Útvonal | útvonalbeállítások (szerkesztéskor) | „Vészhelyzeti útvonal (OLCRTC)” |
| Kiszolgáló | kiszolgálópanel, „Szerkesztés” gomb | „OLCRTC futtatása ezen a szerveren” |
A fürtnek nincs saját kapcsolója: a fürt vészhelyzeti hozzáférése addig van bekapcsolva, amíg legalább egy útvonala meg van jelölve vészhelyzetiként.
Az első Pro-előfizetéssel a rendszer Ön helyett vészhelyzetinek jelöli a legtöbb működő inbounddal rendelkező útvonalat, és a fürt vészhelyzeti hozzáférése azonnal bekapcsol. A szerverek alapértelmezés szerint részt vesznek, a runtime pedig magától kigördül. Az alábbi lépések ezért többnyire ellenőrzés, nem kötelező sorrend: menjen végig rajtuk, ha más útvonalakat választana, kapacitást állítana be, vagy kihagyna egy adott szervert.
Fizessen elő a Prora. Nyissa meg a Fizetés részt → előfizetési blokk. Aktív Pro nélkül a vészhelyzeti hozzáférés kapcsolói meg sem jelennek: a fürt oldalán helyettük a „Vészhelyzeti hozzáférés (OLCRTC)” kártya látszik, „Frissítés” gombbal.
Jelöljön meg egy útvonalat vészhelyzetiként — magának az útvonalnak a beállításaiban. Nyissa meg az útvonalat szerkesztésre, és kapcsolja be a „Vészhelyzeti útvonal (OLCRTC)” kapcsolót.
A kapcsoló csak meglévő útvonal szerkesztésekor jelenik meg. Az új útvonal létrehozására szolgáló űrlapon nincs meg: előbb hozza létre az útvonalat, azután nyissa meg a beállításait, és jelölje meg vészhelyzetiként.
Az adott útvonal kiszolgálói bekerülnek a vészhelyzeti készletbe. Több útvonalat is megjelölhet — a készlet mindet egyesíti, és ha az egyik útvonalon nincs alkalmas kiszolgáló, a kapcsolat egy másik útvonal kiszolgálójára kerül. A megjelölt útvonalak az útvonallistában vészhelyzeti (OLCRTC) címkét kapnak.
Amint megjelöli az első útvonalat, a fürt vészhelyzeti hozzáférése magától bekapcsol: külön semmit sem kell bekapcsolnia.
Engedélyezze az indítást a kiszolgálókon. Kattintson egy kiszolgálóra, hogy megnyíljon a panelje, keresse meg a Vészhelyzeti Runtime (OLCRTC) blokkot, nyomja meg a „Szerkesztés” gombot, kapcsolja be az „OLCRTC futtatása ezen a szerveren” beállítást, és nyomja meg a „Mentés” gombot.
A runtime a háttérben magától települ és frissül — nem kell belépnie a kiszolgálóra. Amíg nem települt és nem jelentkezett be, az állapot „nincs rendben” lesz; ez normális, várja meg a „rendben · N/M aktív” állapotot.
A blokk csak a szokásos felületmódban látható — az egyszerűsített Single módban nincs meg.
Adja meg a kapacitást. Ugyanabban a blokkban — Egyidejű munkamenetek max. A mezőt üresen is hagyhatja, de jobb, ha nem: lásd a következő szakaszt.
Tájékoztassa a felhasználóit. A vészhelyzeti hozzáférés haszontalan, ha akkor értesülnek róla, amikor már blokkolás alatt vannak: az alkalmazást előre kell telepíteni. Irányítsa őket a Vészhelyzeti hozzáférés és Az alkalmazás telepítése oldalra, és kérje meg őket, hogy egyszer járják végig a teljes folyamatot, amíg az internet még rendesen működik.
Hány munkamenetet bír el egy kiszolgáló
Egy vészhelyzeti munkamenet nem „még egy VPN-felhasználó” — érezhetően drágább: a kiszolgáló videofolyamba csomagolja a forgalmat, és ez processzoridőbe kerül.
Élő munkameneten végzett mérés szerint (Full HD videó nézése, körülbelül 5 Mbit/s) egy munkamenet nagyjából egy mag 15%-át és 31 MB memóriát foglal. A memória szinte semmit sem számít; a valódi korlát a processzor.
| Magok a kiszolgálón | Ésszerű kapacitás |
|---|---|
| 1 | 3 |
| 2 | 6–7 |
| 4 | 12–14 |
Ezek fölé még dedikált kiszolgálón se menjen: már négy munkamenet egyetlen magon annak nagyjából 60%-át jelenti, plusz a háttérterhelést. És vegye figyelembe, hogy a mérés videónézés közben készült (~5 Mbit/s); ha egy felhasználó kihajtja az alagutat, egy munkamenet érezhetően többe kerülhet.
Az üres kapacitásmező azt jelenti: „nincs korlát”. Ekkor az egyetlen védelem az az automatika, amely leáll az új munkamenetek kihelyezésével egy súlyosan túlterhelt kiszolgálóra. Ez azonban késleltetéssel reagál, és egy gyenge kiszolgálón addigra már a szokásos felhasználói is szenvedni fognak. Egymagos kiszolgálókon kifejezetten adja meg a kapacitást.
A terheléselosztás részben segít: ha az útvonalnál a „Legkisebb terhelés forgalom szerint” algoritmus van kiválasztva (ez az alapértelmezett), a magas processzorterhelésű kiszolgáló kevesebb szabad sávszélességet jelent, és az új szokásos felhasználókat a rendszer kevésbé terhelt kiszolgálókra irányítja. De ez az általános processzorterhelés szerinti korrekció, nem a vészhelyzeti munkamenetek számlálása, és több perc késéssel működik — nem helyettesíti a kifejezetten megadott kapacitást.
Mi látszik a felületen
Minden kiszolgáló Vészhelyzeti Runtime (OLCRTC) blokkjában:
- Funkció — futhatnak-e munkamenetek ezen a kiszolgálón;
- Kapacitás — az Ön korlátja az egyidejű munkamenetekre („nincs beállítva” = nincs korlát);
- Runtime — állapot: „rendben · N/M aktív”, „nincs rendben” vagy „még nem jelent”.
Közvetlenül a bekapcsolás után számítson a „nincs rendben” állapotra — ez normális, a kiszolgáló még telepíti a runtime-ot, és még nem jelentkezett be. Ha az állapot sokáig fennmarad, ellenőrizze, hogy a kiszolgáló egyáltalán elérhető-e. A „még nem jelent” felirat csak az oldal betöltése közben villan fel.
Korlátok, amelyeket érdemes előre ismerni
Egy munkamenet legfeljebb 12 óráig él, azután magától leáll. Nem hosszabbítható meg — a felhasználó új hívást hoz létre, és újra kapcsolatot kér.
Felhasználónként egy munkamenet. A második kérés nem hoz létre második munkamenetet: a felhasználó fiókjában „a munkamenet már fut” üzenet jelenik meg, a második levél pedig válasz nélkül marad — érdemes ezt előre elmagyarázni a felhasználóknak, hogy ne tűnjön hibának.
Az internet sebessége alacsonyabb, mint Xray-en keresztüli kapcsolatnál.
A videoszolgáltatásnak elérhetőnek kell lennie a szerver országából. A hívásba az Ön szervere lép be, tehát a szerver országa számít, nem a felhasználóé. Lettországban például a Yandex és a Wildberries blokkolva van — lett szerveren keresztül a Telemost és a WB Stream nem indul el. Vegye ezt figyelembe, amikor kiválasztja, mely szervereken kapcsolja be a vészhelyzeti hozzáférést.
A felhasználókkal szemben támasztott követelmények szigorúbbak, mint amilyennek látszanak. Megerősített e-mail-cím szükséges — akiket kézzel, e-mail nélkül vitt fel, azok nem tudnak hozzáférést igényelni. A fióknak ezenfelül aktívnak kell lennie: a felfüggesztett, lejárt, a keretüket kimerített és az első fizetésre váró fiókok (on_hold — mindenki, aki maga regisztrált, és még nem fizetett) elutasításra kerülnek. A levélnek át kell mennie a feladóhitelesítésen, és csak a híváshivatkozást tartalmazhatja.
A felhasználó fiókjában minden elutasítás az okával együtt jelenik meg; levélre akkor megy válasz, ha a feladót azonosítani tudjuk az Ön felhasználójaként (a nem hitelesített vagy ismeretlen feladó nem kap választ). Ha valaki azzal fordul Önhöz, hogy „kértem, és semmi sem történt”, kezdje a fiók állapotával és a használt híváshivatkozással, az e-mailes útnál pedig ellenőrizze azt is, hogy a levél a fiók címéről ment-e, és csak a hivatkozást tartalmazta-e.
A többugrásos útvonalak nem vesznek részt. A vészhelyzeti munkamenetekhez csak közvetlen útvonalakat használunk.
A vészhelyzeti kliens a Ghostlane, iPhone-ra is. Megtalálható az App Store-ban és a Google Playen, és Windowsra, macOS-re és Linuxra is van belőle változat. Azoknak a felhasználóknak, akik a régi olcboxot telepítették, át kell váltaniuk a Ghostlane-re: az olcbox már nem frissül, és nem ismeri a SaluteJazz és a VK Calls szolgáltatást, a régebbi verzióiból pedig hiányzik az új titkosítás. Részletek: telepítési útmutató.
Hogyan kapcsolható ki
Kapcsolja ki a „Vészhelyzeti útvonal (OLCRTC)” kapcsolót a fürt összes vészhelyzeti útvonalán, vagy törölje ezeket az útvonalakat — a fürt vészhelyzeti hozzáférése kikapcsol, és új munkamenetek nem indulnak többé. A már elindultak kitöltik a saját idejüket.
Ha a Pro-előfizetés lejárt, kikapcsolni mindent lehet, visszakapcsolni viszont csak a megújítása után.