ipsec.conf หรือ swanctl.conf? เลือกฟรอนต์เอนด์ strongSwan สักหนึ่งตัว

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

สองไฟล์ สองตัวโหลด หนึ่งดีมอน

การจัดแบบ starter แบบเก่าอ่าน ipsec.conf และส่งต่อการเชื่อมต่อไปยัง charon ผ่านการผสานการจัดการแบบเก่าจุดเข้าปฏิบัติการของมันคือคำสั่ง ipsec

การจัดแบบ swanctl โหลดนิยามผ่าน VICI อ่าน swanctl.conf และขับเคลื่อนด้วยคำสั่ง swanctlดีมอน charon ที่เป็นระบบดั้งเดิมของ systemd ผสานกับการเข้าหานี้

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

อ่านแพ็กเกจและ unit ที่ติดตั้งไว้

เริ่มด้วยโหมดอ่านอย่างเดียวชื่อแพ็กเกจบน Ubuntu 24.04 แยกกันคือ strongswan-starter, strongswan-swanctl และ charon-systemdแพ็กเกจที่หายไปคือข้อมูลที่มีประโยชน์ ไม่ใช่คำสั่งให้ติดตั้ง

ทำบัญชีแพ็กเกจและ unit ในครั้งเดียว:

dpkg-query -W strongswan-starter strongswan-swanctl charon-systemd
systemctl list-unit-files '*strongswan*'

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

ถ้า unit ที่ใช้งานคือ strongswan-starter ไฟล์ที่สำคัญคือ ipsec.confถ้าเป็น charon-systemd กับ swanctl แล้ว ipsec.conf เป็นเพียงเครื่องประดับ

ใช้เส้นทางการควบคุมที่ตรงกัน

ฟรอนต์เอนด์แต่ละตัวมีมุมมองของการเชื่อมต่อและความสัมพันธ์เป็นของตัวเองswanctl --list-conns แสดงนิยามที่โหลดไว้ และ swanctl --list-sas แสดงความสัมพันธ์ที่ทำงานอยู่เส้นทางเก่าใช้ ipsec statusall

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

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

รูปแบบไม่ใช่เวอร์ชัน IKE

โปรไฟล์เก่าเลือก IKEv1 ด้วย keyexchange=ikev1การเชื่อมต่อ swanctl ใช้การตั้งค่าเวอร์ชัน ซึ่ง 1 เลือก IKEv1นี่คือคำศัพท์สองชุดสำหรับแนวคิดเดียวกัน ไม่ใช่การแปลง

ที่อยู่ของอีกฝ่าย ตัวตนภายในและระยะไกล แหล่งข้อมูลรับรอง ข้อเสนอ และตัวเลือก child ต้องถูกแมปอย่างตั้งใจการวางบล็อก left/right ลงในไวยากรณ์ swanctl ไม่ได้ทำสิ่งใดในนั้น

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

ตรวจตัวโหลดก่อนแตะโปรไฟล์

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

เส้นทางการควบคุมสองเส้นตอบคำถามเรื่องการโหลดโดยตรง:

swanctl --list-conns
ipsec statusall

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

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