เกตเวย์ Juniper หรือ Pulse: ควรใช้โปรโตคอล OpenConnect ใด

การเลือกโปรโตคอลสำหรับ OpenConnect เป็นการฝึกจับคู่ ไม่ใช่การค้นหาแบรนด์ เกตเวย์ที่เขียนว่า Juniper บนหน้าเข้าสู่ระบบอาจให้บริการ Network Connect, Pulse หรือทั้งสองอย่าง และค่าเริ่มต้นของไคลเอนต์ไม่ใช่ทั้งสองแบบ การเดาจะทำให้การเข้าสู่ระบบล้มเหลว และแย่กว่านั้นคือเกิดกระทู้สนับสนุนที่โทษข้อมูลรับรองว่าผิดทั้งที่ปัญหาเป็นความไม่ตรงกันของโปรโตคอล ยืนยันบริการก่อนพิมพ์ชื่อโฮสต์ลงในโปรไฟล์

OpenConnect เรียกโปรโตคอลเก่าว่า nc และตัวใหม่ว่า pulse และทั้งคู่อาศัยอยู่ในไบนารีเดียวกัน แฟล็กที่คุณเลือกเปลี่ยนการแลกเปลี่ยนตอนเข้าสู่ระบบ ไม่ใช่การกำหนดเส้นทางหลังเชื่อมต่อสำเร็จ

ชื่อโปรโตคอลทั้งสองใช้ประวัติผลิตภัณฑ์ร่วมกัน

Network Connect ของ Juniper และไคลเอนต์ Pulse Secure รุ่นหลังเป็นโปรโตคอลที่ต่างกันซึ่งตระกูลอุปกรณ์หนึ่งเปิดให้ใช้มาเป็นเวลา OpenConnect พัฒนาตัวจัดการ nc สำหรับตัวแรกและตัวจัดการ pulse สำหรับตัวที่สอง ทั้งสองเป็นเส้นทางโค้ดแยกกันและรูปแบบคำขอแยกกัน การรองรับอันหนึ่งจึงไม่บอกอะไรเกี่ยวกับอีกอัน

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

การเลือกบนบรรทัดคำสั่งเป็นการเปลี่ยนหนึ่งคำ คือ openconnect --protocol=nc vpn.example.com สำหรับ Network Connect หรือ openconnect --protocol=pulse vpn.example.com สำหรับ Pulse ทั้งสองความพยายามเป็นการเชื่อมต่อจริงที่กำหนดเส้นทางและ DNS ใหม่ได้ จึงต้องตั้งใจรัน ห้ามใส่รหัสผ่านบนบรรทัดคำสั่งหรือปิดการตรวจสอบใบรับรองเพื่อข้ามข้อผิดพลาดของโปรโตคอล เพราะนั่นซ่อนความไม่ตรงกันแทนที่จะแก้ไข ถ้าต้องดูว่าไคลเอนต์ส่งอะไร --dump-http-traffic จะพิมพ์การแลกเปลี่ยน ซึ่งมักระบุตัวจัดการที่เกตเวย์คาดไว้

จับคู่โปรโตคอลกับสิ่งที่เกตเวย์เปิดให้ใช้

อุปกรณ์ตอบเฉพาะโปรโตคอลที่กำหนดค่าไว้ บริการแบบ Pulse เท่านั้นจะปฏิเสธการเข้าสู่ระบบด้วย nc แม้ข้อมูลรับรองจะถูกต้อง และบริการ Network Connect เก่าไม่มีจุดปลายทาง pulse ให้ตอบ ถามผู้ดูแลระบบว่าเปิดใช้อันใดและรองรับไคลเอนต์ตัวไหน อุปกรณ์ที่เปลี่ยนชื่อ หน้า wiki ที่ล้าสมัย และพอร์ทัลเว็บที่คุ้นเคยล้วนเป็นหลักฐานอ่อน

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

การยืนยันตัวตนอาจตอบคำถามได้ก่อนโปรโตคอล

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

การเลือกกลุ่ม auth เป็นจุดสะดุดทั่วไปอีกจุด เพราะเกตเวย์ที่มีหลายกลุ่มคาดว่าไคลเอนต์จะระบุกลุ่มหนึ่ง

บนบรรทัดคำสั่ง --authgroup="Employees" ให้ตัวเลือกนั้น และการละเว้นอาจทำให้เซสชันไปอยู่ในกลุ่มเริ่มต้นที่ปฏิเสธบัญชี เมื่อใช้ใบรับรอง --certificate ชี้ไปที่ใบรับรองและกุญแจของไคลเอนต์ และเกตเวย์อาจยังต้องใช้โทเคนหลังจากนั้น ทดสอบลำดับทั้งหมดหนึ่งครั้งด้วยเอาต์พุตแบบละเอียดก่อนจะทำอะไรอัตโนมัติรอบ ๆ

เมื่อส่วนหน้าเดสก์ท็อปไม่สามารถแสดงตัวเลือกได้

ส่วนหน้าแบบกราฟิกมีชุดคุณสมบัติของตนเอง และปลั๊กอินเก่าอาจเก่ากว่าโปรโตคอลที่คุณต้องการ การผสานรวม OpenConnect ของ NetworkManager เก็บตัวเลือกไว้ในข้อมูลการเชื่อมต่อ nmcli connection modify "Office VPN" vpn.data "protocol=pulse" จึงตั้งค่าสิ่งที่ตัวแก้ไขไม่แสดงได้ ตรวจสอบว่าเวอร์ชันปลั๊กอินที่ติดตั้งรองรับคีย์นั้นก่อนถือว่าการแก้ไขมีผล

ถ้าเมนูมีเพียง PPTP หรือ L2TP การเลือกอย่างใดอย่างหนึ่งไม่ได้เปลี่ยนบริการ Pulse ให้เป็นโปรโตคอลนั้น ติดตั้งการผสานรวมที่ได้รับอนุมัติแทนการเปลี่ยนไปใช้สิ่งที่เมนูบังเอิญระบุ

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

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

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