สถานะ VPN บน macOS จาก terminal: scutil, เส้นทาง หรือ ping
สถานะของบริการ เส้นทางใน kernel และคำขอจริงตอบคำถามที่แตกต่างกันสามข้อ เขียนสคริปต์ตามตัวระบุบริการและตรวจสอบเส้นทางด้วย
ที่ใดที่หนึ่งในสคริปต์ปรับใช้มีการตรวจสอบว่าอุโมงค์ทำงานอยู่หรือไม่ก่อนการคัดลอกจะเริ่ม มีคำตอบสามแบบที่ใช้ได้ และมันไม่ได้หมายความอย่างเดียวกัน: สถานะบริการที่ scutil รายงาน เส้นทางที่ kernel เลือก และอีกฝั่งตอบกลับจริงหรือไม่ การเปรียบเทียบทั้งสามคือความแตกต่างระหว่างการตรวจสอบที่ทำนายการคัดลอกได้กับการตรวจสอบที่เพียงตกแต่งบันทึก
สามคำตอบสำหรับคำถามว่า VPN ทำงานอยู่หรือไม่
สถานะบริการเป็นข้อเท็จจริงของระนาบควบคุม macOS รู้ว่าการกำหนดค่าเชื่อมต่ออยู่เพราะกระบวนการไคลเอนต์ของมันบอกเช่นนั้น เส้นทางเป็นข้อเท็จจริงของระนาบข้อมูล: kernel จะส่งปลายทางนี้ผ่านอินเทอร์เฟซนั้น การเข้าถึงได้เป็นข้อเท็จจริงจากต้นทางถึงปลายทาง และอาจล้มเหลวด้วยเหตุผลที่อีกสองอย่างมองไม่เห็น
| Signal | Answers | Blind spot |
|---|---|---|
scutil --nc status | Is the service connected? | Third-party clients, wrong routes |
route -n get | Where would this go? | The peer may be down |
| A request to the far side | Does it work now? | Slow, and it changes state |
การตรวจสอบที่มีประโยชน์รวมสองอย่างแรกเข้าด้วยกันและใช้อย่างที่สามเป็นคำยืนยันว่าอีกสองอย่างไม่ได้โกหก อย่างใดอย่างหนึ่งเดี่ยว ๆ เป็นเพียงการคาดเดาพร้อมตราเวลา
อ่านตัวระบุ ไม่ใช่ชื่อที่แสดง
scutil --nc list
scutil --nc status "Office"รายการพิมพ์หนึ่งบรรทัดต่อบริการ และแต่ละบรรทัดมีสถานะในวงเล็บ ตามด้วยตัวระบุบริการ ชนิด และชื่อที่แสดง เขียนสคริปต์ตามตัวระบุ เพราะชื่อที่แสดงคือสิ่งที่ใครบางคนพิมพ์ในระบบตั้งค่าและเปลี่ยนได้โดยไม่แจ้งล่วงหน้า คำสั่งสถานะพิมพ์คำเดียว และสำหรับบริการบางชนิดมีสถิติต่อท้าย เปรียบเทียบคำแรกนั้นแทนการค้นหาชื่อในผลลัพธ์ทั้งหมด ซึ่งปรากฏที่อื่นด้วย
การเริ่มบริการอาจเรียกให้ยืนยันสิทธิ์หรือถูกปฏิเสธทันทีเมื่อโปรไฟล์ถูกจัดการ. การปฏิเสธนั้นไม่ใช่ข้อบกพร่องของอุโมงค์ มันคือถ้อยแถลงนโยบายว่าใครมีสิทธิ์ยกมันขึ้น
ไคลเอนต์จากบุคคลที่สามซ่อนจากรายการ
รายการว่างไม่ได้หมายความว่าไม่มี VPN การกำหนดค่าที่สร้างในระบบเครือข่ายของระบบเองจะแสดงที่นี่ ไคลเอนต์จากผู้จำหน่าย โปรไฟล์การจัดการ หรือแอปจากบุคคลที่สามอาจถืออุโมงค์ที่ทำงานอยู่ซึ่งคำสั่งนี้ไม่เคยเห็น เครื่องมือของมันเองคือผู้มีอำนาจสำหรับบริการของมันเอง การถาม scutil เกี่ยวกับไคลเอนต์ที่ไม่เคยลงทะเบียนกับมันจะได้ผลลัพธ์ว่างเปล่า และความว่างเปล่าไม่ใช่คำตอบเดียวกับตัดการเชื่อมต่อ
เมื่อรายการว่างแต่การรับส่งข้อมูลถูกเข้ารหัสอย่างชัดเจน ให้มองหาอินเทอร์เฟซ: อุปกรณ์ utun หรือ ppp ที่มีที่อยู่ในช่วงที่คาดไว้เป็นหลักฐานว่ามีบางสิ่งสร้างอุโมงค์ขึ้น สัญญาณนี้อ่อนกว่าสถานะบริการ จึงควรจับคู่กับการตรวจสอบเส้นทางแทนที่จะถืออินเทอร์เฟซเป็นหลักฐานยืนยันตัวตน ไคลเอนต์หลายตัวสร้างอินเทอร์เฟซเช่นนี้ได้หลายอัน และมีเพียงอันเดียวที่เป็นของอุโมงค์ที่คุณหมายถึง
สถานะไม่ใช่การกำหนดเส้นทาง
บริการที่เชื่อมต่ออยู่บอกว่าอุโมงค์มีอยู่ ไม่ได้บอกว่าปลายทางของคุณใช้มัน อ่านที่อยู่ แล้วถาม kernel โดยตรง:
ifconfig | grep -A4 utun
netstat -rn -f inet
route -n get 10.40.0.20ไคลเอนต์อุโมงค์เต็มติดตั้งเส้นทางเริ่มต้นผ่านอุโมงค์ ส่วนไคลเอนต์อุโมงค์แยกติดตั้งคำนำหน้าแบบส่วนตัวที่เฉพาะเจาะจง ทั้งคู่รายงาน Connected และสคริปต์ที่ตรวจเฉพาะสถานะจะวิ่งไปบนเส้นทางผิดอย่างสบายใจ การหยุดอุโมงค์ไม่จำเป็นต้องลบเส้นทางที่ไคลเอนต์อื่นติดตั้งไว้ และนั่นเป็นวิธีหนึ่งที่เครื่องหนึ่งมีทั้งบริการที่เชื่อมต่อและเส้นทางที่ล้าสมัยพร้อมกัน มองที่ปลายทางที่คุณสนใจ ไม่ใช่ตารางเส้นทางทั้งหมด
การตั้งชื่อเป็นปัญหาอีกเรื่องหนึ่ง
เครื่องอื่นเข้าถึง Mac ด้วยชื่อไม่ได้ในขณะที่ที่อยู่ใช้งานได้ และสิ่งนี้ถูกรายงานว่าเป็นความผิดพลาดของ VPN ชื่อโฮสต์ท้องถิ่น ชื่อโฮสต์ และระเบียน DNS เป็นสามสิ่งที่แตกต่างกัน scutil --get LocalHostName แสดงชื่อ Bonjour ส่วน sudo scutil --set HostName mac-office กำหนดชื่อที่ระบบรายงาน
ไม่มีการตั้งค่าใดสร้างระเบียนในโซนสำนักงาน หากโฮสต์อื่นต้องแก้ชื่อผ่าน DNS เจ้าของโซนต้องเพิ่มให้ หรือสคริปต์ควรใช้ที่อยู่แทน การกำหนดชื่อที่มั่นคงทำให้การประกาศสอดคล้องกัน แต่ไม่ได้ทำให้ตัวแก้ชื่อตอบ
บันทึกตัวระบุบริการและรูปแบบเส้นทางที่คาดไว้ด้วยกันในสคริปต์ และตรวจสอบทั้งสองอย่างก่อนการคัดลอก อุโมงค์ที่ทำงานอยู่แต่ถูกกำหนดเส้นทางผิดทิศทางจะล้มเหลวเหมือนไม่มีอุโมงค์เลย และบรรทัดบันทึกที่บอกว่า Connected จะส่งคนถัดไปไปค้นหาผิดที่