สวิตช์นิรภัย VPN อยู่รอดหลังรีบูตหรือไม่? วิธีตรวจสอบ

การรีบูตเป็นวิธีที่ผู้คนใช้ทดสอบสวิตช์นิรภัยบ่อยที่สุด และเป็นการทดสอบที่โกหกบ่อยที่สุด ช่องทำเครื่องหมายในไคลเอนต์เป็นเพียงการตั้งค่า สิ่งที่สำคัญคือมีบางอย่างบังคับใช้การบล็อกระหว่างช่วงเวลาที่สแตกเครือข่ายเริ่มทำงานกับช่วงเวลาที่อุโมงค์ถูกสร้างขึ้นจริงหรือไม่ บน Windows สิ่งนั้นมักเป็นตัวกรองใน Windows Filtering Platform บน Linux เป็นชุดกฎที่โหลดโดยยูนิต บน macOS เป็นสมอ pf บน Android เป็นแฟล็กของระบบเองสำหรับโหมดเปิดตลอดและล็อกดาวน์ การจัดวางเหล่านี้ทำงานต่างกันมากตลอดการรีบูต และมีเพียงระดับแพลตฟอร์มเท่านั้นที่อยู่พร้อมก่อนที่ใครจะลงชื่อเข้าใช้ได้

การรีบูตตั้งคำถามแยกกันสามข้อ

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

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

หาวัตถุที่กู้คืนการบล็อก

บน Linux กฎ netfilter อาศัยอยู่ในเคอร์เนล ไม่มีอะไรเขียนกลับตอนบูตเว้นแต่คุณจัดไว้: iptables-save บวก netfilter-persistent، nftables.service โหลด /etc/nftables.conf، หรือยูนิต systemd ที่รันสคริปต์ของคุณเอง ตรวจสอบว่าอะไรถูกเปิดใช้งาน ไม่ใช่สิ่งที่คุณจำได้ว่าตั้งไว้

systemctl is-enabled nftables netfilter-persistent 2>/dev/null
sudo nft list ruleset
sudo iptables -S OUTPUT

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

Get-Service | Where-Object { $_.Name -match 'vpn' } | Select-Object Name, Status, StartType
netsh wfp show state

คำสั่งที่สองเขียน wfpstate.xml ลงไดเรกทอรีปัจจุบัน มองหาตัวกรองที่มีการกระทำแบบบล็อกซึ่งมีอยู่แล้วก่อนที่ไคลเอนต์จะเชื่อมต่อ Base Filtering Engine เริ่มทำงานเร็วตอนบูตและกู้คืนตัวกรองที่เพิ่มด้วยแฟล็กถาวร นั่นคือเหตุผลที่สวิตช์นิรภัยบางตัวบล็อกทราฟฟิกก่อนจะมีหน้าต่างไคลเอนต์ใด ๆ และบางตัวไม่ บน macOS sudo pfctl -s info รายงานว่าเปิด pf อยู่หรือไม่ sudo pfctl -s rules แสดงสิ่งที่โหลดอยู่ และไคลเอนต์ VPN มักผูกกฎเข้ากับสมอแทนชุดหลัก กฎที่ระบุชื่อ utun3 อาจชี้ไปที่อินเทอร์เฟซอื่นหลังบูตครั้งถัดไป เพราะหมายเลขนั้นถูกกำหนดตอนรัน

เฝ้าดูช่องว่างระหว่างเครือข่ายขึ้นกับอุโมงค์ขึ้น

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

บนโฮสต์ systemd ให้อ่านลำดับแทนการเดา รัน systemctl cat บนยูนิต VPN และไฟร์วอลล์ และมองหา After= หรือ Before= เทียบกับ network-pre.target และ network-online.target ยูนิตไฟร์วอลล์ที่เรียงลำดับหลัง network-online.target แพ้ให้กับอินเทอร์เฟซ ส่วนตัวที่ถูกต้องการโดยและเรียงลำดับก่อน network-pre.target ชนะ บน Windows คำถามที่เทียบเท่าคือชนิดการเริ่มทำงานของบริการและ dependencies เพราะบริการที่ตั้งเป็น Manual ไม่สามารถบล็อกโปรเซสตอนบูตได้ หากข้อกำหนดของคุณรวมทราฟฟิกก่อนลงชื่อเข้าใช้ มีเพียงการจัดวางระดับอุปกรณ์เท่านั้นที่ตอบสนองได้ คืออุโมงค์อุปกรณ์ Always On VPN ตรวจสอบสิทธิ์ด้วยใบรับรองเครื่องและเชื่อมต่อก่อนผู้ใช้ลงชื่อเข้าใช้ และ Microsoft จัดทำเอกสารการกำหนดค่าอุโมงค์อุปกรณ์ แยกจากอุโมงค์ผู้ใช้ Android ไปอีกทางหนึ่ง บังคับใช้ VPN แบบเปิดตลอดและบล็อกการเชื่อมต่อที่ไม่มีจากระบบ ไม่ใช่จากโปรเซสแอปพลิเคชัน

รันการทดสอบ แล้วเปรียบเทียบไทม์ไลน์สองเส้น

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

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

ปิดช่องว่างโดยไม่ตัดทางกลับของคุณ

หากไม่มีการบล็อกตอนบูต ให้เลื่อนการบังคับใช้ลงหนึ่งชั้นแทนการเพิ่มกฎไคลเอนต์ตัวที่สอง บันทึกชุดกฎและโหลดจากยูนิตที่เรียงลำดับก่อนเครือข่ายใช้งานได้ และตรวจสอบว่ายูนิตนั้นไม่ต้องใช้การค้นหา DNS หรือเมานต์เครือข่ายที่มันควรจะปกป้อง ขอบเขตสำคัญพอ ๆ กับเวลา กฎที่จับคู่กับ ID ผู้ใช้หรือ cgroup ปล่อยให้ดีมอนของระบบทุกตัวอยู่นอกการบล็อก และชุดกฎที่จัดการเฉพาะ IPv4 ปล่อยให้ IPv6 และ DNS เข้าถึงได้

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

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