VPN เชื่อมต่อใหม่ขณะขับรถ: เปลี่ยนสถานีวิทยุหรือเปลี่ยน IP?
การส่งต่อระหว่างเสาสัญญาณอาจทำให้เส้นทาง IP ยังสมบูรณ์ เปรียบเทียบไคลเอนต์ที่ย้ายอุโมงค์กับผู้ที่สร้างมันใหม่ และอ่านเหตุการณ์เครือข่าย ไม่ใช่การเดินทาง
สายหลุดเมื่อคุณขับผ่านขอบเมือง และไอคอน VPN ก็หายไปในจังหวะเดียวกัน เป็นเรื่องน่าดึงดูดที่จะบันทึกว่า “การเปลี่ยนเสาสัญญาณฆ่าอุโมงค์” มีสองสิ่งที่ต่างกันเกิดขึ้น และมีเพียงอย่างเดียวที่เกี่ยวกับเสาสัญญาณ การส่งต่อทางวิทยุสามารถทิ้งที่อยู่ IP เส้นทางเริ่มต้น และเซสชันของคุณไว้ได้อย่างสมบูรณ์ ในขณะที่การเปลี่ยนที่อยู่จริง จะทำให้อุโมงค์ใดก็ตามที่ไม่สามารถเคลื่อนไปพร้อมกับมันได้ขาดลง การเปรียบเทียบว่าไคลเอนต์จัดการกรณีที่สองนั้นอย่างไรคือแบบฝึกหัดที่มีประโยชน์ เพราะมันบอกคุณว่าคุณเห็นพฤติกรรมที่ออกแบบไว้หรือข้อบกพร่อง
การเปลี่ยนเสาสัญญาณไม่จำเป็นต้องเป็นการเปลี่ยนที่อยู่
เครือข่ายมือถือรักษาเซสชันแพ็กเก็ตให้มีชีวิตระหว่างการส่งต่อ ตราบใดที่จุดยึดการเคลื่อนที่ของผู้ให้บริการยังเหมือนเดิม ลิงก์วิทยุเปลี่ยนไป อุโมงค์ไม่รู้สึกตัว และไม่ควรมี reconnect ปรากฏในบันทึกใด ๆ นี่คือกรณีปกติสำหรับการเคลื่อนที่ภายในเมือง
สิ่งที่เปลี่ยนที่อยู่คือการย้ายระหว่างจุดยึด การสลับจาก Wi-Fi ไปยังเครือข่ายมือถือ หรือการสร้างอุโมงค์ใหม่ฝั่งผู้ให้บริการหลังช่วงห่างยาวนาน เหตุการณ์เหล่านั้นแทนที่ที่อยู่ต้นทางที่แพ็กเก็ตของคุณพกพา และเพื่อน VPN จะเห็นเพื่อนที่ย้ายไปแล้ว
ผลในทางปฏิบัติคือการเคลื่อนที่ไม่ใช่หลักฐาน อุปกรณ์ที่เดินทางสี่สิบกิโลเมตรอาจรักษาที่อยู่เดียวตลอดทาง และอุปกรณ์ที่อยู่นิ่งอาจเปลี่ยนที่อยู่สองครั้งเพราะเครือข่ายตัดสินใจเช่นนั้น การบันทึกเหตุการณ์คือวิธีเดียวที่จะแยกความแตกต่าง
สองแนวทาง: ย้ายอุโมงค์หรือสร้างใหม่
ไคลเอนต์แตกต่างกันในระดับที่พวกเขาใส่ใจว่าต้นทางภายนอกเปลี่ยนไป บางตัวผูกอุโมงค์กับที่อยู่ที่มันถูกสร้างขึ้นและต้องการการสร้างใหม่ทั้งหมด ตัวอื่นตรวจสอบแต่ละแพ็กเก็ตอย่างอิสระและเพียงอัปเดตว่าจะส่งคำตอบไปที่ใด
| Mechanism | Behaviour after the source changes | What the user notices |
|---|---|---|
| WireGuard | Endpoint updated on the next authenticated packet | Usually nothing; the tunnel continues |
| IKEv2 with MOBIKE | Security association moves to the new address | Short pause, no re-authentication |
| OpenVPN over UDP with float | Peer address may change without a restart | Might survive, depending on timing |
| Client bound to one address | Session dies and is rebuilt | A visible reconnect and a new authentication |
แถวบนอธิบายรายงานที่สับสนได้หลายกรณี WireGuard ไม่มีเซสชันให้แตก: ทุกแพ็กเก็ตมีดัชนีของเพื่อนและถูกตรวจสอบสิทธิ์ ดังนั้นแพ็กเก็ตที่ถูกต้องซึ่งมาจากที่อยู่ใหม่จึงเป็นของเพื่อนรายนั้นตามนิยาม และจุดสิ้นสุดที่บันทึกไว้จะตามมันไป ไคลเอนต์ที่แสดง “เชื่อมต่อแล้ว” อย่างต่อเนื่องตลอดการเดินทางกำลังพูดความจริง
แถวล่างก็ไม่ใช่ข้อบกพร่อง การสร้างเซสชันใหม่รันการตรวจสอบสิทธิ์กับที่อยู่ปัจจุบันอีกครั้ง ซึ่งเป็นสิ่งที่คุณต้องการเมื่อที่อยู่เก่าอาจเป็นของคนอื่นแล้ว
สังเกตเหตุการณ์ ไม่ใช่การเคลื่อนที่
บน Android ระบบย่อยการเชื่อมต่อรายงานการเปลี่ยนแปลงเครือข่ายเป็นเหตุการณ์ และนั่นคือสิ่งที่คุณควรเชื่อมโยงกับพฤติกรรมของไคลเอนต์ ดัมป์นั้นยาว แต่ส่วนที่เกี่ยวข้องคือเครือข่ายเริ่มต้นและที่อยู่ของมัน:
adb shell dumpsys connectivity | grep -E 'NetworkAgentInfo|Default network'
adb shell ip -br addr show
adb logcat -b main -s Vpn:* | head -n 40ฝั่งเซิร์ฟเวอร์มีการวัดโดยตรงสำหรับกรณีโรมมิ่ง WireGuard เก็บจุดสิ้นสุดที่ตรวจสอบสิทธิ์ล่าสุดต่อเพื่อนแต่ละราย ดังนั้นการเปลี่ยนที่อยู่จะปรากฏเป็นค่าที่เปลี่ยนไปแทนการเชื่อมต่อใหม่:
sudo wg show wg0 endpoints
sudo wg show wg0 latest-handshakesเปรียบเทียบจุดสิ้นสุดก่อนและหลังการเดินทาง หากที่อยู่และพอร์ตไม่เปลี่ยน อุโมงค์ไม่ต้องทำอะไรเลย และการเชื่อมต่อใหม่มาจากที่อื่น ซึ่งปกติคือแอปพลิเคชัน หากจุดสิ้นสุดเปลี่ยนแต่ตราเวลาของการจับมือยังใกล้กับช่วงต่ออายุคีย์ปกติ อุโมงค์ก็ย้ายไปแทนที่จะรีสตาร์ท
การรีสตาร์ทดูแตกต่างออกไป: ตราเวลาของการจับมือถูกรีเซ็ตไปที่ช่วงเวลาของการเชื่อมต่อใหม่ และไคลเอนต์บันทึกลำดับการเริ่มต้นแทนการดำเนินต่ออย่างเงียบ ๆ
เมื่อใดที่การเชื่อมต่อใหม่คือพฤติกรรมที่ถูกต้อง
การปฏิบัติต่อทุกการเชื่อมต่อใหม่เป็นข้อบกพร่องนำไปสู่การกำหนดค่าที่รักษาเซสชันที่ตายแล้วให้มีชีวิต เพื่อนที่ที่อยู่เปลี่ยนเพราะเครือข่ายจัดสรรใหม่ไม่ควรได้รับทราฟฟิกสำหรับการแมปเก่าต่อไป และไคลเอนต์ที่ดำเนินต่ออย่างเงียบ ๆ อาจลงเอยด้วยการส่งเข้าหลุมดำในขณะที่ไอคอนยังเขียวอยู่
เปรียบเทียบความล้มเหลวทั้งสองจากมุมมองของผู้ใช้ การเชื่อมต่อใหม่มีค่าใช้จ่ายไม่กี่วินาทีและการตรวจสอบสิทธิ์ใหม่ อุโมงค์ที่ล้าสมัยมีค่าใช้จ่ายเป็นแอปพลิเคชันที่ค้างโดยไม่มีข้อผิดพลาด ซึ่งอธิบายได้ยากกว่ามากและมีแนวโน้มที่จะถูกรายงานว่า “อินเทอร์เน็ตพัง” มากกว่า
ยังมีคำถามเชิงนโยบายซ่อนอยู่ข้างใต้ ในช่วงห่างระหว่างการสูญเสียเส้นทางหนึ่งและการสร้างอีกเส้นทางหนึ่ง ไคลเอนต์บางตัวกลับไปส่งทราฟฟิกโดยตรง การป้องกันสิ่งนั้นเป็นการควบคุมแยกจากการกู้คืนอัตโนมัติ และไคลเอนต์อาจเก่งด้านหนึ่งและแย่อีกด้าน ตัดสินใจว่าคุณต้องการสิ่งใดก่อนที่จะปรับแต่งทั้งสอง
เขียนลำดับที่สังเกตได้ลงไป
รายงานที่มีประโยชน์ระบุแหล่งที่มาของเหตุการณ์: การเปลี่ยนเครือข่ายเริ่มต้นพร้อมที่อยู่ใหม่ การสลับจาก Wi-Fi ไปยังเครือข่ายมือถือ หรือการส่งต่อที่ไม่มีการเปลี่ยนที่อยู่เลย จากนั้นระบุว่าไคลเอนต์ทำอะไร ด้วยตราเวลาจากฝั่งเซิร์ฟเวอร์ไม่ใช่จากความจำ
หากอุโมงค์ย้ายไป ให้บอกเช่นนั้นและบันทึกตระกูลจุดสิ้นสุดใหม่ หากมันถูกสร้างใหม่ ให้บันทึกว่าการตรวจสอบสิทธิ์สำเร็จในความพยายามครั้งแรกหรือไม่และช่วงห่างกินเวลานานเท่าใด ข้อเท็จจริงสามข้อนั้นแยกการออกแบบมือถือที่แข็งแรงออกจากไคลเอนต์ที่โซซัดโซเซระหว่างเครือข่าย
และหลีกเลี่ยงวลี “การเปลี่ยนเสาสัญญาณ” เว้นแต่บันทึกของอุปกรณ์จะยืนยันได้จริง เอกสารการเชื่อมต่อของ Android อธิบาย callback ที่แยกความพร้อมใช้งานออกจากการเปลี่ยนเครือข่ายเริ่มต้น และความแตกต่างนั้นคือสิ่งที่รายงานของคุณต้องการ ส่วนที่เหลือเป็นเรื่องราวเกี่ยวกับการขับรถ