OpenVPN เอนจินหรือ Tunnelblick: ใครเป็นเจ้าของเซสชัน VPN บน Mac?

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

ทำการตรวจสอบห้าข้อด้านล่างตามลำดับ ข้อแรกที่มีเจ้าของสองรายคือข้อที่สร้างสถานะกึ่งเชื่อมต่อแปลก ๆ ที่ผู้คนโทษ OpenVPN เอง การตรวจสอบแต่ละข้อระบุหลักฐานที่ตัดสินมัน

การตรวจสอบข้อหนึ่ง: ไบนารี OpenVPN ตัวใดทำงานจริง

รัน pgrep -fl openvpn ขณะเชื่อมต่อและอ่านบรรทัดคำสั่งทั้งหมด เส้นทางแรกคือเอนจินที่ทำงานจริง บน Apple Silicon การติดตั้ง Homebrew มักอยู่ใต้ /opt/homebrew ขณะที่ Mac Intel ใช้ /usr/local และ Tunnelblick รันเอนจินจากภายในชุดแอปพลิเคชันของตัวเอง

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

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

การตรวจสอบข้อสอง: ใครเปลี่ยน DNS และเส้นทาง

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

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

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

การตรวจสอบข้อสาม: ข้อมูลรับรองมาจากไหน

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

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

การตรวจสอบข้อสี่: ใครเริ่ม ดูแล และหยุดกระบวนการ

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

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

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

การตรวจสอบข้อห้า: การส่งมอบได้รับการยืนยันอย่างไร

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

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

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

การแพ็กเกจไม่ได้ตัดสินความเข้ากันได้กับเซิร์ฟเวอร์ ตรวจสอบข้อกำหนดไคลเอนต์ของบริการเอง และเลือกเฉพาะเอนจินเมื่อคุณตั้งใจจะจัดหาการจัดการให้มัน