ทำไม VPN ของคุณจึงใช้เวลานานกว่าการหยุดให้บริการในการกลับมา

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

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

สามการรอที่ดูเหมือนหนึ่งเดียว

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

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

ขั้นตอนใดกันแน่ที่ช้า?

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

จำแนกความล้มเหลวก่อนจะแตะตัวเลขใด

เมื่อใดการลดตัวจับเวลาจึงช่วย และเมื่อใดไม่ช่วย

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

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

ตรวจสอบความพร้อมก่อนจะโทษลูกค้า

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

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

สิ่งที่ต้องบันทึก

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

บันทึกนั้นเปลี่ยนการอัปเกรดซอฟต์แวร์ครั้งถัดไปให้เป็นการเปรียบเทียบแทนการทดลอง