OpenVPN เตือนการใช้ MTU ที่ไม่สอดคล้อง: ข้อความเปรียบเทียบอะไร

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

เงื่อนไขสามข้อตัดสินคำตอบ: คู่ peers เปรียบเทียบอะไร ค่าเก่าหรือไม่ และมีอาการใดนอกเหนือจากคำเตือน

คำเตือนเปรียบเทียบตัวเลือก ไม่ใช่แพ็กเก็ต

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

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

ทำไม link-mtu จึงเลิกใช้

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

การตรวจสอบความสอดคล้องยังมีค่า OCC แบบเลือกได้ที่ผูกกับ tun-mtu ซึ่งเปลี่ยนสิ่งที่นำมาเปรียบเทียบโดยไม่เปลี่ยนสิ่งที่เครือข่ายรับส่ง การตั้งค่าไม่ทำให้แพ็กเก็ตใหญ่ขึ้นพอดี

แก้ไขโปรไฟล์ก่อนทดสอบเส้นทาง

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

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

จากนั้นทดสอบอาการที่คุณมีจริง

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

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

เก็บค่า effective ไว้กับผลลัพธ์

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

การปิดการตรวจสอบความสอดคล้องไม่ได้ทำให้อะไรกลมกลืน มันเพียงลบการสังเกตออกและปล่อยการตั้งค่าทั้งสองไว้เหมือนเดิม