Mengapa OpenVPN mati setelah laptop bangun?

Suspend mesin, bangunkan, lalu periksa tiga hal dalam urutan ini sebelum Anda menyentuh konfigurasi apa pun: apakah tun0 masih ada, apakah rute ke alamat internal masih memilihnya, dan apakah server masih mencantumkan peer ini. Perangkat yang bertahan dari tidur sementara rutenya menunjuk ke tempat lain adalah sisa, bukan terowongan. Saat rutenya benar dan lalu lintas tetap mati, kesalahannya berada di atas terowongan dan memulai ulang klien tidak akan mengubahnya. Mengotomatiskan mulai ulang baru masuk akal setelah uji manual menunjukkan yang mana dari tiga kasus itu yang Anda miliki.

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

Reproduksi kebangunannya sebelum mengotomatiskannya

Tidur lebih sering mengakhiri sesi terenkripsi daripada menghapus perangkatnya. Aliran UDP yang menjaga terowongan tetap hidup berhenti, server dapat menjatuhkan peer, dan klien entah menyadarinya dan menyambung ulang atau mempertahankan antarmuka yang tidak ada apa pun di belakangnya. Pemeriksaan antarmuka saja membuktikan sedikit, karena perangkat usang terlihat persis seperti perangkat yang berfungsi sampai paket harus melewatinya. Jalankan pencarian rute plus satu permintaan nyata melalui terowongan, lalu baca jurnal di sekitar momen kebangkitan.

Jika klien kembali sendiri, hook menambah kerumitan alih-alih keandalan. Jika tidak pernah pulih, otomatisasi adalah perbaikan yang jujur.

Di mana hook tidur systemd sebenarnya berada

Banyak panduan lama menunjuk ke /etc/pm/sleep.d, direktori milik pm-utils yang tidak pernah dikonsultasikan oleh suspend berbasis systemd. systemd membaca hook dari /usr/lib/systemd/system-sleep/ dan /etc/systemd/system-sleep/, meneruskan fase lebih dulu dan operasi kedua, jadi pre dan post adalah satu-satunya nilai tempat hook bercabang. Simpan salinan lokal di bawah /etc alih-alih mengedit berkas paket, dan ingat skrip berjalan sebagai root di tengah transisi, jadi skrip harus kembali dengan cepat.

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

try-restart hanya menyentuh unit bila sudah aktif, jadi terowongan yang Anda matikan dengan sengaja tetap mati sepanjang kebangkitan. --no-block mencegah hook menunggu saat klien bernegosiasi, yang penting ketika jaringan belum naik. Bersama-sama kedua flag berarti hook yang gagal diam-diam alih-alih menahan seluruh urutan kebangkitan. Bila unit sudah berhenti, tidak terjadi apa-apa sama sekali, yang justru hasil yang Anda inginkan di sana.

Pulihkan layanannya, biarkan tun0 sendiri

Menurunkan tun0 secara manual membuat daemon mengawasi antarmuka yang tidak lagi dimilikinya, dan perubahan status berikutnya menghasilkan kesalahan yang membingungkan. Sasaran layanan atau profil koneksinya, bukan antarmukanya; periksa dulu nama unit yang tepat, karena paket distribusi, OpenVPN 3, dan NetworkManager semuanya memilih nama yang berbeda. Profil NetworkManager kembali saat koneksi itu didaur ulang, jadi unit systemd bukan sasarannya di sana. Apa pun mekanismenya, seharusnya tindakan yang sama dengan yang Anda verifikasi secara manual.

Mulai ulang memasang kembali rute yang didorong klien saat terhubung. Sebagian besar kebangkitan menginginkan itu. Mesin yang Anda tambahi rute sendiri tidak, jadi periksa ulang rute itu alih-alih menganggap pemulihan mengembalikannya, dan catat di tempat yang bisa ditemukan kebangkitan berikutnya.

Tangani waktu yang tidak bisa Anda kendalikan

Asosiasi nirkabel dan DHCP sering selesai setelah hook berjalan, jadi mulai ulang bisa gagal saat jalur ke server belum ada. Tunggu sebentar alamat itu, coba sekali lagi, dan catat hasilnya.

Resolusi nama adalah perlombaan tersendiri, karena tumpukan jaringan desktop dapat memulihkan DNS setelah terowongan sudah naik. Uji pencarian secara terpisah dengan resolvectl query internal.example alih-alih menyimpulkannya dari rute yang berfungsi. Terowongan yang merutekan dengan benar dan tidak menyelesaikan apa pun adalah masalah DNS, bukan masalah hook.

Jaga keputusan hook tetap terlihat dengan menulis fase, nama unit, dan hasilnya ke jurnal. Catat di catatan mesin uji kebangkitan mana yang Anda jalankan, agar pemulihan yang berhasil bisa dibedakan dari yang kebetulan. Pilih tindakan paling tidak mengganggu yang mengembalikan layanan, dan biarkan klien yang pulih sendiri melakukannya. Mulai ulang penuh memutus sesi yang sedang berjalan, yang merupakan biaya nyata pada laptop yang bangun beberapa kali sehari.