ออกหรือตัดการเชื่อมต่อ: ผลลัพธ์ VPN สองแบบที่ต่างกัน

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

เอกสารของไคลเอนต์เป็นที่เดียวที่เชื่อถือได้ในการรู้ว่าอันไหนเป็นอันไหน

สี่การควบคุม อาจมีสี่พฤติกรรม

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

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

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

อ่านสถานะก่อนและหลังแต่ละการกระทำ

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

systemctl status wg-quick@wg0 --no-pager
pgrep -a -f 'openvpn|wireguard|vpnagent'
ip link show | grep -E 'tun|wg'
nft list ruleset | grep -E 'drop|reject' | head -20
scutil --nc list

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

การตัดการเชื่อมต่อด้วยมือไม่ใช่การ crash

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

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

เลือกสถานะที่ใช้ไม่ได้ซึ่งคุณต้องการจริง ๆ

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

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

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