OpenVPN TAP บน macOS: ตรวจสอบไคลเอนต์ก่อนแก้ไขข้อบกพร่อง
TAP บรรทุกเฟรม Ethernet และ TUN บรรทุก IP และไคลเอนต์ macOS ปัจจุบันส่วนใหญ่ได้ทิ้งอย่างแรกไปแล้ว ยืนยันโหมด แล้วย้ายร่วมกับเจ้าของเซิร์ฟเวอร์
โปรไฟล์เก่าไปอยู่บน Mac รุ่นใหม่ ไคลเอนต์นำเข้าได้โดยไม่มีข้อโต้แย้ง และการเชื่อมต่อก็หลุดหรือไม่ส่งทราฟฟิกเลย ก่อนจะเสียเวลาทั้งบ่ายกับใบรับรอง อ่านบรรทัดอุปกรณ์ในโปรไฟล์ ถ้าเขียนว่า dev tap แสดงว่าคุณกำลังขออินเทอร์เฟซแบบ Ethernet จากไคลเอนต์ และบน macOS เซสชันแบบนี้ส่วนใหญ่จบลงที่คำขอนั้น
ขั้นตอนที่ 1: ยืนยันว่าโปรไฟล์ขอ TAP จริง
โปรไฟล์ถูกเปลี่ยนชื่อ ห่อ และส่งออกใหม่ ดังนั้นตรวจไฟล์ที่คุณนำเข้าจริง ค้นหาคำสั่งอุปกรณ์และ include ใดก็ตามที่อาจเขียนทับมัน ในกรณีส่วนใหญ่ผลลัพธ์สองบรรทัดก็ตัดสินคำถามได้ เมื่อมีทั้ง dev และ dev-type คำสั่งที่มาทีหลังจะเป็นฝ่ายชนะ และนั่นคือรายละเอียดแบบที่โปรไฟล์ที่คัดลอกมาซ่อนไว้
grep -nE "^[[:space:]]*(dev|dev-type)[[:space:]]" client.ovpn
ls -l ~/Library/Application\ Support/ 2>/dev/null
ถ้าไฟล์มี dev tap หรือ dev tap0 ไคลเอนต์ต้องมีอินเทอร์เฟซ TAP ถ้ามี dev tun เนื้อหาที่เหลือของบทความนี้ใช้ไม่ได้ และปัญหาอยู่ที่อื่น
จดชื่อและเวอร์ชันของไคลเอนต์ เวอร์ชัน macOS และที่มาของโปรไฟล์ ข้อเท็จจริงสามข้อนี้กำหนดว่าเส้นทางใดในสองเส้นทางด้านล่างเป็นไปได้ตั้งแต่แรก
ขั้นตอนที่ 2: รู้ว่าโหมดอุปกรณ์เปลี่ยนอะไรจริง
อินเทอร์เฟซ TUN บรรทุกแพ็กเก็ต IP ไคลเอนต์อ่านและเขียนแพ็กเก็ตที่ส่งถึงคู่ IP และระบบปฏิบัติการก็กำหนดเส้นทางให้เหมือนอินเทอร์เฟซอื่น
อินเทอร์เฟซ TAP บรรทุกเฟรม Ethernet รวมถึงการออกอากาศและ ARP นี่คือสิ่งที่ทำให้เซิร์ฟเวอร์ที่ทำบริดจ์แจกจ่ายที่อยู่ผ่าน DHCP และให้ไคลเอนต์ค้นหาอุปกรณ์ด้วยการตะโกน และนั่นคือเหตุผลที่การออกแบบเก่าบางแบบพึ่งพามัน
ราคาที่ต้องจ่ายคือ TAP ต้องมีไดรเวอร์ที่นำเสนออินเทอร์เฟซ Ethernet ให้ระบบ Apple ยกเลิกโมเดลส่วนขยายเคอร์เนลที่ไดรเวอร์ TAP รุ่นเก่าของ Mac พึ่งพา และ API แทนของมันไม่ได้ปรากฏขึ้นราวกับเวทมนตร์ในไคลเอนต์ที่ไม่เคยอัปเดตให้ใช้ ความสามารถของแพลตฟอร์มกับผลิตภัณฑ์ที่ส่งมอบแล้วเป็นคนละเรื่อง
ขั้นตอนที่ 3: เลือกระหว่างไคลเอนต์ที่เข้ากันได้กับการย้ายระบบ
มีสองเส้นทางที่ซื่อตรง เส้นทางแรกคือไคลเอนต์ที่ผู้เผยแพร่ระบุสำหรับ macOS และฮาร์ดแวร์ของคุณว่ารองรับการจัดวาง TAP ที่คุณต้องการ ไม่ใช่โพสต์ฟอรัมเมื่อสี่ปีก่อน และไม่ใช่ตัวติดตั้งที่เก็บถาวร แต่เป็นถ้อยแถลงปัจจุบันพร้อมการเชื่อมต่อทดสอบ
เส้นทางที่สองคือย้ายบริการไปยัง TUN ซึ่งเป็นการเปลี่ยนแปลงฝั่งเซิร์ฟเวอร์พอ ๆ กับการเปลี่ยนแปลงฝั่งไคลเอนต์ ต้องมีโทโพโลยีแบบกำหนดเส้นทาง พูลที่อยู่ เส้นทางที่พุชให้เครือข่ายระยะไกล และเส้นทางกลับจากเครือข่ายเหล่านั้นมายังพูล
สิ่งที่ไม่ทำงานคือแก้ tap เป็น tun ในสำเนาเครื่องของคุณแล้วหวัง เซิร์ฟเวอร์ยังทำบริดจ์อยู่ ไคลเอนต์พูด IP แล้ว และไม่มีอะไรตรงกัน
ขั้นตอนที่ 4: เก็บข้อเท็จจริงก่อนเปลี่ยนบริการที่ทำงานอยู่
เก็บโปรไฟล์ต้นฉบับไว้ไม่แตะต้อง และทำสำเนาสำหรับทดลอง ไฟล์ที่กู้คืนได้ในหนึ่งนาทีมีค่ามากกว่าโฟลเดอร์ที่เป็นระเบียบ เมื่อตัวแทนทำงานได้ ให้ลบสำเนาอย่างตั้งใจแทนที่จะเหลือโปรไฟล์สองอันที่ดูเหมือนกันในรายการ นิสัยข้อเดียวนี้ป้องกันความสับสนส่วนใหญ่หลังการย้ายระบบล้มเหลว บันทึกพฤติกรรมปัจจุบันเพื่อพิสูจน์ว่าเกิดอะไรขึ้น: อุโมงค์ขึ้นหรือไม่ ได้ที่อยู่หรือไม่ เข้าถึงโฮสต์ที่รู้จักได้หรือไม่ และการแปลงชื่อทำงานหรือไม่
ถามเจ้าของเกตเวย์สามคำถาม เซิร์ฟเวอร์ทำงานบนโทโพโลยีแบบบริดจ์หรือแบบกำหนดเส้นทาง พรีฟิกซ์ระยะไกลใดที่ควรเข้าถึงได้ และมีช่วงเวลาบำรุงรักษาสำหรับการเปลี่ยนการกำหนดค่าหรือไม่ หรือคาดว่าจะทำงานได้โดยไม่ต้องแตะเซิร์ฟเวอร์
คำตอบของสิ่งเหล่านี้กำหนดว่าคุณกำลังแก้ปัญหาไคลเอนต์ในบ่ายนี้ หรือวางแผนเปลี่ยนเครือข่ายสัปดาห์หน้า
ขั้นตอนที่ 5: ตรวจสอบการย้ายระบบจากทั้งสองด้าน
เมื่อเซิร์ฟเวอร์มีการกำหนดค่าแบบกำหนดเส้นทางและคุณมีโปรไฟล์ที่เข้ากัน ให้ทดสอบตามลำดับนี้: อุโมงค์ถูกสร้างขึ้น ไคลเอนต์ได้รับที่อยู่จากพูลใหม่ โฮสต์ฝั่งไกลตอบกลับ และชื่อถูกแปลงผ่านการตั้งค่า DNS ที่พุชไป
จากนั้นทดสอบสิ่งที่เคยพึ่งพาพฤติกรรม Ethernet ถ้าแอปค้นหาอุปกรณ์ด้วยการออกอากาศ มันจะไม่พบผ่านอุโมงค์แบบกำหนดเส้นทาง และการกำหนดค่าไคลเอนต์เท่าไรก็ไม่ทำให้กลับมา แอปนั้นต้องมีที่อยู่ที่รู้จัก โฮสต์ช่วยเหลือในเครื่อง หรือวิธีค้นหาอื่น
ปิดท้ายด้วยการเชื่อมต่อใหม่และรีบูตหนึ่งครั้ง เพราะโปรไฟล์ที่ทำงานเฉพาะครั้งแรกมักหมายความว่าเส้นทางที่พุชหรือการตั้งค่า DNS ไม่ถูกนำไปใช้เมื่อเชื่อมต่อใหม่
เมื่อยังล้มเหลว ให้อ่านข้อผิดพลาดแรก
ไคลเอนต์ที่ไม่สามารถสร้างอินเทอร์เฟซได้จะบอกในบันทึกของมัน มักอยู่ในบรรทัดแรก ๆ ไคลเอนต์ที่สร้างได้แล้วแต่ยืนยันตัวตนไม่ผ่านนั้นผ่านคำถามเรื่องอุปกรณ์ไปนานแล้ว และการไล่ตาม TAP ต่อไปก็เสียเซสชันเปล่า
เก็บโปรไฟล์ต้นฉบับและการกำหนดค่าที่ทำงานไว้จนกว่าตัวแทนจะได้รับการพิสูจน์ การย้อนการเปลี่ยนแปลงไคลเอนต์นั้นเร็ว แต่การสร้างเครือข่ายแบบบริดจ์ที่ใครบางคนรื้อออกตามการคาดเดาไม่เร็ว