ทำไม vpnc ตัดการเชื่อมต่อที่ 24 นาที และควรเปลี่ยนอะไร

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

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

ตัวจับเวลาใดเป็นเจ้าของการหลุด

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

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

กรณีแรก: ไคลเอนต์ยอมทิ้งเซสชันที่ไม่ได้ใช้งาน

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

DPD idle timeout (our side) 0
NAT Traversal Mode cisco-udp

การปิด DPD ฝั่งไคลเอนต์ลบการเตือนผิดพลาดและยังลบการตรวจจับในเครื่องเพียงอย่างเดียวของคุณด้วย ดังนั้นใช้มันเดี่ยว ๆ และดูว่าช่วงเวลาเปลี่ยนหรือไม่

กรณีที่สอง: รีคีย์ถูกปฏิเสธ

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

IKE DH Group dh5

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

กรณีที่สาม: การแปลเขียน encapsulation ใหม่

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

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

โปรไฟล์ที่เชื่อมต่อได้ดีจากบรรทัดคำสั่งแต่ไม่ได้จากเดสก์ท็อปเป็นปัญหาของส่วนหน้า ไม่ใช่ปัญหาของตัวจับเวลา

ตรวจสอบการแลกเปลี่ยนที่ล้มเหลวก่อนการเปลี่ยนแปลงครั้งที่สาม

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

vpnc --debug 3 office

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