SSH ค้างเมื่อใช้ OpenVPN? วัด MTU ของเส้นทางก่อน

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

อ่านรูปร่างของความล้มเหลวก่อนแตะโปรไฟล์

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

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

วัดเพดานจากทั้งสองฝ่าย

เปรียบเทียบ MTU ของอุโมงค์กับลิงก์จริงก่อนแก้อย่างใดอย่างหนึ่ง อุโมงค์ที่คัดลอกค่าจริงมาแล้วบอกคุณว่าความไม่ตรงกันอยู่ที่ใด

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

ip link show tun0
ping -M do -s 1380 10.9.0.1

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

mssfix กับ fragment ทำงานคนละอย่าง

mssfix จำกัดขนาดเซกเมนต์ที่การเชื่อมต่อ TCP ภายในอุโมงค์ประกาศตอนจับมือ นี่คือคันโยกที่ถูกต้องสำหรับ SSH, HTTPS และการคัดลอกไฟล์ จึงมักหายค้างทันทีที่ตั้งค่า มันไม่แตะเพย์โหลด UDP เลย

อุโมงค์ที่บรรทุกบริการ UDP ด้วยอาจยังล้มเหลวหลังแก้ SSH แล้ว ผลลัพธ์นั้นทำให้ทุกคนที่คิดว่าตัวเลือกเดียวครอบคลุมทุกอย่างสับสน

fragment คือกลไกอีกตัวและเครื่องมืออีกแบบ มันแยกแพ็กเก็ตที่ใหญ่เกินก่อนห่อหุ้ม ใช้ได้เฉพาะการขนส่ง UDP เพิ่มภาระต่อดาตาแกรม และมีเอกสารระบุว่าเป็นทางเลือกสุดท้ายเมื่อการค้นหาพัง ทั้งสองค่าต้องตรงกันที่เพื่อนที่ปิดอุโมงค์ เมื่อฝั่งหนึ่งจำกัดอีกฝั่งแบ่ง จะเกิดคำเตือนในบันทึกและพฤติกรรมที่ไม่มีใครคาดเดาจากไฟล์ได้

การลด MTU ของอินเทอร์เฟซคือทางเลือกแบบหยาบ

การลด MTU ของอินเทอร์เฟซที่ทั้งสองฝั่งคือเครื่องมือหยาบ มันบอกตัวเลขที่เล็กกว่าแก่ผู้ส่งภายในทุกตัว ซึ่งได้ผล และผลักภาระนั้นให้ทราฟฟิกทั้งหมดแทนที่จะเป็นโฟลว์ TCP ที่ต้องการ

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

ทดสอบซ้ำด้วยการถ่ายโอนที่ค้าง

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

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