PSK ของ L2TP/IPsec ถูกปฏิเสธ: ไล่จากไดอะล็อกก่อน แล้วจึงไปที่ไฟล์
คีย์ที่เห็นบนหน้าจอยังแพ้ไฟล์ความลับที่ค้างอยู่หรือการขึ้นบรรทัดใหม่ที่มองไม่เห็นได้ ตามรอยตั้งแต่ช่องใน NetworkManager ไปจนถึง /etc/ipsec.d
คุณวางคีย์ที่แชร์ไว้ล่วงหน้าจากข้อความของผู้ดูแลระบบลงในไดอะล็อกของ NetworkManager ติ๊กช่องเพื่อแสดงคีย์ และมันตรงกันทุกตัวอักษร แต่การเชื่อมต่อก็ยังจบลงด้วยความล้มเหลวในการพิสูจน์ตัวตนก่อนที่อุโมงค์จะขึ้น ครั้งแรกที่เห็นผมคิดว่าคีย์ผิด แต่ไม่ใช่ สองสิ่งอื่นเป็นตัวกำหนดว่าเดมอนอ่านอะไรจริง ๆ คือไฟล์ความลับที่ปลั๊กอินเขียนให้กับการเชื่อมต่อนั้น และค่าที่ผ่านไดอะล็อกมาทั้งหมดไม่เปลี่ยนแปลงหรือไม่
เส้นทางด้านล่างไล่คีย์จากช่องไปจนถึงไฟล์ และลำดับนั้นเองที่บอกว่าคีย์หายไปตรงไหน ทำบนเครื่องที่ล้มเหลว ไม่ใช่เครื่องที่ใช้งานได้ เพราะความต่างระหว่างสองเครื่องมักอยู่ที่การจัดวางไฟล์ ไม่ใช่ที่คีย์
เริ่มที่ไดอะล็อก แต่อย่าไว้ใจช่องกรอก
เปิดแท็บ IPsec ของการเชื่อมต่อ แล้วพิมพ์คีย์ใหม่แทนการวาง จากคีย์ที่คัดลอกมาจากข้อความแชท ไฟล์ PDF หรือโปรแกรมจัดการรหัสผ่าน อาจมีอักขระขึ้นบรรทัดใหม่ต่อท้ายที่ช่องไม่แสดง และตัวอักษรที่เห็นก็ยังดูถูกต้อง
คลิกตัวควบคุมแสดงรหัสผ่านแล้วดูที่ปลายสตริง ไม่ใช่ตรงกลาง ถ้าเคอร์เซอร์ทิ้งบรรทัดว่างไว้ใต้ข้อความ ให้ลบมันแล้วพิมพ์อักขระตัวสุดท้ายใหม่ การแก้เพียงจุดเดียวนี้แก้รายงานลักษณะนี้ได้มากจนน่าประหลาดใจ และถูกกว่าการอ่านล็อกใด ๆ
ถ้าคีย์มาจากระบบตั๋วที่ตัดบรรทัดยาว ให้ขอผ่านช่องทางที่ไม่ตัดบรรทัด อย่าเทียบสองสตริงด้วยสายตา แต่ให้เทียบความยาวกับผู้ดูแลระบบ เพราะอักขระที่หายไปตรงจุดตัดบรรทัดมองไม่เห็นในฟอนต์แบบสัดส่วน
ตามคีย์เข้าไปใน /etc/ipsec.d
ปลั๊กอินไม่เคยส่ง PSK ให้เดมอน IPsec เป็นอาร์กิวเมนต์บน บนบรรทัดคำสั่ง แต่เก็บค่าไว้ในไฟล์ความลับและจัดให้เดมอนดึงไฟล์นั้นเข้ามา โดยเพิ่มบรรทัด include ใน /etc/ipsec.secrets หากยังไม่มี สิ่งที่ไดอะล็อกถืออยู่คืออินพุตของไฟล์ที่สร้างขึ้น ไม่ใช่ค่าที่ใช้งานจริง
ก่อนจะแก้อะไร ให้ไล่ดูว่ามีอะไรอยู่:
ipsec --version
sudo ls -l /etc/ipsec.d/*.secrets /etc/ipsec.d/ipsec.nm-l2tp.secrets 2>/dev/null
sudo grep -n "include" /etc/ipsec.secrets
ปลั๊กอินรุ่นเก่าเขียนไฟล์หนึ่งไฟล์ต่อการเชื่อมต่อ ตั้งชื่อตาม UUID ของการเชื่อมต่อ เช่น /etc/ipsec.d/nm-l2tp-ipsec-<uuid>.secrets การลบโปรไฟล์ในแอปเพล็ตไม่ได้ลบไฟล์นั้นอย่างน่าเชื่อถือ ถ้าไฟล์เก่าจากเซิร์ฟเวอร์ก่อนยังอยู่บนดิสก์และยังถูกนำเข้ามา เดมอนอาจเลือกความลับที่เป็นของโปรไฟล์ที่คุณเลิกใช้ไปแล้ว และการเชื่อมต่อก็ล้มเหลวทั้งที่ช่องที่เห็นอยู่ถูกต้อง
ทำความเข้าใจว่าการเปลี่ยนใน 1.2.12 ทำอะไรกับการอัปเกรด
ปลั๊กอินเวอร์ชัน 1.2.12 เปลี่ยนไฟล์ความลับแยกตามการเชื่อมต่อมาเป็นไฟล์ที่ใช้ร่วมกันไฟล์เดียว คือ /etc/ipsec.d/ipsec.nm-l2tp.secrets การอัปเกรดไม่ได้ล้างไฟล์เก่าที่ตั้งชื่อตาม UUID และบรรทัด include /etc/ipsec.d/*.secrets ที่มีอยู่ก็ยังดึงไฟล์เหล่านั้นเข้ามา เวอร์ชัน 1.2.16 เปลี่ยนวิธีจัดการข้อเสนอเริ่มต้น ไม่ใช่การจัดวางความลับ
ประวัติตรงนี้อธิบายว่าทำไมสองเครื่องที่ดูเหมือนมีโปรไฟล์เดียวกันจึงทำงานต่างกัน คีย์เหมือนกัน แต่ชุดไฟล์ที่เดมอนนำเข้ามาไม่เหมือนกัน เมื่อจะเอาข้อมูลที่ตกค้างออก ให้ย้ายไปพักไว้แทนการลบทิ้ง ยืนยันการเชื่อมต่อ แล้วค่อยลบเมื่อบันทึกสถานะที่ใช้งานได้แล้ว การเปลี่ยนชื่อไว้ทำให้กู้ค่าเก่ากลับมาได้ถ้าพบว่าปัญหาอยู่ที่อื่น
แยกอักขระที่รูปแบบการเก็บข้อมูลรับไว้ไม่ได้
เอกสารของ strongSwan เรื่องสตริงความลับที่แชร์กันระบุว่าค่าต้องไม่มีอักขระขึ้นบรรทัดใหม่หรือเครื่องหมายอัญประกาศคู่ คีย์ที่วางมาจากเอกสารอาจพาตัวใดตัวหนึ่งมาด้วยโดยที่ในไดอะล็อกปกติมองไม่เห็นความต่างเลย
ตั้งแต่ 1.2.12 ค่าที่เก็บไว้ไม่ใช่ข้อความธรรมดาอีกต่อไป ปลั๊กอินเข้ารหัส PSK เป็น base64 ก่อนถึงไฟล์ และบันทึกการออกจำหน่ายก็ยกการเข้ารหัสนี้เป็นเหตุผลที่เครื่องหมายอัญประกาศคู่ใช้ได้ในคีย์แล้ว ดังนั้นอัญประกาศที่พิมพ์ในช่องจึงแทนได้ แต่ไม่ใช่กับอักขระควบคุมทุกตัว
ความยาวเป็นข้อจำกัดอีกอย่าง ไม่มีค่าต่ำสุดสากลที่ใช้กับซอฟต์แวร์ L2TP/IPsec บางไคลเอนต์รับคีย์ที่สั้นกว่ายี่สิบอักขระ และบางเกตเวย์บังคับค่าต่ำสุด ถ้าคีย์สั้นถูกปฏิเสธ กฎนั้นเป็นของนโยบายเซิร์ฟเวอร์หรือการตรวจสอบของไคลเอนต์ตัวนั้น และการไปเพิ่มอะไรในเครื่องก็ไม่ทำให้เปลี่ยน
อ่านว่าชั้นพิสูจน์ตัวตนชั้นไหนล้มเหลว
รัน ipsec --version ก่อน เพราะ strongSwan กับ Libreswan ใช้ชื่อไฟล์และไวยากรณ์ต่างกัน และคำแนะนำของตัวหนึ่งอาจทำให้อีกตัวเสียหายได้ จากนั้นอ่านขั้นที่ล้มเหลวจากข้อความของไคลเอนต์หรือล็อกของเดมอน การบ่นเรื่องคีย์ที่แชร์ไว้ล่วงหน้าเป็นคนละเหตุการณ์กับชื่อผู้ใช้และรหัสผ่านที่ถูกปฏิเสธ
PSK พิสูจน์ตัวตนปลายทั้งสองของอุโมงค์ ส่วนชื่อผู้ใช้และรหัสผ่านพิสูจน์ตัวตนคนที่อยู่ภายใน L2TP และ PPP จัดการหลังจากความสัมพันธ์ IPsec ขึ้นแล้ว PSK ที่ถูกต้องแต่บัญชีผิดก็ยังล้มเหลว และการเปลี่ยนบัญชีก็ไม่ได้ซ่อมคีย์ที่เดมอนไม่เคยอ่านถูก
เมื่อปิดตั๋ว ให้จดทั้งสี่อย่าง ได้แก่ เวอร์ชันปลั๊กอิน ไฟล์ความลับที่ใช้อยู่ คีย์นั้นพิมพ์ใหม่หรือวาง และชั้นที่ระบุในข้อผิดพลาด จากนั้นใครที่ทำเส้นทางนี้ซ้ำภายหลังจะกระโดดไปที่ความต่างระหว่างเครื่องที่ใช้งานได้กับเครื่องที่ล้มเหลวได้ทันที