VPN ping ใช้งานได้แต่เว็บไซต์ค้าง: ตรวจสอบขนาด

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

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

การตอบกลับ echo ตอบคำถามที่เล็กกว่ามาก

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

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

ค้นหาว่าการเชื่อมต่อเริ่มต้นแล้วหรือไม่

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

curl -v --max-time 10 https://internal.example/ -o /dev/null
ss -tn state established '( dport = :443 )'

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

วัดขนาดด้วยตัวเลขที่ระบุ

เมื่ออาการค้างปรากฏภายใต้ภาระ ทดสอบขนาดแพ็กเก็ตหนึ่งค่าด้วยการตั้งบิตห้ามแบ่งส่วน และระบุการคำนวณเพื่อให้ผลลัพธ์มีความหมาย บน Linux ที่มี iputils เพย์โหลด 1392 ไบต์บวกส่วนหัว ICMP 8 ไบต์และส่วนหัว IPv4 20 ไบต์ให้แพ็กเก็ตภายในขนาด 1420 ไบต์พอดี ระบุการคำนวณนั้นในตั๋ว เพราะ ping เปล่า ๆ ที่ไปถึงเกตเวย์ไม่ได้พิสูจน์อะไรเกี่ยวกับแอปพลิเคชัน

ping -4 -M do -s 1392 10.44.0.10
ping -4 -M do -s 1372 10.44.0.10

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

คำนวณเส้นทางภายนอก

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

การค้นพบ MTU ของเส้นทางใน IPv4 ขึ้นอยู่กับผลป้อนกลับเกี่ยวกับแพ็กเก็ตที่ไม่สามารถส่งต่อได้โดยไม่แบ่งส่วน และ IPv6 ใช้ข้อความ Packet Too Big ข้อกำหนด IPv4 อธิบายกลไกนั้น การกรองผลป้อนกลับทำให้ผู้ส่งสูญเสียความสามารถในการเรียนรู้ และปล่อยให้ส่งแพ็กเก็ตซ้ำที่ไม่วันจะใส่ลงได้ สิ่งนี้เองที่ทำให้ คำขอเล็กที่ทำงานได้และคำขอใหญ่ที่ล้มเหลวอยู่ร่วมกันได้อย่างสบาย

เปลี่ยนตัวเลขหนึ่งค่าและทดสอบแอปพลิเคชันอีกครั้ง

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

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

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