การเข้าสู่ระบบ VPN ไปถึง RADIUS และผู้ให้บริการข้อมูลระบุตัวตนของคุณได้อย่างไร
ติดตามการเข้าสู่ระบบ VPN จากไคลเอนต์ไปยังคำขอ RADIUS ของเกตเวย์ ผู้ให้บริการข้อมูลระบุตัวตนที่อยู่เบื้องหลัง และนโยบายที่ใช้หลังการยอมรับ
สัปดาห์ที่แล้วผู้ใช้สามารถเข้าสู่ระบบ VPN ได้แต่กลับไปจบลงในเครือข่ายที่ไม่มีอะไรถูกแก้ไข ไคลเอนต์บอกว่าเชื่อมต่อแล้ว บันทึกของเกตเวย์บอกว่า Access-Accept และทีมข้อมูลระบุตัวตนบอกว่าบัญชีปกติดี การเข้าสู่ระบบทำงานแล้ว แต่การอนุญาตที่อยู่เบื้องหลังไม่ได้ทำงาน เมื่อการเข้าสู่ระบบ VPN ล้มเหลว ผมจะเดินตามเส้นทางที่คำขอเดินจริง — ไคลเอนต์ เกตเวย์ เซิร์ฟเวอร์ RADIUS ผู้ให้บริการข้อมูลระบุตัวตน — และหยุดที่จุดแรกที่คำตอบไม่สอดคล้องกับจุดถัดไป
ไคลเอนต์ไม่เคยพูด RADIUS
ไม่ว่าแอปบนแล็ปท็อปจะแสดงอะไร จุดแรกของมันคือโปรโตคอล VPN: IKEv2, OpenVPN, WireGuard หรือไคลเอนต์ที่ใช้ TLS RADIUS ไม่ปรากฏในการแลกเปลี่ยนนั้น ไคลเอนต์พิสูจน์ตัวตนกับเกตเวย์ด้วยใบรับรอง ชื่อผู้ใช้และรหัสผ่าน หรือวิธี EAP ที่บรรทุกอยู่ในการตั้งค่าอุโมงค์
เรื่องนี้สำคัญเมื่ออ่านบันทึก เพราะข้อผิดพลาดการพิสูจน์ตัวตนทั่วไปที่ผู้ใช้เห็นนั้นเกตเวย์สร้างขึ้นหลังจากที่มันได้คุยกับอย่างอื่นแล้ว หากไคลเอนต์ไม่เคยไปถึงเกตเวย์ ก็ไม่มีคำขอ RADIUS ให้แก้ไข และหนึ่งชั่วโมงที่ใช้บนเซิร์ฟเวอร์ RADIUS ก็สูญเปล่า ยืนยันว่าอุโมงค์เกิดขึ้นจริงก่อนที่จะแตะส่วนหลัง
เกตเวย์คือไคลเอนต์ RADIUS
เมื่อการตั้งค่าอุโมงค์ไปถึงจุดที่ต้องตรวจสอบข้อมูลประจำตัว เกตเวย์จะกลายเป็นเซิร์ฟเวอร์การเข้าถึงเครือข่าย มันสร้าง Access-Request: User-Name รหัสผ่านหรือเพย์โหลด EAP, NAS-IP-Address หรือ NAS-Identifier และ Message-Authenticator เมื่อวิธีนั้นต้องการ คำขอไปที่ UDP 1812 โดยค่าเริ่มต้น และการบัญชีไปที่ 1813 การติดตั้งเก่ายังใช้ 1645 และ 1646 ดังนั้นกฎไฟร์วอลล์ที่เขียนสำหรับคู่หนึ่งจึงอธิบายความล้มเหลวเงียบ ๆ ได้หลายอย่าง
ทั้งสองฝ่ายใช้ความลับร่วมกัน และมันไม่ใช่ข้อมูลประจำตัวผู้ใช้ มันลงนามในการแลกเปลี่ยน และทุกคำตอบจะถูกตรวจสอบกับมัน ตั้งค่าความลับต่างกันในสองฝ่ายแล้วเซิร์ฟเวอร์จะไม่ตอบว่าความลับผิด — มันทิ้งคำขอหรือคำตอบไม่ผ่านการตรวจสอบ ดังนั้นเกตเวย์จึงรายงานว่าหมดเวลา ความลับผิดกับเซิร์ฟเวอร์ที่ตายแล้วดูเหมือนกันจากเกตเวย์ ดังนั้นผมจึงทดสอบจุดนั้นด้วยเครื่องมือไคลเอนต์ก่อนที่จะโทษไดเรกทอรี
โปรโตคอลมีขนาดเล็กและเก่า — RFC 2865 กำหนดการแลกเปลี่ยนการพิสูจน์ตัวตน — แต่แอตทริบิวต์ที่มันบรรทุกคือรากฐานของนโยบาย VPN ส่วนใหญ่
# ask the RADIUS server directly, from the gateway host
radtest alice 'test-password' 127.0.0.1 0 testing123
# watch the exchange the gateway actually sends
tcpdump -ni any -c 20 'udp port 1812'เซิร์ฟเวอร์ RADIUS อาจเป็นเพียงด้านหน้าของผู้ให้บริการข้อมูลระบุตัวตน
ผู้คนพูดถึง RADIUS และผู้ให้บริการข้อมูลระบุตัวตนราวกับเป็นกล่องเดียวกัน บ่อยครั้งไม่ใช่ เซิร์ฟเวอร์ RADIUS รับ Access-Request แล้วถามสิ่งอื่นก่อนตอบ — Active Directory ผ่าน LDAP หรือ Kerberos ไฟล์ผู้ใช้ภายใน หรือบริการภายนอก FreeRADIUS ที่มีโมดูล LDAP หรือ krb5, Windows NPS และ Cisco ISE ต่างก็อยู่ในตำแหน่งนี้
ความแตกต่างนี้กำหนดว่าจะดูที่ไหน รหัสผ่านที่ถูกปฏิเสธคือคำตอบของผู้ให้บริการข้อมูลระบุตัวตนที่ RADIUS ส่งต่อ การหมดเวลามักเป็นช่วง RADIUS ถึงไดเรกทอรี: บัญชี bind ที่หมดอายุ ไดเรกทอรีที่เข้าถึงไม่ได้ หรือคำขอที่ถูกส่งไปยังส่วนหลังผิด หากชื่อผู้ใช้มีส่วนต่อท้ายโดเมน เซิร์ฟเวอร์อาจกำหนดเส้นทางตามนั้น และบัญชีเดียวกันที่ส่งเป็น CORP\alice และ [email protected] อาจไปจบคนละที่ ใน Windows NPS บันทึก Security บันทึก 6272 สำหรับการอนุญาตและ 6273 สำหรับการปฏิเสธ ซึ่งบอกว่าการตัดสินใจมาจาก NPS หรือไม่
อ่านความล้มเหลวที่จุดที่ทำให้เกิด
ข้อความเชื่อมต่อไม่ได้หนึ่งข้อความครอบคลุมความล้มเหลวที่แตกต่างกันสี่แบบ ก่อนเปลี่ยนอะไร ให้จับคู่อาการกับจุดที่ทำให้เกิด
| What you see | Where it comes from | First check |
|---|---|---|
| Gateway timeout, no reply | Shared secret mismatch, UDP 1812 blocked, unknown NAS, wrong server address | tcpdump at the gateway; radtest from the gateway host |
| Immediate reject | Credentials, account state, domain suffix, RADIUS policy | NPS 6273 or the FreeRADIUS auth log; test the account directly |
| Repeated challenge or MFA loop | Access-Challenge state not returned, or a token that expired mid-flow | Client prompt timing and the State attribute in debug output |
| Accept, then no access | Authorization attributes unmapped, wrong pool, route or ACL policy | Gateway policy and the attributes in the Access-Accept |
แถวสุดท้ายคือแถวที่ส่งคนไปหาทีมผิด Access-Accept หมายความว่าข้อมูลประจำตัวได้รับการยอมรับ ไม่ได้หมายความว่าเกตเวย์วางผู้ใช้ในพูลที่ถูกต้องหรือดันเส้นทาง แอตทริบิวต์กลุ่มมีความสำคัญก็ต่อเมื่อนโยบายของเกตเวย์อ่านมัน ผมเคยเห็นการเข้าสู่ระบบที่ถูกต้องไปจบในพูลแขกเพราะการแมปกลุ่มถูกตั้งค่าฝั่ง RADIUS สำหรับแอตทริบิวต์อื่นจากที่เกตเวย์ตรวจสอบ
ติดตามการเข้าสู่ระบบหนึ่งครั้งตั้งแต่ต้นจนจบ
เลือกบัญชีทดสอบหนึ่งบัญชีและเกตเวย์หนึ่งตัว แล้วสังเกตความพยายามเดียวกันที่ทั้งสี่จุด เริ่มการดีบักฝั่ง RADIUS — freeradius -X พิมพ์คำขอและทุกโมดูลที่มันแตะ — ติดตามบันทึกการพิสูจน์ตัวตนของเกตเวย์ และรัน tcpdump สำหรับการแลกเปลี่ยน UDP เชื่อมต่อหนึ่งครั้งแล้วอ่านร่องรอยทั้งสี่ตามลำดับ
สิ่งที่คุณต้องการเห็นคือความสอดคล้อง: เกตเวย์ถามถึงผู้ใช้ที่คุณคาดไว้ เซิร์ฟเวอร์ RADIUS เลือกส่วนหลังที่คุณคาดไว้ ส่วนหลังนั้นคืนการตัดสินใจ และแอตทริบิวต์ในคำตอบตรงกับนโยบายที่เกตเวย์ใช้ จุดแรกที่ร่องรอยไม่สอดคล้องคือเส้นแบ่งความผิดของคุณ หากคำตอบไม่มีแอตทริบิวต์กลุ่ม ปัญหาอยู่ฝั่ง RADIUS ไม่ใช่ในโปรไฟล์ VPN; หากแอตทริบิวต์อยู่และเกตเวย์เพิกเฉย ปัญหาคือนโยบายของเกตเวย์
บันทึกด้านความปลอดภัยหนึ่งข้อขณะอยู่ที่นั่น ความลับร่วมกันปกป้องการแลกเปลี่ยน แต่มันไม่ได้เข้ารหัสแอตทริบิวต์ส่วนใหญ่ หากเกตเวย์และเซิร์ฟเวอร์ RADIUS อยู่คนละเซกเมนต์ ให้วางจุดนั้นบน RADIUS ผ่าน TLS หรือเส้นทางส่วนตัว อุโมงค์ผู้ใช้ที่เข้ารหัสไม่ได้บอกอะไรเกี่ยวกับลิงก์ส่วนหลัง
ก่อนปิดตั๋ว ให้ยืนยันสี่สิ่ง เกตเวย์เข้าถึงเซิร์ฟเวอร์ RADIUS บนพอร์ตที่กำหนดไว้จริง ความลับร่วมกันตรงกันทั้งสองฝ่าย เซิร์ฟเวอร์ RADIUS แก้ไขรูปแบบชื่อผู้ใช้ที่แน่นอนที่เกตเวย์ส่ง การยอมรับมีแอตทริบิวต์ที่นโยบายของเกตเวย์ต้องการ เมื่อทั้งสี่ข้อเป็นจริง การเข้าสู่ระบบที่ยังล้มเหลวคือปัญหานโยบายของเกตเวย์ ไม่ใช่การพิสูจน์ตัวตน