คิลสวิตช์ของคุณจะบล็อกแอปที่คุณแยกออกจากอุโมงค์หรือไม่

คิลสวิตช์เปิดอยู่ มีแอปหนึ่งถูกแยกออกจากอุโมงค์โดยเจตนา และข้อกำหนดสองข้อตอนนี้ขัดแย้งกัน ข้อหนึ่งบอกว่าไม่มีอะไรออกได้นอกจากผ่านอุโมงค์ อีกข้อบอกว่าโปรแกรมนี้ต้องวิ่งตรง ไคลเอนต์แต่ละตัวแก้ความขัดแย้งนี้ต่างกัน และหน้าการตั้งค่ามักไม่อธิบายว่ากฎใดชนะ เขียนนโยบายรายแอปไว้ก่อนจะเชื่อป้ายใด ๆ

สองนโยบาย หนึ่งเครื่อง

คิลสวิตช์คือคำสัญญาเรื่องความล้มเหลว เมื่ออุโมงค์ไม่ได้ปกป้องทราฟฟิก ทราฟฟิกก็หยุด อุโมงค์แบบแบ่งคือคำสัญญาเรื่องการเลือก โปรแกรมหรือปลายทางเหล่านี้ใช้อุโมงค์ ส่วนพวกนั้นไม่ใช้ คำสัญญาข้อที่สองสร้างทราฟฟิกที่ข้อแรกต้องตัดสินใจ ไม่มีคำสัญญาข้อใดผิด เพียงแต่คนต่างกันเขียนไว้สำหรับภัยคุกคามต่างกัน

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

เขียนรายการแอปก่อนเขียนกฎ

ระบุโปรแกรมที่ต้องใช้อุโมงค์ โปรแกรมที่ต้องวิ่งตรง และชื่อหรือปลายทางที่ต้องไม่ปรากฏในรายการใดเลย รวมพฤติกรรมของตัวแปลงชื่อกับฝั่ง IPv6 แยกไว้ เพราะทั้งสองอาจใช้นโยบายต่างจากทราฟฟิกของหน้าเว็บ

กฎรายแอปมักจับกับไฟล์เรียกทำงานหรือแพ็กเกจ ไม่ใช่โปรไฟล์ที่อยู่ข้างใน โปรไฟล์เบราว์เซอร์ หน้าต่างส่วนตัว และส่วนขยายไม่มีตัวตนเครือข่ายของตัวเอง จึงสืบทอดสิ่งที่โปรเซสได้รับ โปรเซสช่วยที่เบราว์เซอร์นั้นเปิดอาจไม่สืบทอดกฎเดียวกันเลย

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

ไคลเอนต์ทำอะไรระหว่างที่ระบบล่ม

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

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

อ่านพฤติกรรมของระบบปฏิบัติการที่อยู่ตรงหน้าคุณ ไม่ใช่การตั้งค่าชื่อเดียวกันที่อื่น API การบังคับใช้แตกต่างกัน และช่องทำเครื่องหมายหนึ่งช่องอาจหมายถึงสิ่งต่างกันอย่างสิ้นเชิงบนเดสก์ท็อปและบนโทรศัพท์ เวอร์ชันก็สำคัญ เพราะตัวควบคุมการล็อกย้ายระหว่างหน้าจอในแต่ละรุ่นของ Android และรายการข้อยกเว้นฝั่งไคลเอนต์ไม่ใช่ตัวควบคุมเดียวกับการล็อกของแพลตฟอร์ม

สามช่วงเวลา อุโมงค์เปิด อุโมงค์ปิด เชื่อมต่อใหม่

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

curl -sS --max-time 8 https://api.ipify.org
curl -sS --max-time 8 --interface tun0 https://api.ipify.org
dig +short example.com

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

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