ค้างสองวินาที: VPN หรือ Wi-Fi?

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

สองบันทึก ไม่ใช่หนึ่ง

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

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

ลิงก์เข้าถึงทำอะไรขณะแอปพลิเคชันค้าง

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

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

ping -i 0.5 -c 40 192.168.60.1
mtr -rwc 40 203.0.113.25
ip -brief address show

ตัวนับที่เพิ่มขึ้นเมื่อวานไม่อธิบายอะไรเกี่ยวกับการค้างเช้านี้ จำกัดความสัมพันธ์ไว้ที่หน้าต่างที่ผู้ใช้รายงาน

มองหาบันทึกการรีสตาร์ต

ดาตาแกรม UDP ที่หายไปเพียงอย่างเดียวไม่ได้ทำให้ Community OpenVPN เริ่มการเจรจา TLS ใหม่ พฤติกรรมการรีสตาร์ตเป็นไปตาม ping-restart และค่าที่บังคับใช้อาจถูกเซิร์ฟเวอร์ส่งมา คู่มือ 2.6 กำหนดตัวจับเวลาเหล่านั้น การส่งข้อมูลขาดช่วงหนึ่งวินาที ไม่เคยข้ามเกณฑ์ และบันทึกยังว่างเปล่า ดังนั้นค้นในบันทึกรอบการหยุดชะงักหาบรรทัดรีสตาร์ต การเชื่อมต่อใหม่ หรือตัวระบุเซสชันที่เปลี่ยนไป หากทั้งสามไม่ปรากฏ อุโมงค์น่าจะไม่ได้ทำอะไรและตัวจับเวลาไม่เคยเป็นปัญหา

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

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

ให้การเปรียบเทียบตัดสินว่าต้องแก้อะไร

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

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

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