OpenVPN พยายามซ้ำไม่หยุดหลังเกิดข้อผิดพลาด TLS: จะหยุดมันอย่างไร

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

ลูปที่ซ่อนข้อผิดพลาดแรก

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

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

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

กลไกการลองซ้ำเบื้องหลังลูป

การลองซ้ำเป็นค่าเริ่มต้นเพราะไทม์เอาต์หลายตัวที่ไม่เกี่ยวข้องกันใช้กลไกร่วมกัน connect-retry กำหนดช่องว่างระหว่างการลองเชื่อมต่อ connect-retry-max จำกัดได้ว่าทดลองแต่ละรายการปลายทางบ่อยเพียงใด และ resolv-retry ควบคุมการค้นหาชื่อที่ทำซ้ำ ความล้มเหลวของการเจรจา TLS มาถึงกลไกนั้นในฐานะเหตุการณ์การขนส่ง ไคลเอนต์จึงจัดตารางการลองใหม่แทนที่จะรายงาน ค่าเริ่มต้นช่วยกับการเชื่อมต่อที่ไม่เสถียรและทำร้ายข้อบกพร่องที่ไม่สามารถหายได้

ตัวเลือก --tls-exit เปลี่ยนเฉพาะกรณีการเจรจา คู่มืออธิบายว่าคือการออกเมื่อการเจรจา TLS ล้มเหลว ซึ่งแคบกว่าการออกเมื่อเกิดข้อผิดพลาดใด ๆ ไทม์เอาต์ ความล้มเหลวของตัวแปลงชื่อ และการปฏิเสธการพิสูจน์ตัวตนยังคงพฤติกรรมของตัวเอง

ทำให้ไคลเอนต์ออกเมื่อ TLS ล้มเหลว

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

ตัวดูแลเป็นผู้ตัดสินว่าการออกนั้นมองเห็นได้หรือไม่ ยูนิต systemd ที่มี Restart=always หรือ Restart=on-failure จะเริ่มไคลเอนต์ใหม่ ลูปจึงดำเนินต่อและตัวเลือกดูเหมือนไม่ได้ทำอะไร ตรวจสอบนโยบายก่อนจะโทษไคลเอนต์:

systemctl show -p Restart -p RestartSec openvpn-client@office
journalctl -u openvpn-client@office -n 40 --no-pager

Restart=no ปล่อยให้โปรเซสหยุดอยู่ และ Restart=on-failure ยังรีสตาร์ตหลังสถานะที่ไม่เป็นศูนย์ หากต้องการให้ความล้มเหลวมองเห็นได้แต่บริการฟื้นจากเหตุขัดข้องที่ไม่เกี่ยวข้อง ให้ตั้ง Restart=on-failure และใช้ StartLimitBurst กับ StartLimitIntervalSec เพื่อหยุดพายุการรีสตาร์ต จากนั้นอ่านสถานะของยูนิตเพื่อยืนยันรหัสออกสุดท้าย: systemctl status รายงานมัน และบันทึกเก็บข้อผิดพลาดแรกไว้เหนือการรีสตาร์ต

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

พิสูจน์ด้วยจุดปลายแบบใช้ครั้งเดียว

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

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

ลบโปรไฟล์ทดสอบเมื่อเสร็จ สำเนาที่มีจุดปลายผิดโดยเจตนาคือกับดักสำหรับใครก็ตามที่ภายหลังเริ่มทุกโปรไฟล์ในไดเรกทอรี

ขั้นตอนที่ตัวเลือกนี้ไปไม่ถึง

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

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

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