RRAS เริ่มทำงานก่อนที่อุโมงค์ OpenVPN จะพร้อมตอนบูต

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

อาการเป็นอย่างไรเมื่อบูตแบบเย็น

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

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

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

ระบุชื่อทรัพยากร ไม่ใช่แค่บริการ

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

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

Get-Service | Where-Object Name -match 'vpn|openvpn' | Select-Object Name, Status, StartType

อ่านห่วงโซ่การพึ่งพาก่อนจะเพิ่มอะไร

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

Get-Service -Name RemoteAccess | Select-Object Status, StartType
sc.exe qc RemoteAccess
Get-Service -Name RemoteAccess | Select-Object -ExpandProperty DependentServices

บรรทัด DEPENDENCIES จาก sc.exe qc คือรายการที่คุณต้องรักษาไว้ เพราะ sc.exe config RemoteAccess depend= แทนที่รายการทั้งหมดแทนที่จะต่อท้าย การทิ้งข้อกำหนดเบื้องต้นที่ไม่เกี่ยวข้องขณะเพิ่มบริการ VPN จะสร้างข้อบกพร่องที่สองซึ่งปรากฏตอนบูตอื่น และวินิจฉัยยากกว่าของเดิมมาก คัดลอกรายการที่มีอยู่ลงบันทึกการเปลี่ยนแปลงก่อนแตะต้องมัน

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

ผูกการรีสตาร์ตกับเงื่อนไข ไม่ใช่กับตัวจับเวลา

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

Get-NetAdapter | Where-Object Status -eq 'Up'
Get-NetRoute -DestinationPrefix 0.0.0.0/0
Get-WinEvent -LogName System -MaxEvents 40 |
  Where-Object ProviderName -eq 'Service Control Manager'

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

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

บันทึกการเปลี่ยนผ่านเพื่อให้การบูตครั้งถัดไปอธิบายตัวเองได้

บันทึกเวลาสามครั้งในบรรทัดเดียวกัน: เมื่อบริการพึ่งพาถึง RUNNING เมื่อทรัพยากรที่ต้องการปรากฏ และเมื่อ RRAS ยอมรับมันในที่สุด บรรทัดเดียวนั้นตอบคำถามที่วิศวกรคนถัดไปจะถาม และการสร้างมันแทบไม่เสียค่าใช้จ่าย หากไม่มี การสอบสวนครั้งถัดไปจะเริ่มจากการเดาแบบเดียวกับครั้งนี้

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