RRAS khởi động trước khi đường hầm OpenVPN sẵn sàng lúc khởi động máy

Máy chủ khởi động lại, OpenVPN khởi động, và RRAS khởi động trong khi bộ điều hợp hoặc tuyến đường mà nó phụ thuộc vẫn chưa có. Khởi động lại RRAS bằng tay một phút sau đó sẽ khắc phục, khiến sự cố trông như đã được giải quyết và che giấu sự cố thật. Ở đây hai điều kiện khác nhau bị lẫn lộn: dịch vụ tiên quyết đang chạy, và tài nguyên mạng mà RRAS thực sự cần đã trở nên dùng được. Phụ thuộc dịch vụ của Windows có thể diễn đạt điều kiện thứ nhất và không bao giờ diễn đạt điều kiện thứ hai, nên thêm một phụ thuộc mà không định nghĩa tài nguyên chỉ cho bạn một lần khởi động trông gọn gàng hơn và vẫn lỗi đó.

Triệu chứng trông thế nào khi khởi động nguội

Dấu hiệu là sự khác nhau giữa khởi động nguội và khởi động lại. Khi khởi động nguội, RRAS báo mình đang chạy trong khi bộ điều hợp đường hầm chưa có, tuyến đường bị mất, hoặc địa chỉ đối tác chưa phân giải được. Khởi động lại bằng tay sau đó thành công vì lúc ấy tài nguyên đã có, và dịch vụ chỉ đọc lại một thế giới mà một phút trước nó không thể thấy. Nhật ký dịch vụ sẽ cho thấy một lần khởi động sạch trong cả hai trường hợp, vì thế riêng trình xem sự kiện hiếm khi giải thích được điều này.

Ghi lại cả hai trạng thái trước khi thay đổi bất cứ điều gì: RRAS báo gì khi khởi động, và cái gì tồn tại ngay lúc việc khởi động lại bằng tay thành công. Nếu hai quan sát đó giống hệt nhau, thứ tự khởi động không phải lời giải thích của bạn và phụ thuộc sẽ không giúp gì. Việc so sánh tốn mười phút và tiết kiệm một tuần phỏng đoán.

Một phụ thuộc được thêm với lý do «nó chạy sau khi khởi động lại» chỉ trì hoãn đúng lỗi đó trong khoảng thời gian dịch vụ tiên quyết cần để báo RUNNING. Nó cũng làm việc khởi động khó suy luận hơn, vì ràng buộc thứ tự giờ trông như một lời giải thích. Hãy hỏi phụ thuộc bảo đảm đối tượng nào và đối tượng đó có phải là thứ RRAS không thấy được hay không.

Gọi tên tài nguyên, không chỉ dịch vụ

Viết ra thứ cụ thể đang thiếu. Đó có thể là bộ điều hợp đường hầm có địa chỉ, tuyến đến mạng con đối tác, câu trả lời DNS, hoặc chứng chỉ vẫn đang được cấp. «Dịch vụ VPN đang chạy» không phải mô tả tài nguyên, và biểu tượng xanh trong ứng dụng khách cũng không. Cho đến khi bạn gọi được tên đối tượng và lệnh hiển thị nó, bạn chưa định nghĩa điều kiện mà mình đang cố chờ.

Cũng xác định cách phiên bản OpenVPN này được khởi chạy. Đường hầm do GUI quản lý và đường hầm do dịch vụ quản lý có vòng đời khởi động khác nhau, và tên dịch vụ phải đến từ chiếc máy trước mặt bạn, không phải từ một ví dụ viết cho trình cài đặt khác. Hãy liệt kê các ứng viên thay vì tin vào một cái tên nhớ được.

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

Đọc chuỗi phụ thuộc trước khi thêm vào

Service Control Manager báo các trạng thái như START_PENDING và RUNNING, và SERVICE_STATUS reference định nghĩa chính xác ý nghĩa của từng trường. Không trạng thái nào trong số đó hứa rằng đối tác, tên DNS hay ứng dụng hạ nguồn đã tiếp cận được. Chính khoảng trống đó là toàn bộ lý do vì sao lỗi này tồn tại dù phụ thuộc được cấu hình đúng.

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

Dòng DEPENDENCIES từ sc.exe qc là danh sách bạn phải giữ, vì sc.exe config RemoteAccess depend= thay thế toàn bộ danh sách chứ không nối thêm. Bỏ mất một điều kiện tiên quyết không liên quan trong khi thêm dịch vụ VPN sẽ tạo ra lỗi thứ hai xuất hiện ở lần khởi động khác, và khó chẩn đoán hơn nhiều so với lỗi gốc. Sao chép danh sách hiện có vào hồ sơ thay đổi trước khi chạm vào nó.

Phụ thuộc cũng thay đổi hành vi khi tắt máy, vì dừng một điều kiện tiên quyết sẽ dừng các dịch vụ phụ thuộc nó. Kiểm tra điều gì xảy ra trong lúc bảo trì trước khi nối RRAS với thứ gì đó thường xuyên khởi động lại.

Gắn việc khởi động lại vào một điều kiện, không phải bộ hẹn giờ

Chờ cố định giả định đường hầm luôn sẵn sàng trong khoảng thời gian đó, và chính giả định ấy thất bại ở lần khởi động khi chứng chỉ chậm hoặc liên kết bị ngắt. Kiểm tra chính tài nguyên đó, với một hạn chót, và để việc kiểm tra quyết định có cần khởi động lại hay không.

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'

Một tác vụ được lên lịch khi khởi động, chạy các kiểm tra đó và chỉ khởi động lại RRAS khi bộ điều hợp hoặc tuyến đường vẫn thiếu, là có giới hạn, có thể kiểm toán và dễ gỡ bỏ. Cách còn lại, khởi động lại RRAS ở mỗi lần kết nối lại, làm gián đoạn các phiên khỏe mạnh và biến một liên kết không ổn định thành vòng lặp khởi động lại. Vòng lặp đó tệ hơn lỗi gốc, vì giờ nó ảnh hưởng đến những người dùng vốn vẫn ổn.

Cho việc kiểm tra một khoảng chờ tối đa khớp với thời gian đường hầm mất một cách hợp lý trên phần cứng của bạn, và để tác vụ thoát với trạng thái khác không khi nó bỏ cuộc. Một tác vụ im lặng chỉ đơn giản ngừng thử thì không thể phân biệt với tác vụ thành công.

Ghi nhật ký chuyển trạng thái để lần khởi động sau tự giải thích

Ghi ba dấu thời gian trên cùng một dòng: khi dịch vụ phụ thuộc đạt RUNNING, khi tài nguyên cần thiết xuất hiện, và khi RRAS cuối cùng chấp nhận nó. Dòng duy nhất đó trả lời câu hỏi mà kỹ sư tiếp theo sẽ hỏi, và tạo ra nó gần như không tốn gì. Không có nó, cuộc điều tra tiếp theo bắt đầu từ đúng những phỏng đoán như lần này.

Dừng tự động hóa sau một số lần thử nhất định và báo lỗi thay vì thử lại mãi mãi. Một lần khởi động kết thúc bằng thông báo rõ ràng «tài nguyên không bao giờ xuất hiện» đáng giá hơn lần cứ tiếp tục khởi động lại dịch vụ trong bóng tối. Khi thông báo đó xuất hiện, tên tài nguyên bạn đã ghi ở phần thứ hai chính là thứ người tiếp theo sẽ tìm.