การเข้าถึงฉุกเฉิน: เมื่อเครือข่ายบล็อกทุกอย่าง

ทุกอย่างที่ผ่านมาตั้งอยู่บนสมมติฐานเดียว คือเครือข่ายยังปล่อยให้เซิร์ฟเวอร์ของคุณผ่านไปได้ เส้นทาง เลือกเซิร์ฟเวอร์ อินบาวด์ ทำให้การเชื่อมต่อดูเหมือนการเข้าเว็บ HTTPS ธรรมดา มัลติฮอป ยืดเส้นทางข้ามหลายประเทศ — แต่ทั้งหมดนี้ต้องการให้ทราฟฟิกออกจากเครื่องได้เสียก่อน

และมันไม่ได้ออกไปเสมอไป เครือข่ายเปลี่ยนมาใช้ ไวต์ลิสต์: บริการที่อนุญาตไม่กี่รายการยังใช้ได้ ส่วนที่เหลือทั้งหมด — รวมถึง VPN ของคุณ — ผ่านไม่ได้เลย การเข้าถึงฉุกเฉิน (OLCRTC) ถูกสร้างมาเพื่อชั่วโมงแบบนั้นโดยเฉพาะ

มันคืออะไร — และไม่ใช่อะไร

การเข้าถึงฉุกเฉินคือ ช่องสำรอง ไม่ใช่โปรโตคอลที่สอง การเชื่อมต่อปกติยังคงเป็นแบบเดิม: VLESS + Reality บนเซิร์ฟเวอร์ของคุณเอง การเข้าถึงฉุกเฉินใช้เซิร์ฟเวอร์ชุดเดียวกัน แต่ห่อทราฟฟิกไว้ภายใน วิดีโอคอล บนบริการที่เครือข่ายจำกัดยังปล่อยผ่าน — จากภายนอกมันดูเหมือนการประชุมวิดีโอธรรมดา

จากตรงนี้มีผลตามมาสามข้อ และควรรู้ทั้งสามข้อก่อนจะสัญญาอะไรกับใคร:

• ผู้ใช้เป็นคนเปิดเองด้วยมือ เฉพาะตอนที่ไม่มีอะไรใช้ได้แล้วเท่านั้น ไม่มีการสลับอัตโนมัติ: การเชื่อมต่อปกติไม่ «กระโดด» ไปใช้ช่องฉุกเฉินเอง
• มันช้า ดาวน์โหลดราว 14 Mbit/s อัปโหลดต่ำกว่าหนึ่งเมกะบิต ดีเลย์ 175–235 ms อ่านและดูวิดีโอสบาย แต่ส่งไฟล์ วิดีโอคอล และเล่นเกมไม่ไหว
• มันชั่วคราว เซสชันหนึ่งอยู่ได้ไม่เกิน 12 ชั่วโมงแล้วหยุดเอง ผู้ใช้มีได้ครั้งละหนึ่งเซสชัน ถ้าจะใช้ต่อก็เริ่มเซสชันใหม่

ฝั่งผู้ใช้เห็นอะไร

1. ผู้ใช้สร้าง วิดีโอคอลใหม่ ในบริการที่รองรับ — Yandex Telemost, WB Stream หรือ Jitsi Meet
2. ส่งลิงก์ของห้องให้เรา: วางลงในบล็อก การเข้าถึงฉุกเฉิน ในบัญชีของตัวเอง หรือส่งอีเมลไปยังที่อยู่สำหรับคำขอส่วนตัว ทั้งสองทางทำสิ่งเดียวกัน — และทางอีเมลยังใช้ได้แม้หน้าร้านของคุณจะถูกบล็อกไปแล้ว
3. เซิร์ฟเวอร์ตัวหนึ่งของคุณเข้าห้องนั้นในฐานะแขก ราวหนึ่งนาทีต่อมาผู้ใช้จะได้ลิงก์เชื่อมต่อที่ขึ้นต้นด้วย olcrtc:// พร้อมคิวอาร์โค้ด
4. ผู้ใช้นำเข้าลิงก์นั้นใน olcbox ซึ่งเป็นไคลเอนต์ฉุกเฉิน แล้วเชื่อมต่อ

ฝั่งคุณต้องมีอะไรบ้าง

• การสมัคร Pro — €0.99 ต่อเดือน การเข้าถึงฉุกเฉินมาพร้อมกับระดับนี้ ส่วน Max ก็มีเช่นกัน พร้อมกับทุกอย่างที่เหลือ (บทที่ 13)
• เส้นทางฉุกเฉิน เซิร์ฟเวอร์ของเส้นทางที่ถูกทำเครื่องหมายว่าฉุกเฉินจะรวมกันเป็นพูลที่เซสชันจะไปลง เมื่อสมัครครั้งแรก ระบบจะทำเครื่องหมายให้คุณหนึ่งเส้นทางเอง — เส้นทางที่มีอินบาวด์ทำงานอยู่มากที่สุด — พร้อมกับยกสวิตช์ของคลัสเตอร์ขึ้นให้ด้วย
• เซิร์ฟเวอร์ เข้าร่วมโดยค่าเริ่มต้น ส่วนรันไทม์ติดตั้งและอัปเดตตัวเองเบื้องหลัง: ไม่ต้องเข้า SSH ทำอะไรเลย

พูดง่าย ๆ คือในกรณีทั่วไปไม่มีอะไรต้องตั้งค่า: สมัครแล้วการเข้าถึงฉุกเฉินก็ทำงาน ส่วนสวิตช์แบบมือยังอยู่ตรงนั้นเผื่อคุณต้องการ: เส้นทางไหนบ้างที่ประกอบเป็นพูล เซิร์ฟเวอร์หนึ่งตัวรับได้กี่เซสชัน และควรกันตัวไหนออกหรือไม่

ต่างจากเส้นทางปกติอย่างไร

• ผู้ใช้ไม่ได้เลือกประเทศ เขาไม่เห็นพูลด้วยซ้ำ — เจตนาเชิงภูมิศาสตร์เป็นสิ่งที่คุณกำหนดผ่านการเลือกว่าเส้นทางไหนเป็นฉุกเฉิน ทำเครื่องหมายได้หลายเส้นทาง: พูลจะรวมทั้งหมดเข้าด้วยกัน และถ้าเส้นทางหนึ่งไม่มีเซิร์ฟเวอร์ที่เหมาะ เซสชันก็จะไปลงอีกเส้นทางหนึ่ง
• เส้นทางมัลติฮอปไม่เข้าร่วม เซสชันฉุกเฉินใช้เฉพาะเส้นทางตรงเท่านั้น
• หนึ่งเซสชันกิน CPU จริง ๆ การห่อทราฟฟิกเป็นสตรีมวิดีโอในการวัดใช้ราว 15% ของหนึ่งคอร์ และหน่วยความจำ 31 MB (เซสชันวิดีโอราว 5 Mbit/s) — แพงกว่าผู้ใช้ VPN เพิ่มอีกหนึ่งคนมาก เกณฑ์คร่าว ๆ คือ 3 เซสชันต่อคอร์: 3 บนเซิร์ฟเวอร์คอร์เดียว, 6–7 ที่สองคอร์, 12–14 ที่สี่คอร์

ผู้ใช้คนไหนของคุณถึงจะใช้ได้จริง

ข้อกำหนดเข้มกว่าที่เห็น — และคำถามที่เข้าฝ่ายซัพพอร์ตก็มาจากตรงนี้:

• อีเมลที่ยืนยันแล้ว ผู้ใช้ที่คุณสร้างเองด้วยมือโดยไม่มีที่อยู่อีเมลจะขอไม่ได้เลย
• บัญชีที่ใช้งานอยู่ บัญชีที่หยุดชั่วคราว หมดอายุ ใช้โควตาทราฟฟิกหมด และรอชำระเงินครั้งแรก (ทุกคนที่สมัครเองและยังไม่ได้จ่าย) จะถูกปฏิเสธ

คำบ่นที่คุณจะได้ยินคือ «ขอไปแล้วแต่ไม่มีอะไรเกิดขึ้น» ให้เริ่มจากสถานะบัญชีและลิงก์ห้องที่เขาใช้ ส่วนทางอีเมลให้ตรวจด้วยว่าส่งจากที่อยู่ของบัญชีและมีแต่ลิงก์อยู่ในเนื้อความ

จำไว้

• การเข้าถึงฉุกเฉินคือห่วงชูชีพสำหรับเครือข่ายที่ใช้ไวต์ลิสต์ ไม่ใช่โปรโตคอลที่สองและไม่ใช่ตัวแทนของการเชื่อมต่อปกติ
• ทราฟฟิกยังวิ่งผ่านเซิร์ฟเวอร์ของคุณเอง โดยปลอมตัวเป็นวิดีโอคอลที่ผู้ใช้สร้างขึ้นเอง
• ช้า ไม่เกิน 12 ชั่วโมง หนึ่งเซสชันต่อผู้ใช้ เริ่มด้วยมือ
• พร้อมกับ Pro มันเปิดเอง: เส้นทางหนึ่งถูกทำเครื่องหมายว่าฉุกเฉิน สวิตช์คลัสเตอร์ถูกยกขึ้น เซิร์ฟเวอร์เข้าร่วมโดยค่าเริ่มต้น
• หนึ่งเซสชัน ≈ 15% ของหนึ่งคอร์ CPU — บนเซิร์ฟเวอร์ที่อ่อนแรงให้กำหนดความจุอย่างชัดเจน
• ผู้ใช้ต้องมีอีเมลที่ยืนยันแล้ว บัญชีที่ใช้งานอยู่ และไคลเอนต์ที่ติดตั้งไว้ ล่วงหน้า

ต่อไป

การเข้าถึงฉุกเฉินคือเรื่องของการรับมือเมื่อเครือข่ายพัง บทถัดไปว่าด้วยอีกครึ่งหนึ่ง: ระบบรู้ได้อย่างไรว่า เซิร์ฟเวอร์ของคุณ พัง