คุณควรลงทะเบียนที่อยู่ใดเป็นไคลเอนต์ RADIUS ของ NPS
ลงทะเบียนที่อยู่ต้นทางจริงของแบ็กเอนด์เกตเวย์ ไม่ใช่ชื่อโฮสต์สาธารณะหรือพูลไคลเอนต์ จับคู่ shared secret แล้วยืนยันด้วยคำขอที่ควบคุมได้หนึ่งครั้ง
เกตเวย์ VPN ที่มอบหมายการตรวจสอบสิทธิ์ให้ Windows NPS ต้องมีวัตถุหนึ่งรายการฝั่ง NPS ก่อนที่นโยบายผู้ใช้ใด ๆ จะทำงานได้ นั่นคือรายการไคลเอนต์ RADIUS สำหรับเกตเวย์ ความพยายามที่ล้มเหลวส่วนใหญ่ลงทะเบียนที่อยู่ผิด เพราะที่อยู่ที่สำคัญคือที่อยู่ที่เกตเวย์ใช้บนเส้นทางแบ็กเอนด์ ไม่ใช่ชื่อโฮสต์ที่พนักงานพิมพ์ลงในแอป VPN ของตน หากค่าตรงนั้นผิด NPS จะทิ้งคำขออย่างเงียบ ๆ ซึ่งดูเหมือนรหัสผ่านผิดจากฝั่งไคลเอนต์ มีเงื่อนไขสามข้อที่กำหนดว่าที่อยู่ใดควรอยู่ในช่องนี้ ดังนั้นจงหาข้อสรุปให้ได้ก่อนเปิดคอนโซล
ลงทะเบียนเกตเวย์ ไม่ใช่แล็ปท็อปหรือพูล
วัตถุไคลเอนต์ RADIUS แทนอุปกรณ์เข้าถึงเครือข่ายที่ส่งคำขอตรวจสอบสิทธิ์ นั่นคือเกตเวย์ VPN ไม่ใช่แล็ปท็อปทุกเครื่องที่รันไคลเอนต์ และไม่ใช่ช่วงที่อยู่ที่แจกจ่ายภายในอุโมงค์
ที่อยู่ในอุโมงค์เหล่านั้นไม่เคยปรากฏเป็นต้นทางของคำขอ RADIUS เพราะคำขอเดินทางผ่านเส้นทางเครือข่ายของเกตเวย์เอง การลงทะเบียนรายการพูลไคลเอนต์ทำให้เกิดนโยบายที่ไม่สามารถตรงกับคำขอใดได้เลย ขณะที่คำขอจริงมาจากที่อยู่ที่ NPS ไม่เคยรู้จัก ความสับสนแบบเดียวกันนี้ทำให้ผู้คนเพิ่ม IP บ้านของพนักงานแต่ละคน ซึ่งทั้งดูแลรักษาไม่ได้และผิด
สามเงื่อนไขกำหนดที่อยู่ที่คุณกรอก
ข้อแรก หาที่อยู่ต้นทางที่เกตเวย์ใช้จริงไปยัง NPS เกตเวย์ที่มีหลายอินเทอร์เฟซมักส่งจากอินเทอร์เฟซจัดการหรือแบ็กเอนด์แทนที่จะเป็นตัวรับฟัง VPN สาธารณะ ข้อที่สอง ตรวจสอบว่ามี NAT ระหว่างสองฝั่งหรือไม่ หากคำขอถูกแปลง NPS จะเห็นที่อยู่ที่แปลงแล้ว และนั่นคือค่าที่ต้องลงทะเบียน ข้อที่สาม หากเกตเวย์สองเครื่องแบ่งบทบาทกัน แต่ละต้นทางของคำขอต้องมีรายการไคลเอนต์ของตัวเอง เพราะวัตถุเดียวที่มีที่อยู่เดียวครอบคลุมได้เพียงเครื่องเดียว
บันทึกสองปลายทางช่วยให้จับคู่ได้ตรง ตารางด้านล่างใช้ที่อยู่ส่วนตัวเพื่อเป็นตัวอย่าง ดังนั้นให้แทนที่ด้วยที่อยู่ที่เส้นทางของคุณใช้จริง
| At NPS | At the VPN gateway |
|---|---|
| RADIUS client address 10.20.0.10 | Authentication server 10.20.0.20 |
| Shared secret, agreed value | The same secret, same value |
| UDP 1812 permitted from 10.20.0.10 | UDP 1812 permitted toward 10.20.0.20 |
ยืนยันต้นทางแทนการเดา ดูบันทึกของ NPS หรือไฟร์วอลล์ระหว่างการพยายามหนึ่งครั้ง หรือดักจับบนโฮสต์ NPS ด้วย sudo tcpdump -ni any udp port 1812 ที่อยู่ในผลการดักจับนั้นคือคำตอบเดียวที่ป้องกันได้สำหรับรายการไคลเอนต์ หากเกตเวย์มีต้นทางที่เป็นไปได้หลายทาง ให้ลงทะเบียนแต่ละทางภายใต้ชื่อที่เป็นมิตรของตัวเอง
shared secret คือค่าระหว่างเกตเวย์กับ NPS
shared secret ตรวจสอบสิทธิ์ความสัมพันธ์ระหว่างอุปกรณ์ ไม่ใช่รหัสผ่านผู้ใช้ และไม่เคยแจกจ่ายให้พนักงานหรือฝังในโปรไฟล์ไคลเอนต์
เลือกค่าเดียว กรอกในทั้งสองที่ และเก็บไว้ที่เดียวกับที่เก็บข้อมูลสำรองการกำหนดค่าของเกตเวย์ หากไม่ตรงกันจะเกิดคำขอที่ NPS ทิ้งโดยไม่มีข้อผิดพลาดที่เป็นประโยชน์ ซึ่งแยกไม่ออกจากเซิร์ฟเวอร์ที่เข้าถึงไม่ได้ในบันทึกของเกตเวย์ หมุนเวียนค่าในช่วงหน้าต่างบำรุงรักษาและอัปเดตทั้งสองฝั่งในการเปลี่ยนแปลงครั้งเดียวกัน
ยืนยันด้วยคำขอที่ได้รับอนุญาตหนึ่งครั้ง
ใช้บัญชีที่ควบคุมได้และเชื่อมโยงความพยายามครั้งเดียวทั้งสองฝั่ง ที่เกตเวย์ ยืนยันว่าคำขอออกไปยังเซิร์ฟเวอร์ที่ตั้งใจไว้ ที่ NPS ยืนยันว่าคำขอมาถึงจากไคลเอนต์ที่ลงทะเบียนและตรงกับนโยบายคำขอเชื่อมต่อที่คาดไว้ การหมดเวลาและการถูกปฏิเสธมีความหมายต่างกัน และการถือว่าทั้งสองเป็นปัญหาข้อมูลรับรองจะทำให้ชั่วโมงถัดไปสูญเปล่า จากนั้นทดสอบบัญชีที่ถูกต้องแต่ไม่มีสิทธิ์และรหัสผ่านผิด เพราะนโยบายที่ยอมรับทุกอย่างก็ผ่านการทดสอบแรกเช่นกัน
สุดท้าย ตรวจสอบว่าเกตเวย์ทำอะไรกับสิทธิ์ที่ส่งกลับมา การลงทะเบียนไคลเอนต์ RADIUS เพียงอนุญาตให้อุปกรณ์เข้าร่วมเท่านั้น ไม่ได้ให้สิทธิ์การเข้าถึง LAN แก่ทุกเซสชันที่เกิดขึ้น
จำกัดขอบเขตผลการวินิจฉัย ไม่มี shared secret ไม่มีรหัสผ่านผู้ใช้ ไม่มีเพย์โหลดแพ็กเก็ตเต็มในตั๋วสนับสนุน หากการออกแบบกำหนดให้เซิร์ฟเวอร์ NPS อ่านแอตทริบิวต์ไดเรกทอรี สิทธินั้นเป็นงานธุรการแยกต่างหากจากการลงทะเบียนไคลเอนต์ และจะล้มเหลวในแบบที่ต่างออกไปเมื่อไม่มี