Always-on VPN กับ kill switch: คุณเปิดอะไรจริง ๆ

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

ข้อตรวจ 1: การบล็อกเป็นสวิตช์ของมันเองหรือไม่

บน Android 10 และใหม่กว่า โปรไฟล์ VPN ที่บันทึกไว้เปิดสวิตช์อิสระสองตัวหลังไอคอนเฟือง: Always-on VPN และ Block connections without VPN มีเพียงตัวที่สองที่เป็น kill switch เมื่อมีแต่ always-on อุโมงค์จะกลับมาหลังการตัดจริง และแอปใดที่อยู่ระหว่างคำขอสามารถเข้าถึงเครือข่ายผ่าน Wi-Fi หรือข้อมูลมือถือได้จนกว่าจะเกิด

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

อ่านสถานะจากอุปกรณ์ ไม่ใช่จากคอนโซล: adb shell settings get global always_on_vpn_app และ adb shell settings get global always_on_vpn_lockdown ถ้าตัวแรกคืน null แสดงว่าไม่มีแพ็กเกจใดถูกบังคับที่ระดับแพลตฟอร์ม ถ้าตัวที่สองคืน 0 แพลตฟอร์มไม่ได้บล็อกอะไรเลย คู่มือ VPN ของ Android อธิบายสิ่งเหล่านี้เป็นความสามารถแยก ไม่ใช่โหมดเดียว

ข้อตรวจ 2: การบล็อกเป็นของชั้นไหน

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

Windows เป็นตัวอย่างชัดที่สุดของป้ายที่ไม่บล็อก ที่นั่น Always On อธิบายความคงอยู่ของอุโมงค์: อุโมงค์อุปกรณ์สำหรับการพิสูจน์ตัวตนเครื่อง และอุโมงค์ผู้ใช้สำหรับบัญชีที่ลงชื่อเข้า ตั้งผ่าน XML ของโปรไฟล์หรือ Add-VpnConnection ไม่มีสิ่งใดในโปรไฟล์นั้นหยุดแพ็กเก็ตขาออกเมื่อไม่มีอุโมงค์ และการกรองขาออกไม่ได้เปิดโดยปริยาย เครื่องพกพาบน Wi-Fi จึงยังทำงานได้ขณะ VPN ล่ม

WireGuard ก็แยกแบบเดียวกัน แต่แยกตามไคลเอนต์ WireGuard for Windows มีตัวเลือก Block untunneled traffic ต่ออุโมงค์ซึ่งติดตั้งกฎการกรอง เครื่องมือฝั่ง Linux ไม่มีสวิตช์เทียบเท่า wg-quick เพิ่มเส้นทางสำหรับแต่ละรายการ AllowedIPs พร้อมกฎ fwmark และ wg-quick down ลบทั้งสองออก เส้นทางปริยายทางกายภาพจึงกลับมารับงานอีกครั้งโดยไม่มีแพ็กเก็ตตกหล่น

บนแพลตฟอร์ม Apple always-on มาในรูปฟีเจอร์โปรไฟล์การจัดการสำหรับอุปกรณ์ที่ถูกกำกับดูแล และแสดงออกเป็นกฎ on-demand ไม่ใช่ช่องทำเครื่องหมาย คำถามที่ต้องตอบจากเพย์โหลดคืออุโมงค์ที่ล้มเหลวปฏิเสธทราฟฟิกหรือเพียงขอการเชื่อมต่ออื่น ชื่อเมนูจะไม่บอกคุณ

ข้อตรวจ 3: วัดช่องว่าง ไม่ใช่วัดไอคอน

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

การทดสอบที่ถูกที่สุดหยุดอุโมงค์โดยเจตนาแล้วลองออก ขณะอุโมงค์ล่ม curl -m 5 -sS -o /dev/null -w '%{http_code}' https://example.com ที่คืน 200 หมายความว่านโยบายเป็น fail-open การหมดเวลาหรือการเชื่อมต่อถูกปฏิเสธหมายความว่ายังมีบางอย่างบล็อกอยู่ ip route get 1.1.1.1 ระบุอินเทอร์เฟซที่จะพาแพ็กเก็ตไป ซึ่งมักให้ข้อมูลมากกว่าไอคอนในถาด และ systemctl status wg-quick@wg0 แสดงว่าอินเทอร์เฟซถูกลบอย่างสะอาดหรือไม่

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

ข้อตรวจ 4: ตัดสินข้อยกเว้นก่อนล็อก

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

รูปแบบน้อยที่สุด อนุญาตปลายทางและทิ้งอย่างอื่นทั้งหมด:

table inet vpnlock {
  chain output {
    type filter hook output priority 0; policy drop;
    oifname "lo" accept
    ip daddr 203.0.113.10 udp dport 51820 accept
    oifname "wg0" accept
  }
}

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

ข้อตรวจ 5: บันทึกสิ่งที่พิสูจน์ได้จริง

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

ก่อนจะเรียกว่าเสร็จ:

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