DNS ล้มเหลวหรือปัญหา MTU? คำขอหยุดจริงที่ไหน

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

สองความล้มเหลวบนชั้นที่ต่างกัน

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

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

ถ้าอาการของคุณเป็นบางส่วน ให้หยุดดู DNS

ขั้นตอน 1: ชื่อถูกแก้หรือไม่

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

ถามตัวแก้ที่ระบบปฏิบัติการจะใช้ แล้วเปรียบเทียบ:

dig +short vpn.example.com
dig +short vpn.example.com @10.0.0.53

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

ขั้นตอน 2: การถ่ายโอนหยุดที่ไหน

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

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

การติดขัดหนึ่งครั้งที่ทำซ้ำได้มีค่ามากกว่าเรื่องเล่าสิบเรื่อง

ทำไม MTU จึงสร้างความเสียหายเฉพาะหลังการจับมือกัน

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

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

วัดขนาดอย่างชัดเจนแทนที่จะอนุมาน:

ping -M do -s 1472 203.0.113.20
tracepath 203.0.113.20

เปลี่ยนหนึ่งชั้น แล้วพิสูจน์

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

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

บันทึกนั้นแหละที่ป้องกันไม่ให้ DNS ขนาดแพ็กเก็ต และการพิสูจน์ตัวตนกลายเป็นกองทางลัดถาวรที่ไม่มีใครอธิบายได้ การทดสอบด้วย IP ดิบเป็นตัวอย่างที่ดีของทางลัดที่เปลี่ยนอัตลักษณ์ TLS และการปิดการตรวจสอบใบรับรองเพื่อให้การเปรียบเทียบผ่านไม่ใช่การวินิจฉัย