Mengapa OpenVPN mati selepas komputer riba bangun?

Gantung mesin, bangunkan semula, kemudian periksa tiga perkara mengikut urutan ini sebelum menyentuh sebarang konfigurasi: sama ada tun0 masih wujud, sama ada laluan ke alamat dalaman masih memilihnya, dan sama ada pelayan masih menyenaraikan peer ini. Peranti yang terselamat daripada tidur sedangkan laluan menunjuk ke tempat lain ialah sisa, bukan terowong. Apabila laluan betul dan trafik masih mati, kerosakan terletak di atas terowong dan memulakan semula klien tidak akan mengubahnya. Automasi mula semula hanya masuk akal selepas ujian manual menunjukkan yang mana antara tiga kes itu yang anda ada.

ip -br address show tun0
ip route get 10.20.0.10
journalctl -u openvpn-client@office -b --no-pager | tail -30

Hasilkan semula kebangkitan sebelum mengautomasikannya

Tidur lebih kerap menamatkan sesi yang disulitkan daripada mengalihkan peranti. Aliran UDP yang mengekalkan terowong hidup berhenti, pelayan mungkin menggugurkan peer itu, dan klien sama ada menyedarinya dan menyambung semula atau mengekalkan antara muka tanpa apa-apa di belakangnya. Semakan antara muka semata-mata membuktikan sedikit, kerana peranti lama kelihatan sama seperti peranti yang berfungsi sehingga paket perlu melaluinya. Jalankan carian laluan serta satu permintaan sebenar melalui terowong, kemudian baca jurnal di sekitar saat kebangkitan.

Jika klien kembali dengan sendirinya, cangkuk menambah kekacauan dan bukan kebolehpercayaan. Jika ia tidak pernah pulih, automasi ialah penyelesaian yang jujur.

Di mana cangkuk tidur systemd sebenarnya tinggal

Banyak panduan lama menunjuk ke /etc/pm/sleep.d, direktori milik pm-utils yang tidak pernah dirujuk oleh gantung berasaskan systemd. systemd membaca cangkuk daripada /usr/lib/systemd/system-sleep/ dan /etc/systemd/system-sleep/, memberikan fasa dahulu dan operasi kedua, jadi pre dan post ialah satu-satunya nilai yang dicabangkan oleh cangkuk. Simpan salinan tempatan di bawah /etc dan bukan menyunting fail pakej, dan ingat skrip berjalan sebagai root di tengah-tengah peralihan, jadi ia mesti kembali dengan cepat.

#!/bin/sh
case "$1" in
  post)
    systemctl --no-block try-restart [email protected]
    ;;
esac
exit 0

try-restart hanya menyentuh unit apabila ia sudah aktif, jadi terowong yang anda matikan dengan sengaja kekal mati sepanjang kebangkitan. --no-block menghalang cangkuk daripada menunggu semasa klien berunding, yang penting apabila rangkaian belum naik lagi. Bersama-sama kedua-dua bendera bermakna cangkuk yang gagal secara senyap dan bukan menahan keseluruhan urutan kebangkitan. Apabila unit sudah berhenti, tiada apa berlaku sama sekali, dan itulah hasil yang anda mahu di sana.

Pulihkan perkhidmatan, biarkan tun0

Menurunkan tun0 secara manual meninggalkan daemon mengawasi antara muka yang tidak lagi dimilikinya, dan perubahan keadaan seterusnya menghasilkan ralat yang mengelirukan. Sasarkan perkhidmatan atau profil sambungannya dan bukan antara muka; periksa dahulu nama unit yang tepat, kerana pakej pengedaran, OpenVPN 3 dan NetworkManager semuanya memilih yang berbeza. Profil NetworkManager kembali apabila sambungan itu dikitar semula, jadi unit systemd bukan sasaran di situ. Apa pun mekanismenya, ia sepatutnya tindakan yang sama yang anda sahkan secara manual.

Mula semula memasang semula laluan yang ditolak oleh klien semasa ia bersambung. Kebanyakan kebangkitan mahukan itu. Mesin yang anda tambah laluan sendiri tidak, jadi periksa semula laluan itu dan bukan menganggap pemulihan telah mengembalikannya, dan catatkannya di tempat kebangkitan seterusnya boleh menemuinya.

Tangani masa yang anda tidak boleh kawal

Persatuan wayarles dan DHCP selalunya selesai selepas cangkuk berjalan, jadi mula semula boleh gagal sedangkan laluan ke pelayan belum ada. Tunggu sebentar alamat itu, cuba sekali lagi dan log hasilnya.

Resolusi nama ialah perlumbaan berasingan, kerana tindanan rangkaian desktop boleh memulihkan DNS selepas terowong sudah naik. Uji carian secara berasingan dengan resolvectl query internal.example dan bukan menyimpulkannya daripada laluan yang berfungsi. Terowong yang menyalurkan dengan betul dan tidak menyelesaikan apa-apa ialah masalah DNS, bukan masalah cangkuk.

Kekalkan keputusan cangkuk kelihatan dengan menulis fasa, nama unit dan hasil ke dalam jurnal. Catat dalam nota mesin ujian kebangkitan mana yang anda jalankan, supaya pemulihan yang berfungsi dapat dibezakan daripada yang bertuah. Pilih tindakan paling kurang mengganggu yang mengembalikan perkhidmatan, dan biarkan klien yang pulih sendiri berbuat demikian. Mula semula penuh menggugurkan sesi yang sedang berjalan, yang merupakan kos sebenar pada komputer riba yang bangun beberapa kali sehari.