Fail-open กับ fail-closed: kill switch ของ VPN ตัดสินอะไร
ทั้งสองคำอธิบายว่าเกิดอะไรขึ้นเมื่ออุโมงค์หายไป ไม่ใช่ว่าการเข้ารหัสแข็งแรงแค่ไหน ขอบเขตที่คุณเลือกเป็นตัวตัดสินว่าทราฟฟิกนั้นรั่วจริงหรือไม่
ความเชื่อที่ผิดคือ fail-closed เป็นการตั้งค่าที่ปลอดภัยและ fail-open คือความประมาท ทั้งสองอธิบายว่าเกิดอะไรขึ้นกับทราฟฟิกเมื่ออุโมงค์หายไป และไม่มีตัวใดเปลี่ยนคุณภาพการเข้ารหัสของอุโมงค์นั้น นโยบาย fail-closed ที่มีรายการข้อยกเว้นยาวอาจรั่วได้มากกว่านโยบาย fail-open บนอุปกรณ์ที่ไม่เคยออกจากเครือข่ายสำนักงาน เลือกผลลัพธ์ที่คุณอธิบายให้เจ้าของทราฟฟิกได้
ป้ายบอกผลลัพธ์ ไม่ใช่ความแข็งแกร่ง
คำศัพท์นี้มาจากระบบควบคุม: fail-open อนุญาตให้ทำงานเมื่อส่วนประกอบล้มเหลว fail-closed ปฏิเสธ เมื่อใช้กับ VPN ส่วนประกอบที่ล้มเหลวคืออุโมงค์ และคำถามคือทราฟฟิกได้รับอนุญาตให้ดำเนินต่อผ่านเส้นทางอื่นหรือไม่ การเลือก cipher ความยาวคีย์ และโปรโตคอลเป็นการตัดสินใจแยกกัน
ความสับสนยังคงอยู่เพราะ kill switch ฟังดูเป็นคุณสมบัติความปลอดภัย และผู้ขายก็ทำตลาดเช่นนั้น ในเชิงกลไกมันคือ กฎการกำหนดเส้นทางและไฟร์วอลล์ที่บล็อกทราฟฟิกที่อุโมงค์ควรจะบรรทุก ซึ่งถูกนำไปใช้ในไคลเอนต์ ในระบบปฏิบัติการ หรือบนเกตเวย์ ชั้นใดบังคับใช้ก็กำหนดขอบเขตของมันด้วย และกฎในชั้นหนึ่งไม่ครอบคลุมอีกชั้นหนึ่ง กฎบนเกตเวย์ไม่อาจปกป้องแล็ปท็อปที่ย้ายไปเครือข่ายอื่นแล้ว
แต่ละผลลัพธ์เป็นอย่างไร
นโยบายเดียวกันอาจทำงานต่างกันมากตามความล้มเหลวที่คุณพบ ดังนั้นจงเปรียบเทียบเหตุการณ์ไม่ใช่ป้าย
| Event | Fail-open result | Fail-closed result |
|---|---|---|
| Tunnel drops while a transfer runs | Transfer continues on the direct path | Transfer stalls until the tunnel returns |
| Client exits or crashes | Rules disappear with the process | Rules persist only if the OS owns them |
| Device boots before sign-in | Normal network access | Blocked until the VPN connects |
| Captive portal needed | Portal loads normally | Portal unreachable without an exception |
| IPv6 not carried by the tunnel | IPv6 traffic leaks directly | Leaks too, unless the block covers IPv6 |
แถวสุดท้ายคือแถวที่จับคนที่คิดว่า kill switch เป็นสวิตช์เดียว กฎที่เขียนสำหรับตารางเส้นทาง IPv4 ปล่อยเส้นทางเริ่มต้น IPv6 ไว้ไม่แตะต้อง และแอปพลิเคชันอาจใช้มันอย่างสบายใจ
ขอบเขตเป็นตัวตัดสินว่ารั่วหรือไม่
ถามว่านโยบายครอบคลุมอะไรก่อนถามว่าเป็นโหมดไหน กฎต่อแอปพลิเคชันปกป้องแอปเดียวและไม่มีอะไรอื่น กฎทั้งอุปกรณ์ปกป้องทุกอย่างยกเว้นข้อยกเว้น และกฎบนเกตเวย์ปกป้องเฉพาะทราฟฟิกที่ไปถึงเกตเวย์นั้น DNS ต้องมีการตัดสินใจของตัวเอง เพราะคำถามที่ส่งไปยังตัวแก้ไขในเครื่องอาจเปิดเผยชื่อได้แม้เพย์โหลดถูกบล็อก
ข้อยกเว้นเครือข่ายท้องถิ่นมีไว้สำหรับเครื่องพิมพ์ การแคสต์ และพอร์ทัลรับรอง และแต่ละอย่างคือรูโหว่ในการบล็อก จดบันทึกไว้ข้างนโยบาย เพราะคนที่รับช่วงการกำหนดค่าจะอ่าน fail-closed ว่าเป็นเรื่องสัมบูรณ์
การเชื่อมต่อใหม่และการบล็อกก็เป็นกลไกควบคุมแยกกัน ไคลเอนต์สามารถเชื่อมต่อใหม่โดยอัตโนมัติโดยไม่เคยบล็อก หรือบล็อกโดยไม่เชื่อมต่อใหม่ และการรวมกันเป็นตัวกำหนดว่าผู้ใช้ประสบอะไรระหว่างเหตุขัดข้อง
พิสูจน์ในช่วงการเปลี่ยนผ่าน
การทดสอบสภาวะคงที่ไม่ได้พิสูจน์อะไร จงตัดอุโมงค์ลงโดยเจตนาและลองแอปพลิเคชันที่ควรได้รับการปกป้อง แล้วตรวจว่ามันไปถึงเครือข่ายหรือไม่ เปรียบเทียบตัวบ่งชี้ของไคลเอนต์กับผลลัพธ์ เพราะตัวบ่งชี้ที่ยังบอกว่าเชื่อมต่ออยู่คือกรณีที่แน่นอนที่นโยบายนี้มีไว้สำหรับ ถ้าแอปที่ได้รับการปกป้องสำเร็จ ชื่อโหมดไม่สำคัญ คุณมีรอยรั่ว
ทำซ้ำจากการบูตเย็นก่อนลงชื่อเข้าใช้ เมื่อเปลี่ยนจาก Wi-Fi เป็นเครือข่ายมือถือ และโดยให้แอปที่ได้รับการปกป้องอยู่เบื้องหลัง ถ้ากระบวนการของไคลเอนต์เป็นผู้บังคับใช้การบล็อก จงทดสอบด้วยว่าเกิดอะไรขึ้นเมื่อกระบวนการนั้นถูกฆ่าแทนที่จะปิดอย่างเรียบร้อย
สุดท้าย ตรวจเส้นทางการล้างข้อมูล หากถอนการติดตั้งไคลเอนต์ขณะที่กฎยังทำงานอยู่ ให้ใช้ขั้นตอนการลบที่ผู้ขายจัดทำไว้ แทนที่จะปิดไฟร์วอลล์ของระบบปฏิบัติการ ซึ่งจะลบการป้องกันที่ไม่เกี่ยวข้องโดยไม่ตอบว่าใครเป็นเจ้าของกฎที่เหลืออยู่