Azure VPN Client 3.4 ตัดการเชื่อมต่อทุกชั่วโมง: ความถี่การลงชื่อเข้าใช้

ผู้ใช้หนึ่งคนเชื่อมต่อ ทำงาน แล้วถูกตัดการเชื่อมต่อชั่วโมงละครั้งพร้อมข้อความว่าการพิสูจน์ตัวตนกับ Microsoft Entra หมดอายุ การเชื่อมต่อใหม่ได้และวงจรก็วนซ้ำราวกับนาฬิกาจับเวลา บนเกตเวย์ point-to-site ที่ไม่ได้ติดตั้งสิ่งใด รูปแบบนั้นชี้ไปที่ ข้อมูลรับรอง ไม่ใช่อุโมงค์ Azure VPN Client 3.4.0 เริ่มบังคับใช้ความถี่การลงชื่อเข้าใช้ของการเข้าถึงตามเงื่อนไขระหว่างเซสชันที่สร้างไว้แล้ว นโยบายที่ไคลเอนต์รุ่นก่อนประเมินเฉพาะตอนลงชื่อเข้าใช้

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

ขั้นตอน 1: อ่านข้อความให้ตรง

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

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

ขั้นตอน 2: หาเวอร์ชันไคลเอนต์

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

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

ขั้นตอน 3: หาว่านโยบายอยู่ที่ใด

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

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

ขั้นตอน 4: คำนวณ

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

ถ้าความต่างไม่ตรงกับผลบวกนั้น สมมติฐานตารางเวลาผิด และควรหยุดปรับนโยบาย

ขั้นตอน 5: แยกตารางเวลาออกจาก rekey

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

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

ขั้นตอน 6: ติดตั้งโดยไม่ให้เซอร์ไพรส์

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

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