แอปต้องไม่ทำงานขณะ VPN เปิดอยู่: อะไรเป็นตัวบังคับ

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

ตำนาน: kill switch ห้ามโปรแกรมเริ่มทำงาน

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

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

ตั้งชื่อโหมดก่อนตั้งชื่อเครื่องมือ

เขียนกฎเป็นเครื่องสถานะสามสถานะ: การใช้งานปกติ เซสชันงาน VPN และการออก การทับซ้อนที่ต้องห้ามเป็นของสถานะกลาง ไม่ใช่ของซอฟต์แวร์ไคลเอนต์

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

ความขัดแย้งสองทางทำอะไรจริง ๆ

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

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

ทดสอบการเปลี่ยนสถานะ ไม่ใช่แค่การเปิดครั้งแรก

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

systemctl show work-vpn.service -p Conflicts -p After
systemctl start work-vpn.service
systemctl is-active office-sync.service
nmcli connection show --active

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

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