ทำไมการเข้าสู่ระบบ openfortivpn จึงล้มเหลวเมื่อคุณวาง URL ของพอร์ทัล

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

ที่อยู่พอร์ทัล Fortinet อย่าง https://vpn.example.com/ext พาข้อมูลหลายส่วนมาพร้อมกัน และมีเพียงบางส่วนเท่านั้นที่เป็นของไคลเอนต์ VPN

จุดปลายทางและ realm เป็นอินพุตแยกกัน

openfortivpn คาดหวังจุดปลายทางในรูปแบบ host หรือ host:port พร้อมบัญชี และค่า realm หากการติดตั้งใช้งานค่าดังกล่าว realm บอกเกตเวย์ว่าจะใช้นโยบายการพิสูจน์ตัวตนแบบใดก่อนประเมินบัญชี นี่เป็นฟิลด์แยก ไม่ใช่ส่วนต่อท้ายที่ไคลเอนต์ดึงออกมาจาก URL

สำหรับการติดตั้งที่ผู้ดูแลยืนยันว่า realm คือ ext การเรียกที่ไม่เป็นความลับมีลักษณะเช่นนี้: openfortivpn vpn.example.com:443 --username=alice --realm=ext ค่าเดียวกันอยู่ในไฟล์กำหนดค่าเป็นรายการ host, port, username และ realm ปล่อยรหัสผ่านไว้นอกทั้งสองรูปแบบและให้ไคลเอนต์ถามเอา เพื่อไม่ให้ไปอยู่ในประวัติเชลล์หรือไฟล์ที่ทุกคนอ่านได้ การพยายามครั้งที่สองในขณะที่ไคลเอนต์แรกยังคงถืออุโมงค์อยู่จะล้มเหลวด้วยเหตุผลที่ไม่เกี่ยวข้องกับ realm เลย

คู่มือ openfortivpn แสดงทั้งสองตัวเลือก ดังนั้นการตรวจสอบการสะกดที่แน่นอนจึงทำได้ง่ายก่อนโทรหาฝ่ายสนับสนุน อย่างไรก็ตาม คู่มือไม่สามารถบอกได้ว่าเกตเวย์ของคุณกำหนดค่า realm ใดไว้

ส่วนของเส้นทางไม่ใช่ realm โดยอัตโนมัติ

URL ของพอร์ทัลรวบรวมสิ่งต่างๆ ไว้หลังชื่อโฮสต์ เช่น แอปพลิเคชันเข้าสู่ระบบ ตัวเลือกภาษา เป้าหมายการเปลี่ยนเส้นทาง ตัวระบุเซสชัน การตัดส่วนเส้นทางสุดท้ายออกแล้วเรียกมันว่า realm ได้ผลบ่อยพอที่จะเป็นอันตราย ถามผู้ดูแลเกี่ยวกับค่าที่กำหนดไว้ หรืออ่านจากโปรไฟล์ที่องค์กรของคุณแจกจ่าย

realm ไม่ใช่สิ่งเดียวกับส่วนต่อท้ายโดเมนในชื่อผู้ใช้หรือภูมิภาคที่เกตเวย์ตั้งอยู่ การติดตั้งบางแห่งต้องการ alice บางแห่งต้องการ alice@corp และ realm เป็นตัวกำหนดว่าเกตเวย์จะยอมรับอันใด การเปลี่ยนรูปแบบบัญชีเพื่อชดเชย realm ที่ผิดมักให้ผลเป็นการปฏิเสธครั้งที่สองที่มีข้อมูลน้อยกว่า

อย่าแก้ข้อผิดพลาดของ realm ด้วยการเปลี่ยนโฮสต์

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

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

แยกการเข้าสู่ระบบที่ถูกปฏิเสธออกจากอุโมงค์ที่ล้มเหลว

ความล้มเหลวของการพิสูจน์ตัวตนและความล้มเหลวของอุโมงค์เกิดขึ้นต่างเวลา และข้อความก็ต่างกัน ข้อผิดพลาดในการแปลงชื่อเกิดก่อนการจับมือ TLS ใดๆ การปฏิเสธ TLS เกิดก่อนส่งข้อมูลรับรอง การปฏิเสธ realm หรือบัญชีกลับมาเป็นคำตอบระดับ HTTP จากพอร์ทัล เฉพาะหลังจากขั้นตอนเหล่านั้นการเจรจา PPP จึงเริ่ม และเฉพาะตอนนั้น ปัญหาการกำหนดเส้นทางและ DNS จึงปรากฏขึ้น

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

เก็บค่าไว้ในที่ที่การเปิดครั้งต่อไปจะพบ

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

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