Kāpēc OpenVPN mirst pēc klēpjdatora pamošanās?

Ieslēdziet datoru miega režīmā, pamodiniet to un pēc tam pirms jebkuras konfigurācijas aiztikšanas šajā secībā pārbaudiet trīs lietas: vai tun0 joprojām pastāv, vai maršruts uz iekšējo adresi joprojām izvēlas to un vai serveris joprojām uzskaita šo peer. Ierīce, kas pārdzīvo miegu, kamēr maršruts rāda citur, ir palieka, nevis tunelis. Kad maršruts ir pareizs un trafiks tomēr mirst, kļūme atrodas virs tuneļa, un klienta restartēšana to nemainīs. Restartēšanas automatizēšana ir jēga tikai pēc tam, kad manuāls tests ir parādījis, kurš no šiem trim gadījumiem jums ir.

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

Reproducējiet pamošanos, pirms to automatizējat

Miega režīms biežāk beidz šifrēto sesiju, nekā noņem ierīci. UDP plūsma, kas uzturēja tuneli dzīvu, apstājas, serveris var nomest peer, un klients vai nu to pamana un atkal pieslēdzas, vai arī patur saskarni, aiz kuras nekā nav. Saskarnes pārbaude vien pati par sevi maz pierāda, jo novecojusi ierīce izskatās tieši tāpat kā strādājoša kamēr paketēm nav jāiet tai cauri. Palaidiet maršruta meklēšanu un vienu reālu pieprasījumu cauri tunelim, pēc tam lasiet žurnālu ap pamošanās brīdi.

Ja klients atgriežas pats no sevis, āķis pievieno satraukumu, nevis uzticamību. Ja tas nekad neatgūstas, automatizācija ir godīgais risinājums.

Kur systemd miega āķis patiešām atrodas

Daudzas vecākas rokasgrāmatas norāda uz /etc/pm/sleep.d, mapi, kas pieder pm-utils un kuru uz systemd balstīts miegs nekad neapmeklē. systemd lasa āķus no /usr/lib/systemd/system-sleep/ un /etc/systemd/system-sleep/, vispirms nododot fāzi un tad darbību, tāpēc pre un post ir vienīgās vērtības, uz kurām āķis sazarojas. Turiet vietējo kopiju /etc ietvaros, nevis rediģējot iepakotu failu, un atcerieties, ka skripts darbojas kā root pārejas vidū, tāpēc tam ir ātri jāatgriežas.

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

try-restart pieskaras vienībai tikai tad, kad tā jau ir aktīva, tāpēc tunelis, kuru jūs apzināti izslēdzāt, paliek izslēgts visā pamošanās laikā. --no-block neļauj āķim gaidīt, kamēr klients pārrunā, kas svarīgi, kad tīkls vēl nav pacēlies. Kopā abi karodziņi nozīmē āķi, kas klusām neizdodas, nevis aiztur visu pamošanās secību. Kad vienība jau ir apstādināta, nenotiek absolūti nekas, un tas ir tieši tas iznākums, kuru tur gribat.

Atjaunojiet pakalpojumu, atstājiet tun0 mierā

tun0 nolaišana ar roku atstāj dēmonu uzraugām saskarni, kas tam vairs nepieder, un nākamā stāvokļa maiņa rada mulsinošas kļūdas. Mērķējiet uz pakalpojumu vai tā savienojuma profilu, nevis uz saskarni; vispirms pārbaudiet precīzu vienības nosaukumu, jo distribūcijas pakotnes, OpenVPN 3 un NetworkManager visi izvēlas atšķirīgus. NetworkManager profils atgriežas, kad šis savienojums tiek pārcilpots, tāpēc systemd vienība tur nav mērķis. Lai kāds būtu mehānisms, tam jābūt tai pašai darbībai, kuru pārbaudījāt ar roku.

Restartēšana atkārtoti instalē maršrutus, kurus klients iespieda, kad pieslēdzās. Lielākā daļa pamošanos to vēlas. Dators, kurā pievienojāt savus ceļus, ne, tāpēc pārbaudiet tos vēlreiz, nevis pieņemot, ka atjaunošana tos atgrieza, un pierakstiet tos tur, kur nākamā pamošanās tos varēs atrast.

Tiekiet galā ar laiku, kuru nevarat kontrolēt

Bezvadu asociācija un DHCP bieži beidzas pēc tam, kad āķis jau ir izpildījies, tāpēc restartēšana var neizdoties, kamēr ceļa uz serveri vēl nav. Īsu brīdi pagaidiet šo adresi, pamēģiniet vēlreiz un reģistrējiet rezultātu.

Vārdu atrisināšana ir atsevišķas sacensības, jo darbvirsmas tīkla steks var atjaunot DNS pēc tam, kad tunelis jau ir augšā. Pārbaudiet vaicājumus atsevišķi ar resolvectl query internal.example, nevis seciniet tos no strādājoša maršruta. Tunelis, kas pareizi maršrutē un neko neatrisina, ir DNS problēma, nevis āķa problēma.

Turiet āķa lēmumu redzamu, ierakstot žurnālā fāzi, vienības nosaukumu un rezultātu. Pierakstiet datora piezīmēs, kuru pamošanās testu veicāt, lai strādājošu atjaunošanu varētu atšķirt no laimīgas. Izvēlieties vismazāk traucējošo darbību, kas atgriež pakalpojumu, un ļaujiet klientam, kas atgūstas pats, to darīt. Pilnīga restartēšana nomet sesijas, kas notiek, un tas ir reālas izmaksas klēpjdatorā, kas pamostas vairākas reizes dienā.