OpenVPN PAM: อาร์กิวเมนต์ login คือชื่อบริการ ไม่ใช่ชื่อผู้ใช้

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

คำที่สองเลือกอะไร

บรรทัดตั้งค่าฮับพาธปลั๊กอินและอาร์กิวเมนต์หนึ่งตัว:

plugin /usr/lib/openvpn/plugins/openvpn-plugin-auth-pam.so openvpn

อาร์กิวเมนต์นั้นถูกส่งให้ไลบรารี PAM เป็นชื่อบริการ ดังนั้นสแตกที่ /etc/pam.d/openvpn จึงเป็นตัวที่ทำงาน ถ้าเขียน login ลงไป จะได้นโยบายล็อกอินแบบโต้ตอบแทน พร้อมโมดูลต่าง ๆ ที่นโยบายนั้นบังเอิญรวมไว้ในดิสทริบิวชันของคุณ

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

สแตกอ่านบัญชีจากที่ใดจริง ๆ

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

อ่านไฟล์ที่ชื่อบริการชี้ไป รวมถึงทุกอย่างที่ไฟล์นั้นดึงเข้ามา:

cat /etc/pam.d/openvpn
grep -H pam_ /etc/pam.d/openvpn /etc/pam.d/common-auth

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

หนึ่งความพยายาม สองบันทึก

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

journalctl -u openvpn-server@server --since "-2 min"
journalctl -t sshd -t sudo --since "-2 min"

ทดสอบบริการโดยตรงด้วยยูทิลิตีที่พูดภาษา PAM เพื่อที่คุณจะไม่ต้องดีบักทั้ง VPN และสแตกพร้อมกัน การทดสอบโดยตรงที่สำเร็จด้วยชื่อบริการและบัญชีเดียวกันทำให้ปัญหาจำกัดอยู่ที่วิธีที่เดมอนส่งข้อมูลรับรอง ไม่ใช่ที่ตัวบัญชี

pamtester openvpn alice authenticate

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

บริการเฉพาะทางดีกว่าการแก้ login

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

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

ไคลเอนต์ส่งอะไร และไม่ส่งอะไร

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

ชื่อผู้ใช้และรหัสผ่านอยู่ร่วมกับใบรับรองไคลเอนต์ได้ และการเปิด PAM ไม่ใช่เหตุผลที่จะหยุดตรวจสอบใบรับรอง รักษาชั้นต่าง ๆ ตามที่การติดตั้งตั้งใจไว้ และแก้เฉพาะแหล่งบัญชี

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