Vì sao OpenVPN chết sau khi laptop thức dậy?
Chế độ ngủ có thể giết phiên OpenVPN trong khi để lại tun0. Kiểm tra đường hầm, sau đó khởi động lại unit từ hook ngủ của systemd, không phải thiết bị.
Đưa máy vào chế độ ngủ, đánh thức nó, rồi trước khi chạm vào bất kỳ cấu hình nào hãy kiểm tra ba thứ theo thứ tự này: tun0 còn tồn tại không, tuyến đến một địa chỉ nội bộ còn chọn nó không, và máy chủ còn liệt kê peer này không. Một thiết bị sống sót qua giấc ngủ trong khi tuyến trỏ đi nơi khác là tàn dư, không phải đường hầm. Khi tuyến đúng mà lưu lượng vẫn chết, lỗi nằm phía trên đường hầm và khởi động lại máy khách sẽ không thay đổi điều đó. Tự động hóa việc khởi động lại chỉ có nghĩa sau khi một bài kiểm tra thủ công đã cho thấy bạn thuộc trường hợp nào trong ba trường hợp đó.
ip -br address show tun0
ip route get 10.20.0.10
journalctl -u openvpn-client@office -b --no-pager | tail -30
Tái hiện việc thức dậy trước khi tự động hóa nó
Ngủ kết thúc phiên mã hóa thường xuyên hơn là gỡ thiết bị. Luồng UDP giữ đường hầm sống dừng lại, máy chủ có thể bỏ peer, và máy khách hoặc nhận ra rồi kết nối lại hoặc giữ một giao diện không có gì phía sau. Chỉ kiểm tra giao diện thì chứng minh được ít, bởi vì một thiết bị cũ trông giống hệt một thiết bị đang hoạt động cho đến khi các gói phải đi qua nó. Chạy tra cứu tuyến cùng một yêu cầu thực qua đường hầm, rồi đọc nhật ký quanh thời điểm thức dậy.
Nếu máy khách tự quay lại, một hook thêm rắc rối thay vì độ tin cậy. Nếu nó không bao giờ hồi phục, tự động hóa là giải pháp trung thực.
Hook ngủ của systemd thực sự nằm ở đâu
Nhiều hướng dẫn cũ chỉ vào /etc/pm/sleep.d, một thư mục thuộc pm-utils mà chế độ ngủ dựa trên systemd không bao giờ hỏi tới. systemd đọc hook từ /usr/lib/systemd/system-sleep/ và /etc/systemd/system-sleep/, truyền pha trước rồi thao tác sau, nên pre và post là những giá trị duy nhất mà một hook phân nhánh. Giữ bản sao cục bộ dưới /etc thay vì sửa tệp do gói cung cấp, và nhớ rằng script chạy với quyền root ở giữa quá trình chuyển đổi, nên nó phải quay về nhanh.
#!/bin/sh
case "$1" in
post)
systemctl --no-block try-restart [email protected]
;;
esac
exit 0
try-restart chỉ chạm vào một unit khi nó đã hoạt động, nên đường hầm bạn cố ý tắt vẫn tắt trong suốt quá trình thức dậy. --no-block ngăn hook chờ trong khi máy khách thương lượng, điều này quan trọng khi mạng chưa lên. Cùng nhau, hai cờ nghĩa là một hook thất bại âm thầm thay vì giữ toàn bộ chuỗi thức dậy. Khi unit đã dừng, không có gì xảy ra cả, và đó chính là kết quả bạn muốn ở đó.
Khôi phục dịch vụ, để tun0 yên
Hạ tun0 bằng tay để lại daemon giám sát một giao diện mà nó không còn sở hữu, và lần đổi trạng thái tiếp theo tạo ra lỗi khó hiểu. Nhắm vào dịch vụ hoặc hồ sơ kết nối của nó thay vì giao diện; trước tiên hãy kiểm tra tên unit chính xác, vì các gói bản phân phối, OpenVPN 3 và NetworkManager đều chọn tên khác nhau. Hồ sơ NetworkManager quay lại khi kết nối đó được quay vòng, nên unit systemd không phải mục tiêu ở đó. Dù cơ chế là gì, nó nên là cùng hành động mà bạn đã kiểm chứng bằng tay.
Khởi động lại cài đặt lại các tuyến mà máy khách đẩy vào khi kết nối. Hầu hết các lần thức dậy muốn điều đó. Một máy mà bạn đã thêm tuyến riêng thì không, nên hãy kiểm tra lại những tuyến đó thay vì cho rằng quá trình khôi phục đã đặt chúng lại, và ghi chúng ở nơi lần thức dậy tiếp theo có thể tìm thấy.
Xử lý thời điểm bạn không kiểm soát được
Liên kết không dây và DHCP thường hoàn tất sau khi hook đã chạy, nên khởi động lại có thể thất bại trong khi chưa có đường đến máy chủ. Chờ một chút địa chỉ đó, thử lại một lần và ghi lại kết quả.
Phân giải tên là một cuộc đua riêng, vì ngăn xếp mạng của máy tính để bàn có thể khôi phục DNS sau khi đường hầm đã lên. Kiểm tra truy vấn riêng với resolvectl query internal.example thay vì suy ra từ một tuyến đang hoạt động. Một đường hầm định tuyến đúng mà không phân giải được gì là vấn đề DNS, không phải vấn đề hook.
Giữ quyết định của hook hiển thị bằng cách ghi pha, tên unit và kết quả vào nhật ký. Ghi vào ghi chú của máy bài kiểm tra thức dậy nào bạn đã chạy, để một lần khôi phục hoạt động có thể phân biệt với một lần may mắn. Chọn hành động ít gián đoạn nhất đưa dịch vụ trở lại, và để một máy khách tự hồi phục làm điều đó. Khởi động lại toàn bộ làm rơi các phiên đang chạy, đó là chi phí thực trên một laptop thức dậy vài lần mỗi ngày.