ทำไม RADIUS จึงเห็นที่อยู่ IP แทนชื่อผู้ใช้ VPN

ไคลเอนต์ Windows IKEv2 เชื่อมต่อ และคำขอ RADIUS มาพร้อมที่อยู่ในตำแหน่งที่ควรเป็นชื่อบัญชี ยังไม่มีอะไรล้มเหลว และนั่นคือส่วนที่ทำให้สับสน: เกตเวย์รายงาน ข้อมูลระบุตัวตนที่ไคลเอนต์นำเสนอในชั้น IKE ชื่อผู้ใช้ที่แบ็กเอนด์ของคุณต้องการอาจมาจากการแลกเปลี่ยน EAP แยกต่างหากที่ยังไม่เกิดขึ้น ตัดสินใจว่าใครจะเป็นผู้ขอ ก่อนเปลี่ยนบัญชี

ข้อมูลระบุตัวตนสองอย่างเดินทางในหนึ่งการเชื่อมต่อ

ชื่อสองชื่อสามารถปรากฏในการเชื่อมต่อเดียว ข้อมูลระบุตัวตน IKE ระบุคู่สนทนาระหว่างการตั้งค่าอุโมงค์ และปลั๊กอิน eap-radius จะคัดลอกลงใน RADIUS User-Name ในตอนแรก ข้อมูลระบุตัวตน EAP เป็นค่าอีกค่าหนึ่ง ใช้สำหรับการพิสูจน์ตัวตนผู้ใช้ และอาจไม่ถูกส่งเลยหากไม่มีใครขอ

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

ขอให้เกตเวย์ร้องขอข้อมูลระบุตัวตน EAP

การตั้งค่าที่รองรับแบบหนึ่งให้เกตเวย์ขอข้อมูลระบุตัวตน EAP ก่อนส่งต่อการพิสูจน์ตัวตนให้ RADIUS ในส่วนการพิสูจน์ตัวตนระยะไกลของการเชื่อมต่อ ให้ตั้งค่าวิธีเป็น eap-radius และขอข้อมูลระบุตัวตน EAP อย่างชัดเจน ส่วนที่แสดงด้านล่างอยู่ภายในบล็อกการเชื่อมต่อที่มีอยู่ ไม่ใช่ในไฟล์ของตัวเอง ยืนยันการเชื่อมต่อและแบ็กเอนด์ของการกำหนดค่าก่อนคัดลอกไวยากรณ์จากอีกการติดตั้ง

remote {
    auth = eap-radius
    eap_id = %any
}

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

หรือปล่อยให้ RADIUS เริ่มการแลกเปลี่ยน EAP

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

charon {
    plugins {
        eap-radius {
            eap_start = yes
        }
    }
}

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

ติดตามความพยายามหนึ่งครั้งในทั้งสองบันทึก

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

journalctl -u strongswan -f

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

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