เส้นทาง VPN เพิ่มเติมของ Mac ต้องมีเจ้าของ ไม่ใช่สคริปต์ล็อกอิน
เส้นทางที่เพิ่มครั้งเดียวตอนล็อกอินไม่ใช่นโยบายการเชื่อมต่อใหม่ ให้เจ้าของกับคำนำหน้าฝั่งไกลและตัดสินใจว่าพวกมันปรากฏ เปลี่ยน และหายไปกับการเชื่อมต่อนั้นอย่างไร
การเข้าถึงคำนำหน้าแบบส่วนตัวผ่าน VPN เป็นข้อกำหนดที่มีระยะเวลา: มันคงอยู่ตราบเท่าที่การเชื่อมต่อนั้นใช้งานได้ และสิ้นสุดเมื่อการเชื่อมต่อสิ้นสุด สคริปต์ล็อกอินไม่อาจแสดงสิ่งนั้นได้ เพราะการล็อกอินและการยกอุโมงค์เป็นคนละช่วงเวลา และอุโมงค์ที่มีอยู่ตอนล็อกอินอาจไม่ใช่อุโมงค์ที่รับส่งข้อมูลในอีกหนึ่งนาทีถัดมา การตัดสินใจข้อแรกไม่ใช่จะเรียกใช้คำสั่งใด แต่เป็นว่าองค์ประกอบใดเป็นเจ้าของคำนำหน้านั้น
คำนำหน้าต้องมีเจ้าของ ไม่ใช่ชั่วขณะ
เริ่มจากเขียนข้อกำหนดเป็นประโยคที่มีประธาน: เข้าถึง 10.77.0.0/24 ผ่าน VPN ของสำนักงานตราบเท่าที่การเชื่อมต่อนั้นยังขึ้นอยู่ ประโยคนั้นระบุคำนำหน้า การเชื่อมต่อ และเงื่อนไข และตัดตัวแทนยอดนิยมสองอย่างออกทันที: ฮุกตอนล็อกอินและชื่ออินเทอร์เฟซอย่าง ppp0 หรือ utun2.
ชื่ออินเทอร์เฟซถูกกำหนดตอนรันไทม์และไม่คงที่ระหว่างการเชื่อมต่อใหม่ ฮุกที่ตรงกับชื่อที่เห็นเมื่อสัปดาห์ก่อนจะไม่ทำงานหรือทำงานกับอินเทอร์เฟซของคนอื่น ผลลัพธ์ทั้งสองดูเหมือนบั๊กการกำหนดเส้นทาง ไม่ใช่สมมติฐานที่ล้าสมัยอย่างที่มันเป็น ข้อโต้แย้งเดียวกันใช้กับสคริปต์ใดก็ตามที่ผูกกับชื่อซึ่งมีอยู่เพียงตราบเท่าที่อุโมงค์หนึ่งยังขึ้นอยู่
ใช้แหล่งเจตนาเส้นทางที่รองรับ
เกตเวย์ โปรไฟล์ที่จัดการ หรือกลไกเส้นทางที่มีเอกสารกำกับของไคลเอนต์เจ้าของคือที่ที่เหมาะสม เมื่อกลไกนั้นสามารถแสดงข้อกำหนดได้ จะใช้อันไหนขึ้นกับโปรโตคอลและผู้ให้บริการ และคีย์ไม่ได้เดินทางระหว่างกัน ค่าที่กำหนดค่าโปรไฟล์ OpenVPN จึงไม่ได้บอกอะไรเกี่ยวกับไคลเอนต์ L2TP หรือ IKEv2 แบบเนทีฟ
| Mechanism | Can carry extra prefixes | Who owns the lifetime |
|---|---|---|
| Gateway-pushed routes | Often, if the gateway is configured for it | The connection |
| Managed profile settings | Depends on the client and profile format | The profile |
| Provider tunnel settings | Yes, as included and excluded routes | The provider process |
| Manual command | Yes, once | Nobody |
สำหรับนักพัฒนาอุโมงค์แพ็กเก็ต การตั้งค่าอุโมงค์ IPv4 ของ Apple เปิดเผยเส้นทางที่รวมและที่ยกเว้นอย่างชัดเจน และ IPv6 ก็มีคู่กัน เป็น API ที่ผู้ให้บริการใช้ ไม่ใช่หลักฐานว่าแผง VPN แบบเนทีฟทุกอันเสนอรายการเส้นทางตามอำเภอใจให้ผู้ดูแลระบบ หากชุดค่าผสมปัจจุบันไม่สามารถแสดงคำนำหน้าที่ต้องการได้ ขั้นต่อไปคือเส้นทางการกำหนดค่าที่รองรับจากผู้ให้บริการ ไม่ใช่แอปอื่นที่ติดตั้งโดยหวังว่าจะทำงานได้ดีกว่า
อายุการใช้งานรวมถึงการทำความสะอาด
บางครั้งผู้ช่วยภายนอกจำเป็นจริง ๆ และตอนนั้น «เพิ่มเส้นทาง» เป็นส่วนที่เล็กที่สุดของงาน ผู้ช่วยต้องรู้ว่าตนให้บริการการเชื่อมต่อใดและอินเทอร์เฟซใดที่การเชื่อมต่อนั้นใช้ รอจนสถานะเครือข่ายที่เกี่ยวข้องนิ่ง คงความเป็น idempotent เมื่อรันสองครั้งติดกันและไม่ทำความสะอาดสิ่งใดที่ตัวเองไม่ได้ติดตั้ง
อนุประโยคสุดท้ายคือส่วนที่เจ็บปวด ผู้ช่วยที่ลบทุกเส้นทางที่ตรงกับคำนำหน้าของสำนักงานไม่ช้าก็เร็วจะลบเส้นทางที่ตัวเองไม่ได้เพิ่ม ผลคือระบบขัดข้องและถูกโทษที่ไคลเอนต์ VPN เพราะไคลเอนต์คือส่วนที่ผู้ใช้เห็น การตัดสินใจว่าผู้ช่วยเป็นเจ้าของอะไรก่อนเขียนมันถูกกว่าการอธิบายทีหลังว่าทำไมซับเน็ตภายในจึงหยุดตอบสนอง
การแข่งกันตอนเชื่อมต่อใหม่
ลองนึกถึงการเชื่อมต่อใหม่ที่รวดเร็ว เซสชัน A ล่ม เซสชัน B ขึ้นมาและติดตั้งเส้นทางของตน แล้วการทำความสะอาดที่ล่าช้าของ A ก็ทำงานในที่สุด หากการทำความสะอาดนั้นลบเส้นทางตามคำนำหน้า มันจะพาสถานะที่ถูกต้องของ B ไปด้วย และการเชื่อมต่อที่ทำงานเมื่อวินาทีก่อนก็เปลี่ยนเส้นทางไปที่ว่างเปล่า
นี่คือการแข่งกันเรื่องความเป็นเจ้าของ และการเพิ่มการหน่วงในสคริปต์เพียงเปลี่ยนว่าฝ่ายใดชนะ วิธีแก้คือทำให้การทำความสะอาดขึ้นกับตัวตน: เปรียบเทียบอินเทอร์เฟซและเซสชันที่ผู้ช่วยติดตั้งกับที่ยังใช้ได้อยู่ และลบเฉพาะเมื่อตรงกัน
สิ่งที่ต้องทดสอบ และสิ่งที่เส้นทางทำไม่ได้
การยอมรับต้องครอบคลุมสี่ช่วงเปลี่ยนผ่าน: การเชื่อมต่อครั้งแรก การเชื่อมต่อใหม่บนอินเทอร์เฟซอื่น ความพยายามเชื่อมต่อที่ล้มเหลว และการตัดขาดครั้งสุดท้าย หลังแต่ละครั้ง ให้อ่านเส้นทางที่ระบบเลือกจริงสำหรับที่อยู่ฝั่งไกล ไม่ใช่เส้นทางที่คุณคาดหวัง
route -n get 10.77.0.5
netstat -rn -f inet
รวมกรณีที่ยุ่งยากไว้ในรอบเดียวกัน: IPv6 ในที่ที่จำเป็น คำนำหน้าภายในที่ทับซ้อนกับคำนำหน้าฝั่งไกล และเส้นทางไปยังปลายทางสาธารณะของ VPN เองซึ่งต้องทำงานต่อไปตราบเท่าที่อุโมงค์ยังขึ้นอยู่ จากนั้นเขียนว่าเส้นทางไม่ใช่อะไร มันเลือกแพ็กเก็ต มันไม่ได้ให้สิทธิ์ฝั่งไกลและไม่ได้สร้างเส้นทางกลับ และสิ่งเหล่านั้นยังเป็นข้อกำหนดแยกที่มีเจ้าของแยก
ผลลัพธ์ที่คุณต้องการคือคำนำหน้าที่ตามเจ้าของการเชื่อมต่อที่รองรับของมันผ่านทุกช่วงเปลี่ยนผ่าน ไม่ใช่คำสั่งที่บังเอิญสำเร็จครั้งเดียวบนเครื่องที่เขียนมันขึ้นมา