tun ที่สร้างไว้ล่วงหน้าใน OpenVPN: เปรียบเทียบสองแบบจำลองความเป็นเจ้าของ

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

ชื่อไม่ใช่การเชื่อมต่อ

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

dev tun1
dev-type tun

อินเทอร์เฟซเครือข่ายและ /dev/net/tun เป็นวัตถุที่ต่างกัน อย่างหนึ่งคือลิงก์ภายในเนมสเปซ อีกอย่างคืออุปกรณ์อักขระที่โปรแกรมในสเปซผู้ใช้ใช้เชื่อมต่อ เอกสาร Linux TUN/TAP อธิบายเส้นทางการเชื่อมต่อนั้นและกฎความเป็นเจ้าของสำหรับอุปกรณ์ถาวร เชลล์ root ที่รัน ip link ได้พิสูจน์เพียงว่าเชลล์มีสิทธิ์ ไม่ใช่เดมอนมี ความเป็นเจ้าของโหนดอุปกรณ์ ชุดความสามารถของบริการ และผู้ใช้ที่มันรันอยู่ ต้องสอดคล้องกันทั้งหมดก่อนการเปิดจะสำเร็จ

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

ใครกำหนดค่าลิงก์: สองแบบจำลองความเป็นเจ้าของ

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

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

ตรวจสอบอุปกรณ์จากเนมสเปซที่มีความหมาย

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

ip -details link show dev tun1
ip tuntap show

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

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

ความคงทนสองชนิด

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

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

อะไรพังเมื่อทดสอบเฉพาะการเริ่มทำงาน

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

systemctl status openvpn-client@lab
ip -details link show dev tun1

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

kill -SIGHUP $(pidof openvpn)
journalctl -u openvpn-client@lab -n 40
systemctl stop openvpn-client@lab
ip -details link show dev tun1

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