การอัปเกรด Ubuntu ทำให้ L2TP/IPsec พังหรือไม่? เปรียบเทียบข้อเสนอ IKEv1

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

การอัปเกรดเปลี่ยนอะไรไปจริง ๆ สิ่งที่เปลี่ยนไปคือรายการทรานส์ฟอร์มที่เครื่องของคุณยินดีเสนอ สแตก IPsec ทั้งสองที่ใช้บน Ubuntu คือ strongSwan และ Libreswan ตัดอัลกอริทึมที่ไม่ถือว่าปลอดภัยอีกต่อไป และปลั๊กอิน NetworkManager ที่อยู่ข้างหน้ามีรายการของตัวเองซึ่งเคลื่อนตามกำหนดเวลาอีกแบบ

เซิร์ฟเวอร์ที่ปักหมุดไว้กับ 3DES, SHA1 และกลุ่ม Diffie-Hellman ขนาด 1024 บิตอาจลงเอยด้วยการไม่ได้ยินสิ่งที่มันยอมรับเลย

มีสองชั้นที่ป้อนข้อเสนอ IKEv1 เดมอนมีชุดข้อเสนอเริ่มต้นที่คอมไพล์มาให้ และปลั๊กอิน L2TP จะพึ่งพาชุดนั้นหรือให้รายการของตัวเอง ก่อน NetworkManager-l2tp 1.2.16 ปลั๊กอินพึ่งพาชุดนั้น ข้อเสนอของคุณจึงเป็นสิ่งที่เดมอนที่ติดตั้งไว้เห็นว่าเหมาะสม ตั้งแต่ 1.2.16 เป็นต้นไป ปลั๊กอินส่งรายการที่จัดทำเป็นเอกสารซึ่งจำลองตามไคลเอนต์ Windows และ Apple และรายการนั้นกว้างกว่าค่าเริ่มต้นเดิมแต่ไม่มีทุกชุดผสมแบบเก่าที่หัวคิวอีกต่อไป

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

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

อ่านความล้มเหลวก่อนจะเปลี่ยนอะไร

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

ipsec --version
nmcli connection show "Your VPN name" | grep -i ipsec

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

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

เฟส 1 และเฟส 2 เป็นการเดิมพันแยกกัน

IKEv1 เจรจาสองครั้ง โหมดหลักสร้างสมาคมความปลอดภัย IKE จากอัลกอริทึมการเข้ารหัส อัลกอริทึมความสมบูรณ์ กลุ่ม Diffie-Hellman และวิธีการพิสูจน์ตัวตน จากนั้นโหมดเร็วสร้างสมาคม ESP ที่จะขนส่ง L2TP เซิร์ฟเวอร์มีอิสระที่จะยอมรับอันแรกและปฏิเสธอันที่สอง โปรไฟล์ที่ถูกครึ่งเดียวจึงล้มเหลวช้ากว่าที่คุณคาดและดูเหมือนข้อบกพร่องอื่น

Phase 1: 3des-sha1-modp1024!
Phase 2: 3des-sha1!

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

เปลี่ยนหนึ่งฟิลด์ แล้วทำการทดสอบซ้ำ

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

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