การเข้าสู่ระบบ OpenConnect ไปโผล่ที่หน้าผิดหรือเปล่า? ตรวจเส้นทางก่อน

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

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

ไคลเอนต์ส่งอะไรก่อนที่คุณจะเห็นแบบฟอร์ม

ด้วยที่อยู่อย่าง https://vpn.example.net/partners การกระทำแรกของไคลเอนต์คือคำขอ HTTPS ไปที่เส้นทางนั้น ไม่ใช่ไปที่โฮสต์เปล่า สิ่งที่ตอบกลับมามักเป็นการเปลี่ยนเส้นทางไปยังจุดเข้าสู่ระบบ หรือตัวแบบฟอร์มเอง ไคลเอนต์ที่ได้เพียง vpn.example.net จะเริ่มที่หน้าแรกเริ่มต้นที่มีอยู่ ซึ่งอาจเป็นพอร์ทัลอื่น รายการกลุ่มอื่น หรือหน้าที่คาดหวังโปรโตคอลที่ต่างออกไปโดยสิ้นเชิง ความแตกต่างปรากฏในส่วนหัวการตอบกลับนานก่อนที่จะมีการพิมพ์ข้อมูลรับรองใด ๆ

นั่นคือเหตุผลที่แท็บเบราว์เซอร์ที่ใช้งานได้กับโปรไฟล์ไคลเอนต์ที่ล้มเหลวสามารถระบุเกตเวย์เดียวกันแต่ยังไม่ตรงกันได้ เบราว์เซอร์ตามเส้นทางไป ส่วนโปรไฟล์ไม่เคยมีเส้นทางนั้น

อินพุตสองตัวที่ดูเหมือนใช้แทนกันได้และไม่ได้เป็นเช่นนั้น

OpenConnect เปิดเผยเส้นทาง HTTPS เริ่มต้นเป็น --usergroup และ หน้าคู่มือ ถือว่า URL แบบเต็มที่มีเส้นทางนั้นเป็นคำขอเดียวกันที่เขียนต่างออกไป --authgroup เป็นตัวเลือกแยกต่างหาก มันเลือกหนึ่งรายการจากรายการที่เกตเวย์แสดงภายในแบบฟอร์มเข้าสู่ระบบ บางโปรโตคอลเรียกรายการนั้นว่ากลุ่ม บางตัวเรียกว่าโดเมนหรือเกตเวย์ และนั่นคือจุดที่แฟล็กสองตัวสับสนกัน

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

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

ทำไมการตัดเส้นทางออกจึงเปลี่ยนผลลัพธ์

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

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

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

ยืนยันจุดเริ่มต้นก่อนแก้ไขสิ่งอื่น

อ่านส่วนหัวของเส้นทางที่ได้รับ คำขออย่าง curl -sS -o /dev/null -D - https://vpn.example.net/partners พิมพ์บรรทัดสถานะและส่วนหัว Location ใด ๆ โดยไม่ตามการเปลี่ยนเส้นทาง 302 ที่ชี้ไปยังจุดเข้าสู่ระบบที่มีชื่อยืนยันว่าเส้นทางนั้นมีอยู่และแสดงว่าไปที่ไหน 404 หมายความว่าที่อยู่ของผู้ดูแลระบบล้าสมัย

จากนั้นทำซ้ำจุดเริ่มต้นเดิมในไคลเอนต์ที่ได้รับอนุมัติ เช่น openconnect --usergroup=partners vpn.example.net และดูว่าแบบฟอร์มใดปรากฏ หากแบบฟอร์มถูกต้องแต่อุโมงค์ยังล้มเหลว แสดงว่าเส้นทางไม่เคยเป็นปัญหา และจุดต่อไปคือนโยบายหรือการกำหนดเส้นทาง

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