Git ค้างใน WSL2 เมื่อใช้ VPN: MTU ของอินเทอร์เฟซหรือเส้นทาง?

โคลนยืนยันตัวตนแล้ว จำนวนออบเจ็กต์ปรากฏขึ้น จากนั้นก็ไม่มีอะไรเคลื่อนไหวเป็นเวลาหลายนาที Windows รายงานว่า VPN เชื่อมต่ออยู่ ชื่อโฮสต์ถูกแปลง และเบราว์เซอร์บนเครื่องเดียวกันดึงหน้าเดียวกันของที่เก็บโค้ดได้โดยไม่ยาก การผสมกันนี้ชี้ไปที่ขนาดแพ็กเก็ตมากกว่าข้อมูลรับรอง และคำถามเรื่องขนาดต้องถามในสองที่เพราะ WSL2 มีอินเทอร์เฟซ Linux ของตัวเองพร้อม MTU ของตัวเอง ตัวเลขหนึ่งเป็นของฝั่ง Windows ของเส้นทาง อีกตัวเป็นของดิสทริบิวชัน และการอ่านเฉพาะอะแดปเตอร์ VPN ทำให้ครึ่งหนึ่งของเส้นทางไม่ถูกตรวจสอบ

สัญญาณสามอย่างแยกปัญหาขนาดออกจากสาเหตุอื่น

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

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

เปรียบเทียบอินเทอร์เฟซทั้งสองก่อนตัดสินใจ

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

netsh interface ipv4 show subinterfaces
wsl -d Ubuntu -- bash -lc 'dest=$(getent ahostsv4 github.com | awk \'NR==1{print $1}\'); ip -br link show; ip route get "$dest"'

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

ตัดสินว่าตัวเลขควรเล็กลงหรือไม่

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

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

ip -br link show dev eth0
sudo ip link set dev eth0 mtu 1380
ip -br link show dev eth0

ตัดสินว่าการตั้งค่าควรอยู่ที่ใด

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

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

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

ตรวจสอบหลังเริ่มระบบใหม่ แล้วย้อนกลับ

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

ip -br link show dev eth0
ip route get "$(getent ahostsv4 github.com | awk 'NR==1{print $1}')"

เก็บค่าเดิมที่บันทึกไว้ข้างการเปลี่ยนแปลงเพื่อให้ยกเลิกการทดลองได้อย่างสะอาด และบันทึกว่าทดสอบตระกูลที่อยู่ใด เพราะผลลัพธ์ IPv4 ไม่ได้บอกอะไรเกี่ยวกับการเชื่อมต่อ IPv6 บนโฮสต์เดียวกัน เอกสารเครือข่ายของ WSL อธิบายโหมดที่กำหนดว่าการแก้ไขควรมีลักษณะอย่างไร ตัวเลข MTU เองเป็นการวัดในเครื่อง ไม่ใช่คำแนะนำ