เส้นทางถาวรสำหรับ VPN บน Mac: networksetup หรือ hook การเชื่อมต่อ?

เส้นทางที่พิมพ์ใหม่หลังทุกการเชื่อมต่อแก้ปัญหาเฉพาะหน้า ไม่ใช่ทั้งสัปดาห์ บน macOS ตัวเลือกถาวรมักเป็นคำนำหน้าที่เก็บไว้กับบริการ VPN เพราะบริการจะติดตั้งใหม่ทุกครั้งที่เชื่อมต่อและลบออกเมื่อบริการปิดอยู่ ทางเลือกอื่นคือ route add ชั่วคราวสำหรับการทดสอบ และ hook การเชื่อมต่อสำหรับที่อยู่ที่รู้จักหลังการเจรจาเท่านั้น

ตัดสินใจว่าเส้นทางเป็นของบริการหรือของเซสชัน

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

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

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

อ่านสถานะเส้นทางและบริการปัจจุบัน

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

scutil --nc list
networksetup -listnetworkserviceorder
netstat -rn | head -30
route get 10.20.5.5

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

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

เก็บคำนำหน้าด้วย networksetup

เครื่องมือ networksetup แนบเส้นทางเพิ่มเติมกับบริการเครือข่าย สำหรับบริการชื่อ OfficeVPN และคำนำหน้าส่วนตัวที่เข้าถึงผ่าน peers ของอุโมงค์ รูปแบบคือ:

sudo networksetup -setadditionalroutes OfficeVPN 10.20.0.0 255.255.0.0 10.8.0.6
networksetup -getadditionalroutes OfficeVPN

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

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

ใช้ route add สำหรับการทดสอบเท่านั้น

เส้นทางตรงมีประโยชน์ในการพิสูจน์ว่าคำนำหน้าทำงานก่อนทำให้ถาวร รูปแบบอินเทอร์เฟซหลีกเลี่ยงการค้นหาเกตเวย์:

sudo route -n add -net 10.20.0.0/16 -interface utun4

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

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

เลือก hook เฉพาะเมื่อมีการเจรจาที่อยู่

สำหรับลิงก์ที่ใช้ PPP เช่น L2TP macOS จะรัน /etc/ppp/ip-up เมื่อลิงก์ถูกสร้าง สคริปต์ได้รับชื่ออินเทอร์เฟซและที่อยู่ภายในและระยะไกลที่เจรจาแล้ว จึงสามารถเพิ่มเส้นทางที่ขึ้นอยู่กับ peers ที่เซิร์ฟเวอร์กำหนด นี่คือกรณีที่เส้นทางบริการแบบคงที่ไม่สามารถแสดงออกได้

IKEv2 และไคลเอนต์ของผู้จำหน่ายอาจไม่ใช้เส้นทาง PPP นั้นเลย ซึ่งหมายความว่าสคริปต์อาจเงียบตลอดเซสชัน เมื่อเป็นเช่นนั้น งาน launchd ที่สอบถาม scutil --nc status และตอบสนองต่อการเปลี่ยนแปลงสถานะคือกลไกที่เทียบเท่า โดยมีความหน่วงเล็กน้อย

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

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