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

คำนำหน้าต้องมีเจ้าของ ไม่ใช่ชั่วขณะ

เริ่มจากเขียนข้อกำหนดเป็นประโยคที่มีประธาน: เข้าถึง 10.77.0.0/24 ผ่าน VPN ของสำนักงานตราบเท่าที่การเชื่อมต่อนั้นยังขึ้นอยู่ ประโยคนั้นระบุคำนำหน้า การเชื่อมต่อ และเงื่อนไข และตัดตัวแทนยอดนิยมสองอย่างออกทันที: ฮุกตอนล็อกอินและชื่ออินเทอร์เฟซอย่าง ppp0 หรือ utun2.

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

ใช้แหล่งเจตนาเส้นทางที่รองรับ

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

MechanismCan carry extra prefixesWho owns the lifetime
Gateway-pushed routesOften, if the gateway is configured for itThe connection
Managed profile settingsDepends on the client and profile formatThe profile
Provider tunnel settingsYes, as included and excluded routesThe provider process
Manual commandYes, onceNobody

สำหรับนักพัฒนาอุโมงค์แพ็กเก็ต การตั้งค่าอุโมงค์ IPv4 ของ Apple เปิดเผยเส้นทางที่รวมและที่ยกเว้นอย่างชัดเจน และ IPv6 ก็มีคู่กัน เป็น API ที่ผู้ให้บริการใช้ ไม่ใช่หลักฐานว่าแผง VPN แบบเนทีฟทุกอันเสนอรายการเส้นทางตามอำเภอใจให้ผู้ดูแลระบบ หากชุดค่าผสมปัจจุบันไม่สามารถแสดงคำนำหน้าที่ต้องการได้ ขั้นต่อไปคือเส้นทางการกำหนดค่าที่รองรับจากผู้ให้บริการ ไม่ใช่แอปอื่นที่ติดตั้งโดยหวังว่าจะทำงานได้ดีกว่า

อายุการใช้งานรวมถึงการทำความสะอาด

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

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

การแข่งกันตอนเชื่อมต่อใหม่

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

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

สิ่งที่ต้องทดสอบ และสิ่งที่เส้นทางทำไม่ได้

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

route -n get 10.77.0.5
netstat -rn -f inet

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

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

บทความที่เกี่ยวข้อง