OpenConnect ควรลองเชื่อมต่อ VPN ที่หลุดนานแค่ไหน?

--reconnect-timeout ตอบคำถามแคบ ๆ ข้อเดียว: หลังอุโมงค์ล่ม โปรเซสไคลเอนต์นี้จะลองต่อไปอีกนานแค่ไหนก่อนยอมแพ้และออก หน้าคู่มือของ OpenConnect บันทึกตัวเลือกนั้นโดยมีค่าเริ่มต้นที่เอกสารระบุไว้ 300 วินาทีสำหรับการลองใหม่ที่ตามมาหลังลิงก์หายหรือคู่ค้าที่หยุดตอบ และตัวเลขนี้เป็นเส้นตายสำหรับไคลเอนต์ที่ทำงานอยู่หนึ่งตัว ไม่ใช่หลักฐานว่า VPN ยังเข้าถึงได้ มันยังไม่ใช่นโยบายในการทำให้โปรเซสมีชีวิตอยู่ และความสับสนส่วนใหญ่ก็เริ่มต้นตรงนั้น

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

หน้าต่างเชื่อมต่อใหม่จำกัดอะไรจริง ๆ

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

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

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

การรีสตาร์ตของผู้ดูแลและการลองใหม่ของไคลเอนต์เป็นสองชั้น

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

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

sudo openconnect --background --pid-file=/run/openconnect/vpn.pid \
  --reconnect-timeout=180 \
  --user=<account> https://vpn.example.edu

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

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

ป้องกันการส่งต่อไม่ให้แข่งกับการวนลองใหม่

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

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

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

สิ่งที่ต้องตรวจสอบระหว่างและหลังการขัดข้อง

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

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

curl -sS --max-time 5 -o /dev/null -w '%{http_code}\n' https://intranet.example.internal/health
cat /run/openconnect/vpn.pid
ps -o pid,etime,cmd -p "$(cat /run/openconnect/vpn.pid)"

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

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