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

การตรวจสอบที่หนึ่ง: อ่านว่าการรับรองความถูกต้องหยุดที่ใด

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

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

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

การตรวจสอบที่สอง: ใช้ไคลเอนต์ที่เป็นเจ้าของการท้าทาย

OpenConnect เองรองรับบทสนทนาทั้งหมด รวมถึงรอบการท้าทาย การเรียกใช้โดยตรงเป็นวิธีที่คาดเดาได้มากที่สุดในการยืนยันว่าบัญชีและเกตเวย์ทำงาน:

sudo openconnect --protocol=anyconnect --useragent=AnyConnect vpn.example.net

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

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

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

การตรวจสอบที่สาม: ดูว่าปลั๊กอินของคุณมีโหมด TOTP หรือไม่

บิลด์ NetworkManager OpenConnect บางตัวมีโหมดโทเค็นและช่องยูสเซอร์เอเจนต์ในแท็บ Identity ของการเชื่อมต่อ ตั้งยูสเซอร์เอเจนต์เป็นค่าที่เกตเวย์คาดหวัง เลือกการป้อน TOTP ด้วยตนเอง และบันทึกการเชื่อมต่อ

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

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

การตรวจสอบที่สี่: มองรหัสที่สร้างขึ้นเป็นข้อแลกเปลี่ยน

สคริปต์สามารถเรียก oathtool สำหรับรหัสปัจจุบันและส่งชื่อผู้ใช้ รหัสผ่าน และรหัสเข้า nmcli connection up --ask ลำดับนี้ทำงานได้ แต่ข้อมูลลับที่แชร์กันจะถูกเก็บไว้ที่ใดที่หนึ่งซึ่งใครก็ตามที่เปิดสคริปต์ได้สามารถอ่านได้ และผู้อ่านนั้นสามารถสร้างรหัสได้ตลอดไป นี่คือการขยายพื้นผิวข้อมูลรับรองอย่างถาวร ไม่ใช่การแก้ไขไคลเอนต์

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

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

ยืนยันเกตเวย์และบัญชีเดียวกัน

ทดสอบทุกวิธีเลี่ยงกับเกตเวย์เดียวกัน บัญชีเดียวกัน และกลุ่มอุโมงค์เดียวกัน เกตเวย์ที่ต้องการใบรับรองอุปกรณ์ด้วย อาจปฏิเสธไคลเอนต์บรรทัดคำสั่งด้วยเหตุผลที่ไม่เกี่ยวกับ TOTP และลำดับคำขออาจต่างจากที่ฝึกไว้

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

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

บทความที่เกี่ยวข้อง