Chỉ một hook khi ngủ sẽ không đưa VPN trở lại

Đặt một lệnh kết nối lại trong hook khi ngủ và vấn đề có vẻ đã được giải quyết. Nó chỉ được giải quyết nếu hook chạy sau khi mạng tồn tại, với danh tính mà ứng dụng khách nhận ra, qua một đường đi mà ứng dụng khách thực sự triển khai. Hầu hết các lỗi sau khi thức dậy là một trong ba điều đó, và không điều nào xuất hiện như một lỗi trong chính hook. Hook vẫn trả về thành công.

Một script thoát với số không không nói với bạn điều gì về việc liệu một đường hầm đã trở lại hay chưa.

Hook chạy, và sau đó?

#!/bin/sh
case "$1" in
  pre)
    vpn-client disconnect
    ;;
  post)
    vpn-client connect
    ;;
esac

Mỗi sự kiện gọi hook hai lần, trước và sau khi chuyển đổi, trao cho nó pha và tên sự kiện. Nó chạy dưới quyền root với một môi trường tối thiểu, vì vậy cần có đường dẫn tuyệt đối và không nên mong đợi bất kỳ biến phiên máy tính để bàn nào. Việc cả hai lời gọi trả về nhanh chỉ nói rằng script đã chạy. Liệu hồ sơ có khởi lên sau đó hay không là một quan sát riêng và cần bằng chứng của chính nó trong nhật ký.

Coi đối số pha là một phần của thiết kế. Một lần thử kết nối lại trong pha pre xảy ra khi máy sắp mất tất cả, và nó không thể thành công.

Root, môi trường tối thiểu, sai người dùng

Nếu ứng dụng khách giữ token đăng nhập theo từng người dùng, chạy hook dưới quyền root sẽ để nó không còn gì để trình bày. Kiểm tra trạng thái dưới danh tính mà hook thực sự dùng, không phải danh tính bạn đã thử từ một terminal máy tính để bàn. Một số bản dựng còn để lại một daemon giữ giao diện sau khi ngắt kết nối, nên việc kết nối lại rơi vào trạng thái cũ, và dọn tiến trình trước sẽ khôi phục nó với cái giá là một lần tắt không sạch. Không hành vi nào trong hai hành vi đó hiện ra nếu bạn chỉ thử con đường thuận lợi.

Viết hook với đường dẫn tuyệt đối, giữ nó thuộc sở hữu của root và có thể thực thi, và ghi lại những gì nó đã làm. Không có nhật ký đó, cuộc điều tra tiếp theo bắt đầu từ con số không.

Kết nối tự động không phải là đường của VPN

NetworkManager cung cấp hai cơ chế kích hoạt: một cờ kết nối tự động trên hồ sơ, và các kết nối thứ cấp bắt đầu khi một hồ sơ chính được kích hoạt. Các loại thiết bị gốc triển khai cơ chế đầu; plugin VPN trong lịch sử chỉ triển khai cơ chế thứ hai, nên việc đánh dấu kết nối tự động trên hồ sơ OpenVPN có thể hoàn toàn không có tác dụng. Hãy kiểm tra cả hai thuộc tính, rồi gắn VPN làm thứ cấp của hồ sơ Wi-Fi hoặc Ethernet.

[Unit]
PartOf=NetworkManager.service
Requires=NetworkManager-wait-online.service
After=NetworkManager-wait-online.service

Một giao diện WireGuard do unit systemd quản lý cần tệp bổ sung đó thay vì một hook, được sắp xếp sau khi mạng trực tuyến.

Chờ mạng, với một giới hạn

timer=1
while ! ping -c1 -n -w1 203.0.113.1 >/dev/null; do
  sleep 1; timer=$((timer+1))
  [ $timer -ge 300 ] && exit 0
done
nmcli connection up "work-vpn"

Khi thức dậy, đường hầm có thể được yêu cầu trong khi Wi-Fi vẫn đang liên kết lại, điều này khiến mọi giấc ngủ cố định thành phỏng đoán. Hãy chờ một địa chỉ có thể truy cập, sau đó nâng hồ sơ lên, và giới hạn thời gian chờ để một hook không thể giữ đường thức dậy mở vô thời hạn. Ưu tiên tên hồ sơ hơn chỉ số số, và nếu hồ sơ đúng khác nhau theo mạng, hãy để đường hầm khỏe mạnh ghi lựa chọn của nó vào một tệp trước.

Cũng đề phòng bão khởi động lại, bằng cách đếm số lần thử và dừng lại. Một watchdog phản ứng với mọi lần thăm dò thất bại sẽ biến một sự cố thành một vòng lặp.

Tạm ngưng hệ thống một lần, rồi đọc nhật ký để xem đầu ra của chính hook. Đó là thử nghiệm duy nhất chứng minh thứ tự.