สคริปต์ดาวน์หรือกฎไฟร์วอลล์: อะไรหยุดการรั่วไหล?
การลดอินเทอร์เฟซลงตอนตัดการเชื่อมต่อเป็นวิธีหยาบและมักทำงานโดยไม่มีสิทธิ์ เปรียบเทียบกับกฎไฟร์วอลล์ที่อยู่รอดหลังการหลุดและปิดช่องโหว่
สองดีไซน์สัญญาสิ่งเดียวกัน: เมื่ออุโมงค์ล่ม ไม่มีอะไรออกไปข้างนอกในรูปแบบเปิดเผย ตัวหนึ่งรันสคริปต์ตอนรื้อถอนและตัดอินเทอร์เฟซ อีกตัวปล่อยกฎไฟร์วอลล์ไว้และไม่ขออะไรจากไคลเอนต์ VPN เลย ทั้งสองต่างกันที่ใครมีสิทธิ์ลงมือ อะไรเกิดขึ้นระหว่างช่องว่าง และเครื่องกลับมาออนไลน์อีกครั้งได้อย่างไรในภายหลัง การเปรียบเทียบทั้งสองในสามจุดนั้นมีประโยชน์กว่าการเถียงว่าอันไหนเข้มงวดกว่า
งานเดียวกันด้วยสองกลไก
ไคลเอนต์สามารถรันฮุกเมื่ออุโมงค์ขึ้นและเมื่อถูกรื้อถอน หากโปรไฟล์อนุญาตให้รันสคริปต์ ฮุกนั้นทำงานภายในวงจรชีวิตของไคลเอนต์ ในขณะที่การเชื่อมต่อกำลังปิด ส่วนกฎไฟร์วอลล์นั้นเป็นของระบบและไม่สนใจว่าไคลเอนต์กำลังทำงาน ล่มไป หรือถูกฆ่า
| Property | Teardown script | Firewall unit |
|---|---|---|
| Runs when the client is killed | No | Yes |
| Needs privilege at teardown time | Usually yes | Configured once, at boot |
| Acts on the whole machine | Often, including recovery paths | Only on the flows it matches |
ตารางนั้นคือข้อโต้แย้งทั้งหมด สคริปต์ที่รันเฉพาะตอนปิดอย่างเรียบร้อยครอบคลุมกรณีที่คุณกังวลน้อยที่สุด กรณีที่สำคัญคือการล่มหรือเครือข่ายหายไป และทั้งสองไม่ได้ให้การรื้อถอนที่สะอาด
ฮุกตอนรื้อถอนทำอะไรได้และทำอะไรไม่ได้
รูปแบบที่บันทึกไว้ไล่ผ่านอินเทอร์เฟซเครือข่ายและปิดทุกอย่างยกเว้น loopback เมื่ออุปกรณ์กายภาพถูกปิดลง ไม่มีอะไรหลุดออกนอกอุโมงค์ได้ ซึ่งเป็นเจตนาพอดี
#!/bin/sh
for dev in /sys/class/net/*; do
name=$(basename "$dev")
[ "$name" = lo ] || ip link set dev "$name" down
doneมันยังปิดเครือข่ายท้องถิ่น บริการใดที่เครื่องให้บริการ และเส้นทางที่คุณจะใช้แก้ปัญหา บนแล็ปท็อปอุปกรณ์ไร้สายบางครั้งต้องสลับด้วยมือในภายหลัง การหยุดชะงักสั้น ๆ จึงกลายเป็นการซ่อมบำรุงหนึ่งรอบ ที่แย่กว่านั้น ฮุกอาจไม่ได้รับอนุญาตให้ทำอะไรเลย: เมื่อไคลเอนต์สละสิทธิ์ สคริปต์รื้อถอนจะรันภายใต้บัญชีที่ไม่มีสิทธิ์ และการเปลี่ยนอินเทอร์เฟซทุกครั้งล้มเหลวด้วยข้อผิดพลาดเรื่องสิทธิ์ที่ถูกเขียนในจังหวะที่ไม่มีใครอ่านบันทึก
ตรวจสอบว่าไคลเอนต์เริ่มทำงานอย่างไรก่อนจะเชื่อฮุก สคริปต์ที่ใช้ได้เมื่อรันด้วยมือในฐานะ root ไม่ได้พิสูจน์อะไรเกี่ยวกับบริการที่เริ่มตอนบูต
กฎไฟร์วอลล์ทำอะไรต่างออกไป
กฎที่อนุญาตเฉพาะทราฟฟิกของอุโมงค์ยังทำงานต่อไปเมื่อโปรเซสของไคลเอนต์หายไป เพราะเคอร์เนลไม่ได้ขึ้นกับโปรเซสนั้น กฎยังแคบกว่า: บล็อกเฉพาะโฟลว์ที่ตรงกันและปล่อย loopback ซับเน็ตท้องถิ่นและเส้นทางกู้คืนไว้ตามลำพัง จึงไม่ทิ้งเครื่องให้ตัน
ราคาที่ต้องจ่ายคือกฎต้องถูกเขียนและดูแลโดยเจ้าของไฟร์วอลล์ของโฮสต์ และมันต้อง ระบุชื่ออุปกรณ์อุโมงค์ที่ไคลเอนต์สร้างขึ้นจริง นั่นหมายความว่ากฎและโปรไฟล์ต้องดูแลไปด้วยกัน อินเทอร์เฟซที่ถูกเปลี่ยนชื่อจะทิ้งไฟร์วอลล์ที่บล็อกทุกอย่างและไม่อธิบายอะไรเลย
ไม่มีกลไกใดทำให้อีกกลไกหนึ่งเกินจำเป็น กฎไฟร์วอลล์ที่ไม่เคยถูกโหลดใหม่หลังแก้ไขนั้นเป็นเรื่องสมมติพอ ๆ กับสคริปต์ที่ไม่เคยรัน
persist-tun เป็นตัวตัดสินว่ามีช่องว่างหรือไม่
เมื่ออุปกรณ์อุโมงค์อยู่รอดหลังการตัดการเชื่อมต่อ เส้นทางที่ชี้เข้าไปก็อยู่รอดด้วย ทราฟฟิกจึงถูกทิ้งแทนที่จะถูกเปลี่ยนเส้นทาง ดังนั้นเส้นทางเริ่มต้นไม่ตกลงกลับไปยังเกตเวย์กายภาพ นี่คือพฤติกรรมที่ทำให้การรั่วไหลไม่น่าเกิดขึ้นแม้ก่อนที่กฎไฟร์วอลล์ใดจะเข้ามาเกี่ยวข้อง
หากไม่มีค่านี้ อุปกรณ์จะถูกถอดออกพร้อมเส้นทาง และเส้นทางเริ่มต้นอาจชี้กลับไปยังเกตเวย์กายภาพอีกครั้ง จะเป็นเช่นนั้นหรือไม่ขึ้นกับแพลตฟอร์มและไคลเอนต์ และนั่นคือเหตุผลที่ต้องสังเกตสถานะแทนที่จะสันนิษฐาน มองค่านี้เป็นส่วนหนึ่งของ kill switch ไม่ใช่ตัวเลือกด้านประสิทธิภาพ
รักษาเส้นทางเชื่อมต่อใหม่ให้ยังมีชีวิต แล้วทดสอบสี่สถานะ
การบล็อกที่เข้มงวดอาจขัดขวางไคลเอนต์ไม่ให้เชื่อมต่อใหม่ได้เช่นกัน เพราะไคลเอนต์ยังต้องมีเส้นทางไปยังเซิร์ฟเวอร์ผ่านเกตเวย์กายภาพในขณะที่ทุกอย่างอื่นถูกปฏิเสธ ติดตั้งเส้นทางโฮสต์สำหรับที่อยู่เดียว่านั้นก่อนอุโมงค์จะขึ้น และแปลงชื่อก่อน เพราะ DNS อาจถูกบล็อกเมื่อถึงเวลาที่คุณต้องการ
ip route add 198.51.100.20/32 via 192.168.0.1 dev wlan0จากนั้นตรวจสอบสถานะไม่ใช่ป้ายกำกับ ลองสี่ช่วงเวลาอย่างตั้งใจ: การเริ่มเย็นโดยไม่มีอุโมงค์ เซสชันที่สุขภาพดี การหลุดที่ไม่มีใครขอ และเซสชันหลังกู้คืน ในแต่ละช่วงเวลาอ่านเส้นทางเริ่มต้นและส่งคำขอหนึ่งครั้งที่เห็นที่อยู่ขาออก หากแอปพลิเคชันยอมแพ้ขณะอุโมงค์ลง มันไม่ได้บอกอะไรเกี่ยวกับไคลเอนต์อีเมลหรือตัวอัปเดต ดังนั้นทำการตรวจครั้งสุดท้ายซ้ำกับแอปพลิเคชันพื้นหลังหนึ่งตัว จดกฎ ชื่ออินเทอร์เฟซ และขั้นตอนกู้คืนไว้ เพราะ kill switch ที่ไม่มีใครตรวจสอบได้เป็นเพียงข่าวลือ