วิธีรัน OpenConnect เบื้องหลังหลังการเข้าสู่ระบบแบบโต้ตอบ
จบการเข้าสู่ระบบที่เบื้องหน้า แล้วมอบอุโมงค์ให้โหมดเบื้องหลังของไคลเอนต์เอง การตรวจสอบที่ทำให้ค้นหาและหยุดได้
คุณจบพรอมต์ MFA อุโมงค์ขึ้นมา และการปิดเทอร์มินัลก็พาการเชื่อมต่อลงไปด้วย นี่คือปัญหาการกำกับดูแล ไม่ใช่การรับรองความถูกต้อง และ OpenConnect มีสวิตช์ที่แก้ปัญหานี้อยู่แล้ว ทางแก้คือปล่อยให้ไคลเอนต์แยกไปเบื้องหลังเมื่อการเริ่มระบบเสร็จสิ้น เมื่อส่วนโต้ตอบจบลงจริง ๆ ต่อไปนี้คือลำดับการตรวจสอบ: ทำตามลำดับและหยุดที่ข้อแรกที่ไม่ตรงกับเกตเวย์ของคุณ
ยืนยันว่าเกตเวย์ต้องการอะไรตอนเข้าสู่ระบบ
ก่อนพิมพ์คำสั่ง จดเส้นทางข้อมูลรับรองที่การติดตั้งบังคับ เฉพาะใบรับรอง รหัสผ่านกับโทเค็น และการวนผ่านเบราว์เซอร์ผ่านผู้ให้บริการ SAML ทำงานต่างกัน และโหมดเบื้องหลังข้ามไม่ได้สักอย่าง ตัวเลือกนี้เปลี่ยนสิ่งที่เกิดขึ้นหลังการเริ่มระบบ ไม่เคยเปลี่ยนสิ่งที่เกิดขึ้นระหว่างนั้น
ทางลัดที่น่าดึงดูดคือทำให้พรอมต์เป็นอัตโนมัติ ตัวห่อที่พิมพ์คำตอบตายตัวเมื่อรู้จักพรอมต์รหัสผ่านจะพังทันทีที่เกตเวย์ขอรหัสใช้ครั้งเดียว และทิ้งข้อมูลรับรองไว้ในไฟล์ที่บัญชีอื่นอ่านได้ ถ้าต้องให้คนอนุมัติเซสชัน ก็ให้คนอยู่ในกระบวนการ
รันเซสชันแรกที่เบื้องหน้าและอ่านเอาต์พุต
เชื่อมต่อตามปกติหนึ่งครั้งและปล่อยให้แฮนด์เชกทั้งหมดพิมพ์ออกมา จดโปรโตคอลที่ใช้ เส้นทางใบรับรองหรือโทเค็น ที่อยู่ tunneling ที่เซิร์ฟเวอร์กำหนด และคำเตือนทุกข้อก่อนยอมรับการเชื่อมต่อ บันทึกนั้นคือเส้นฐานของคุณและเป็นวิธีถูกที่สุดในการแยกปัญหาของไคลเอนต์จากการเปลี่ยนแปลงของเกตเวย์ในภายหลัง เก็บไว้ นอกบัฟเฟอร์ของเทอร์มินัล
จากนั้นทำซ้ำคำสั่งเดิมโดยเพิ่มโหมดเบื้องหลังและไฟล์ PID เช่น openconnect --background --pid-file /run/openconnect.pid vpn.example.net และเก็บโปรโตคอลกับตัวเลือกการรับรองความถูกต้องที่เกตเวย์ต้องการไว้ในบรรทัดเดียวกัน คู่มือ OpenConnect อธิบายตัวเลือกนี้ว่าเป็นการทำงานต่อในเบื้องหลังหลังการเริ่มระบบเสร็จสิ้น และนั่นคือเหตุผลที่เฟสโต้ตอบต้องจบก่อน
ทำให้โปรเซสที่ทำงานอยู่ค้นหาและหยุดได้
ไฟล์ PID เป็นหลักฐานก็ต่อเมื่อตรงกับโปรเซสที่ยังมีชีวิต วางไว้ในไดเรกทอรีที่บัญชีบริการเป็นเจ้าของ และเปรียบเทียบหมายเลขที่บันทึกกับตารางโปรเซสก่อนส่งสัญญาณใด ๆ การรีบูตและการแครชทิ้งไฟล์ไว้ และไฟล์ที่เก่าคือสาเหตุปกติที่สคริปต์หยุดรายงานความสำเร็จในขณะที่อุโมงค์ยังทำงานอยู่ มองการตรวจสอบเป็นส่วนหนึ่งของขั้นตอนการหยุด ไม่ใช่ขั้นตอนเสริม
ส่งสัญญาณไปยัง PID ที่ตรวจสอบแล้ว จากนั้นยืนยันว่าอินเทอร์เฟซอุโมงค์หายไปจริงแทนที่จะเชื่อสถานะออก ถ้าไคลเอนต์ต้องใช้สิทธิ์สูงเพื่อกำหนดค่าอินเทอร์เฟซ สัญญาณต้องมาจากบัญชีที่ได้รับอนุญาตให้ส่ง
อย่าวางโหมดเบื้องหลังซ้อนใต้ตัวควบคุม
systemd และตัวควบคุมที่คล้ายกัน คาดว่าจะเป็นเจ้าของโปรเซสที่พวกมันเริ่ม ดังนั้นไคลเอนต์ที่แยกออกไปจึงทำให้สับสน ตัวควบคุมเห็นตัวเรียกออกไปในขณะที่การเชื่อมต่อจริงยังอยู่ ตรรกะการรีสตาร์ต การรายงานสถานะ และเวลาหมดเวลาหยุดจึงอธิบายสิ่งที่ไม่มีจริงอีกต่อไป เขียนยูนิตในการจัดวางแบบเบื้องหน้าที่รองรับ และปล่อยให้ตัวควบคุมทำงานของดีมอน
สงวน --background ไว้สำหรับเซสชันที่คนเริ่มแล้วจากไป ถ้าความต้องการคืออุโมงค์ที่มีอยู่ก่อนใครจะล็อกอิน ชิ้นที่ขาดคือตัวตนที่ไม่โต้ตอบซึ่งได้รับอนุมัติพร้อมแผนต่ออายุ และไม่มีแฟล็กบรรทัดคำสั่งใดให้ทั้งสองอย่าง การเพิ่มแฟล็กในสคริปต์บูตทำให้ได้อุโมงค์ที่ล้มเหลวเงียบ ๆ เมื่อข้อมูลรับรองหมดอายุครั้งแรก
ถือว่าคุกกี้เซสชันเป็นข้อมูลรับรอง
OpenConnect จัดทำเอกสารเฟสรับรองความถูกต้องแยกผ่าน --authenticate และวัสดุที่ได้สามารถส่งคืนด้วย --cookie-on-stdin คู่นั้นมีไว้สำหรับงานผสานรวม และสิ่งที่มันผลิตก็ละเอียดอ่อนเท่ากับรหัสผ่านที่สร้างมัน
เก็บค่าไว้นอกประวัติเชลล์ นอกบันทึก และนอกตั๋วใด ๆ ที่คุณเปิด สคริปต์ส่งต่อต้องรักษาข้อมูลปลายทางที่ตรวจสอบแล้วซึ่งไคลเอนต์ได้รับพร้อมคุกกี้ด้วย หากสูญหาย การรันครั้งหลังอาจเชื่อมต่อกับโฮสต์ที่คุณไม่เคยรับรอง ซึ่งแย่กว่าการเชื่อมต่อที่ล้มเหลวเฉย ๆ
ไล่รายการก่อนปิดเทอร์มินัล
สี่สิ่งควรเป็นจริง: การล็อกอินแบบโต้ตอบจบที่เบื้องหน้า ไฟล์ PID ชี้ไปที่โปรเซสที่คุณตรวจสอบแล้ว คำถามเรื่องตัวควบคุมถูกตัดสินไปทางใดทางหนึ่ง และคุกกี้มีแผนจัดเก็บที่ไม่ใช่ไฟล์ข้อความธรรมดา เมื่อทั้งสี่เป็นจริง การจากเทอร์มินัลไปนั้นปลอดภัยและอุโมงค์ยังทำงานต่อ
ถ้าข้อใดล้มเหลว ให้แก้ข้อนั้นก่อนแตะข้ออื่น เพราะการตรวจสอบที่เหลือชดเชยให้ไม่ได้ เก็บบันทึกเบื้องหน้าของการรันครั้งแรกไว้ด้วย ครั้งถัดไปที่อุโมงค์ล้มโดยไม่เตือน เส้นฐานนั้นคือสิ่งที่แยกการเปลี่ยนแปลงฝั่งเกตเวย์ออกจากฝั่งไคลเอนต์