MTU ของ VPN บน iPhone: กำหนดเจ้าของก่อนเปลี่ยนตัวเลข
สามคำถามตัดสินว่าแอป โปรไฟล์เกตเวย์ หรือไม่มีใครบนโทรศัพท์สามารถเปลี่ยนขนาดได้ ตอบคำถามเหล่านี้ก่อนยืมตัวเลขจาก Mac
ทุกกระทู้เกี่ยวกับขนาดแพ็กเก็ตของ VPN บน iPhone สุดท้ายมักเสนอคำสั่ง Mac แบบเดียวกันกับอินเทอร์เฟซที่ชื่อ ppp0 พร้อมตัวเลขกำกับ คำสั่งนั้นไม่ได้ผล และไม่ใช่ตัวควบคุมที่ถูกต้องแม้บน Mac เว้นแต่อินเทอร์เฟซนั้นจะเป็นของการเชื่อมต่อที่กำลังพูดถึง บนโทรศัพท์ ตัวเลขเป็นของใครก็ตามที่นำอุโมงค์ไปใช้งาน ได้แก่ ระบบปฏิบัติการสำหรับโปรไฟล์แบบเนทีฟ ผู้ให้บริการอุโมงค์แพ็กเก็ตสำหรับแอป หรือเกตเวย์เมื่อมีการเจรจาแอตทริบิวต์ที่มีเอกสารกำกับ สามคำถามจะช่วยแยกแยะว่าคุณกำลังเจอกรณีใด
คำถามข้อหนึ่ง: ไคลเอนต์ใดกำลังทำงาน
โปรไฟล์ IKEv2 แบบเนทีฟ โปรไฟล์ Cisco IPsec ที่มีมาให้ และไคลเอนต์ Cisco จากบุคคลที่สามเป็นสามการใช้งานที่แตกต่างกันพร้อมชุดแอตทริบิวต์ที่รองรับต่างกันสามชุด ประเภทโปรไฟล์ในการตั้งค่าบอกว่าอันใดที่โทรศัพท์เริ่มจริง และรายการแอปบอกว่ามีผู้ให้บริการอยู่ในเส้นทางหรือไม่ เริ่มจากตรงนั้น เพราะส่วนที่เหลือของการตัดสินใจตามมาจากจุดนี้ หากไม่มีผู้ให้บริการในรายการแอป ระบบปฏิบัติการเป็นเจ้าของอุโมงค์
อย่าสรุปการใช้งานจากผู้จำหน่ายเกตเวย์ หัวหน้าศูนย์ Cisco สามารถยุติการเชื่อมต่อจากไคลเอนต์ที่ไม่มีอะไรเหมือนกันนอกจากชื่อผู้จำหน่าย ภาพหน้าจอของบิลด์เก่าบนรีลีสเก่าบอกว่าคู่นั้นรองรับอะไร ไม่ได้บอกว่าโทรศัพท์ในมือคุณทำอะไร
คำถามข้อสอง: ใครเป็นเจ้าของค่า
Apple เปิดเผยพร็อพเพอร์ตี MTU ให้ผู้พัฒนาอุโมงค์แพ็กเก็ตผ่านออบเจ็กต์การตั้งค่าส่วนขยายเครือข่าย นี่คือ API สำหรับผู้ให้บริการที่กำหนดค่าอุโมงค์ของตัวเอง ไม่ใช่สวิตช์ที่ผู้ใช้หรือผู้ดูแลระบบจะเปิดบนไคลเอนต์ที่ติดตั้งของคนอื่นได้ แอปจากบุคคลที่สามอาจเลือกเปิดเผย เพิกเฉย หรือกำหนดค่าตายตัว
สำหรับโปรไฟล์แบบเนทีฟ ระบบปฏิบัติการเลือกขนาดอินเทอร์เฟซ และโทรศัพท์ไม่มีตัวแก้ไขให้ สำหรับเกตเวย์ Cisco สำหรับการเข้าถึงระยะไกลมีแอตทริบิวต์ที่มีเอกสารกำกับสำหรับโปรไฟล์การเชื่อมต่อ และจะใช้ได้หรือไม่ขึ้นอยู่กับไคลเอนต์ รีลีส และทรานสปอร์ตที่เจรจาไว้ ช่องว่างระหว่างสิ่งที่มีเอกสารกับสิ่งที่ปฏิบัติตามคือจุดที่ตัวเลขที่คัดลอกมาผิดพลาด
| Owner | Who can change it | Reachable from the phone |
|---|---|---|
| Packet-tunnel provider | The app vendor through its API | Only if the app exposes a setting |
| Native IKEv2 or Cisco IPsec profile | The operating system | No user control |
| Gateway group policy attribute | The gateway administrator | If the client honours it |
คำถามข้อสาม: อาการขึ้นกับขนาดหรือไม่
ปัญหาขนาดมีลายเซ็นเฉพาะ คำขอเล็กสำเร็จ การอัปโหลดใหญ่หรือการตอบกลับใหญ่ค้าง และบริการเดียวกันทำงานผ่านเครือข่ายการเข้าถึงอื่น การกรอง ขีดจำกัดเพย์โหลดของแอป และเซิร์ฟเวอร์ที่ค้างสามารถทำให้เกิดข้อร้องเรียนคล้ายกัน ดังนั้นบันทึกการทำงานหนึ่งรายการที่ล้มเหลวไว้ข้าง ๆ รายการที่ทำงานได้ เขียนทั้งสองพร้อมเวลาและขนาดหากแอปรายงาน หากไม่มีคู่นั้น การเปลี่ยนแปลงทุกครั้งหลังจากนั้นคือการเดา
ทำแบบทดสอบเดียวกันบน Wi-Fi และบนเครือข่ายมือถือ ความล้มเหลวที่ตามเครือข่ายชี้ไปที่เส้นทาง ส่วนที่ตามอุปกรณ์ชี้ไปที่ไคลเอนต์หรือโปรไฟล์ และทั้งสองต้องการเจ้าของต่างกัน ใช้บริการและบัญชีเดียวกันสำหรับทั้งสองรอบ มิฉะนั้นการเปรียบเทียบจะไม่บอกอะไร
ทำไมสูตร Mac ยังปรากฏอยู่เรื่อย ๆ
หลายปีของ VPN บนเดสก์ท็อปที่ใช้ PPP ทำให้การเปลี่ยนขนาดอินเทอร์เฟซเป็นวิธีแก้ปัญหาเฉพาะที่ที่ชอบด้วยกฎหมาย และคำแนะนำเหล่านั้นถูกคัดลอกต่อไปยังกระทู้มือถือ บนโทรศัพท์ไม่มีเชลล์ ไม่มีชื่ออินเทอร์เฟซแบบนั้น และไม่มีความคงอยู่หลังการเชื่อมต่อใหม่ สูตรที่แก้ปัญหาเดสก์ท็อปในปี 2011 เดินทางไกลกว่าสภาพที่ทำให้มันถูกต้องมาก ไคลเอนต์มือถือไม่ยอมรับคำสั่งเชลล์ใด ๆ สำหรับเรื่องนี้ ไม่ว่ากระทู้จะอ้างอย่างไร
มองค่าที่คัดลอกมาเป็นสมมติฐานเกี่ยวกับเส้นทาง ไม่ใช่การตั้งค่า หากขนาดเล็กทำให้การถ่ายโอนทำงานและขนาดใหญ่ล้มเหลวอย่างสม่ำเสมอ คุณมีหลักฐานเกี่ยวกับเส้นทาง แต่ยังต้องหาองค์ประกอบที่ได้รับอนุญาตให้ดำเนินการกับมัน การค้นหานั้นมักจบที่โปรไฟล์เกตเวย์หรือผู้จำหน่ายแอป และแทบไม่จบที่โทรศัพท์
ทรานสปอร์ตเปลี่ยนคำตอบ
หากเซสชันทำงานบน TLS แทน IPsec การปรับการแบ่งส่วน TCP บนเกตเวย์อาจช่วยได้ เพราะเขียนขนาดเซกเมนต์ที่ประกาศใหม่สำหรับโฟลว์ TCP แต่ไม่ทำอะไรกับทราฟฟิก UDP ซึ่งครอบคลุมเว็บสมัยใหม่มากกว่าที่คนคาดคิด ตรวจสอบทรานสปอร์ตที่เจรจาก่อนเสนอการเปลี่ยนแปลง และระบุในตั๋วว่าคาดว่าทรานสปอร์ตใดจะได้รับผลกระทบ
การค้นพบ MTU ของเส้นทางมีไว้เพื่อให้ปลายทางเรียนรู้ขีดจำกัดจริงแทนการเดา การบล็อกผลป้อนกลับและการกำหนดขนาดเล็กแบบตายตัวเป็นการแลกการถ่ายโอนใหญ่ที่ทำงานได้กับต้นทุนถาวรที่ซ่อนอยู่ในการเชื่อมต่อทุกครั้ง
จะถามทีมเกตเวย์อะไร
ขอสามอย่าง ชื่อแอตทริบิวต์ที่แน่นอนและขอบเขตของมัน ไคลเอนต์ที่ติดตั้งใช้ตามหรือไม่ และเซสชันเจรจาทรานสปอร์ตใด การเปลี่ยนแปลงที่ใช้กับนโยบายกลุ่มเดียวทดสอบได้ ส่วนการแก้ไขทั่วทั้งระบบทดสอบไม่ได้ และมันย้ายความเสี่ยงไปยังผู้ใช้ที่ไม่เคยรายงานปัญหา ขอเอกสารอ้างอิงด้วย เพราะชื่อแอตทริบิวต์เปลี่ยนไประหว่างรีลีส
จากนั้นเปลี่ยนเพียงอย่างเดียวและทดสอบการทำงานเดิมที่ล้มเหลวซ้ำ ไม่ใช่การดาวน์โหลดทดสอบความเร็ว เก็บบันทึกก่อนและหลังพร้อมเวอร์ชันไคลเอนต์และเครือข่ายการเข้าถึง เพื่อให้รายงานถัดไปเปรียบเทียบได้แทนที่จะเถียงกันใหม่
หากการทำงานยังล้มเหลวที่ขนาดเดิม แสดงว่าขนาดไม่ใช่สาเหตุ บันทึกข้อสรุปนั้นด้วย เพื่อให้คนถัดไปไม่เปิดสมมติฐานเดิมอีก