Kial OpenVPN mortas post kiam la tekkomputilo vekiĝas?

Dormo povas mortigi la OpenVPN-sesion kaj lasi tun0 malantaŭe. Testu la tunelon, poste restartigu la unuon el systemd-dormohoko, ne la aparaton.

Suspendu la maŝinon, restarigu ĝin, poste kontrolu tri aferojn en ĉi tiu ordo antaŭ ol tuŝi ajnan agordon: ĉu tun0 ankoraŭ ekzistas, ĉu la vojo al interna adreso ankoraŭ elektas ĝin, kaj ĉu la servilo ankoraŭ listigas ĉi tiun peer. Aparato, kiu postvivas dormon dum la vojo montras aliloken, estas restaĵo, ne tunelo. Kiam la vojo estas ĝusta kaj trafiko tamen mortas, la difekto sidas super la tunelo kaj restartigo de la kliento ne ŝanĝos ĝin. Aŭtomatigi restartigon havas sencon nur post kiam mana testo montris, kiun el tiuj tri kazoj vi havas.

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

Reproduktu la vekiĝon antaŭ ol aŭtomatigi ĝin

Suspendado finas la ĉifritan sesion pli ofte ol ĝi forigas la aparaton. La UDP-fluo, kiu tenis la tunelon viva, haltas, la servilo povas forfali la peer, kaj la kliento aŭ rimarkas tion kaj rekonektiĝas, aŭ retenas interfacon kun nenio malantaŭ ĝi. Interfaca kontrolo sola pruvas malmulte, ĉar malnova aparato aspektas same kiel funkcianta ĝis pakaĵoj devas trapasi ĝin. Rulu la vojserĉon plus unu realan peton tra la tunelo, poste legu la protokolon ĉirkaŭ la momento de la vekiĝo.

Se la kliento revenas sola, hoko aldonas tumulton anstataŭ fidindecon. Se ĝi neniam resaniĝas, aŭtomatigo estas la honesta solvo.

Kie systemd-dormohoko efektive loĝas

Multaj pli malnovaj gvidiloj montras al /etc/pm/sleep.d, dosierujo posedata de pm-utils, kiun systemd-bazita suspendado neniam konsultas. systemd legas hokojn el /usr/lib/systemd/system-sleep/ kaj /etc/systemd/system-sleep/, transdonante unue la fazo kaj due la operacio, do pre kaj post estas la solaj valoroj, laŭ kiuj hoko disbranĉiĝas. Tenu la lokan kopion sub /etc anstataŭ redakti pakaĵan dosieron, kaj memoru, ke la skripto ruliĝas kiel root meze de la transiro, do ĝi devas reveni rapide.

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

try-restart tuŝas unuon nur kiam ĝi jam estas aktiva, do tunelo, kiun vi intence malŝaltis, restas malŝaltita tra la vekiĝo. --no-block malhelpas la hokon atendi dum la kliento intertraktas, kio gravas kiam la reto ankoraŭ ne supreniris. Kune la du flagoj signifas hokon, kiu malsukcesas silente anstataŭ teni la tutan vekiĝan sekvencon. Kiam la unuo jam estas haltigita, nenio ajn okazas, kio estas ĝuste la rezulto, kiun vi volas tie.

Restarigu la servon, lasu tun0 trankvila

Mallevi tun0 permane lasas la demonon observi interfacon, kiun ĝi ne plu posedas, kaj la sekva ŝtata ŝanĝo produktas konfuzajn erarojn. Celu la servon aŭ ĝian konektan profilon anstataŭ la interfacon; unue kontrolu la ĝustan nomon de la unuo, ĉar distribuaĵaj pakaĵoj, OpenVPN 3 kaj NetworkManager ĉiuj elektas malsamajn. NetworkManager-profilo revenas kiam tiu konekto estas recikligita, do la systemd-unuo tie ne estas la celo. Kia ajn la mekanismo, ĝi devus esti la sama ago, kiun vi kontrolis permane.

Restartigo reinstalas la vojojn, kiujn la kliento puŝis kiam ĝi konektiĝis. Plej multaj vekiĝoj volas tion. Maŝino, kie vi aldonis proprajn vojojn, ne volas, do rekontrolu tiujn anstataŭ supozi, ke la rekupero resendis ilin, kaj skribu ilin tie, kie la sekva vekiĝo povas trovi ilin.

Traktu la tempigon, kiun vi ne povas kontroli

Sendrata asocio kaj DHCP ofte finiĝas post kiam la hoko ruliĝis, do restartigo povas malsukcesi dum vojo al la servilo ankoraŭ ne ekzistas. Mallonge atendu tiun adreson, provu unu plian fojon kaj protokolu la rezulton.

Nomrezolucio estas aparta kuro, ĉar la labortabla reta stako povas restarigi DNS post kiam la tunelo jam supreniris. Testu serĉojn aparte per resolvectl query internal.example anstataŭ dedukti ilin el funkcianta vojo. Tunelo, kiu ĝuste enkursigas kaj solvas nenion, estas DNS-problemo, ne hoka problemo.

Tenu la decidon de la hoko videbla skribante la fazon, la nomon de la unuo kaj la rezulton en la protokolon. Notu en la maŝinaj notoj, kiun vekiĝan teston vi rulis, por ke funkcianta rekupero distingiĝu de bonŝanca. Elektu la plej malmulte ĝenan agon, kiu revenigas la servon, kaj lasu klienton, kiu resaniĝas mem, fari tion. Plena restartigo faligas sesiojn en progreso, kio estas reala kosto sur tekkomputilo, kiu vekiĝas plurfoje tage.

Rilataj artikoloj