Bakit namamatay ang OpenVPN pagkatapos magising ang laptop?

I-suspend ang makina, gisingin ito, pagkatapos ay tingnan ang tatlong bagay sa ganitong pagkakasunod-sunod bago hawakan ang anumang configuration: kung umiiral pa ang tun0, kung pinipili pa ito ng ruta patungo sa isang panloob na address, at kung nakalista pa ng server ang peer na ito. Ang device na nakakaligtas sa pagtulog habang ang ruta ay tumuturo sa ibang lugar ay isang labi, hindi isang tunnel. Kapag tama ang ruta at namamatay pa rin ang trapiko, ang sira ay nasa itaas ng tunnel at hindi ito mababago ng pag-restart ng client. Ang pag-automate ng restart ay may saysay lamang pagkatapos na maipakita ng manu-manong pagsubok kung alin sa tatlong kaso ang mayroon ka.

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

Kopyahin ang paggising bago ito i-automate

Mas madalas tapusin ng pagtulog ang naka-encrypt na sesyon kaysa alisin ang device. Humihinto ang UDP flow na nagpapanatiling buhay sa tunnel, maaaring i-drop ng server ang peer, at ang client ay mapapansin ito at muling kumokonekta o pinapanatili ang isang interface na walang anuman sa likod nito. Kaunti lang ang napapatunayan ng pagsusuri ng interface nang mag-isa, dahil ang lumang device ay mukhang eksaktong katulad ng gumaganang device hanggang sa kailangang dumaan ang mga packet dito. Patakbuhin ang paghahanap ng ruta kasama ang isang tunay na kahilingan sa tunnel, pagkatapos ay basahin ang journal sa paligid ng sandali ng paggising.

Kung kusang bumalik ang client, ang hook ay nagdaragdag ng gulo sa halip na pagiging maaasahan. Kung hindi ito kailanman bumangon, ang automation ang tapat na solusyon.

Saan talaga nakatira ang isang systemd sleep hook

Maraming lumang gabay ang tumuturo sa /etc/pm/sleep.d, isang direktoryo na pag-aari ng pm-utils at hindi kailanman kinukonsulta ng pagtulog na nakabatay sa systemd. Nagbabasa ang systemd ng mga hook mula sa /usr/lib/systemd/system-sleep/ at /etc/systemd/system-sleep/, ipinapasa muna ang phase at pagkatapos ang operasyon, kaya ang pre at post lamang ang mga halagang sinasangahan ng isang hook. Itago ang lokal na kopya sa ilalim ng /etc sa halip na i-edit ang isang naka-package na file, at tandaan na tumatakbo ang script bilang root sa gitna ng transition, kaya kailangan itong bumalik nang mabilis.

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

try-restart humahawak lamang ng unit kapag aktibo na ito, kaya ang tunnel na sadyang pinatay mo ay nananatiling patay sa buong paggising. Pinipigilan ng --no-block ang hook na maghintay habang nakikipagnegosasyon ang client, na mahalaga kapag hindi pa nakakataas ang network. Magkasama, ang dalawang flag ay nangangahulugan ng hook na tahimik na nabigo sa halip na pigilan ang buong pagkakasunod-sunod ng paggising. Kapag naka-stop na ang unit, wala talagang nangyayari, at iyon mismo ang resultang gusto mo doon.

Ibalik ang serbisyo, iwanan ang tun0

Ang manu-manong pagbaba ng tun0 ay nag-iiwan sa daemon na pinagmamasdan ang isang interface na hindi na nito pag-aari, at ang susunod na pagbabago ng estado ay gumagawa ng nakakalitong mga error. I-target ang serbisyo o ang profile ng koneksyon nito sa halip na ang interface; tingnan muna ang eksaktong pangalan ng unit, dahil ang mga package ng distribusyon, OpenVPN 3 at NetworkManager ay pumipili ng magkakaiba. Bumabalik ang isang NetworkManager profile kapag ni-recycle ang koneksyong iyon, kaya ang systemd unit ay hindi ang target doon. Anuman ang mekanismo, dapat itong parehong aksyon na na-verify mo nang manu-mano.

Ang restart ay muling nag-i-install ng mga rutang itinulak ng client noong kumonekta ito. Gusto iyon ng karamihan ng paggising. Ang makina kung saan nagdagdag ka ng sarili mong mga landas ay hindi, kaya suriin muli ang mga iyon sa halip na ipagpalagay na ibinalik sila ng pagbawi, at isulat ang mga ito kung saan mahahanap sila ng susunod na paggising.

Harapin ang timing na hindi mo kontrolado

Ang wireless association at DHCP ay madalas na natatapos pagkatapos tumakbo ang hook, kaya maaaring mabigo ang restart habang wala pang landas patungo sa server. Maghintay nang kaunti para sa address na iyon, subukan muli nang isang beses, at i-log ang resulta.

Ang paglutas ng pangalan ay isang hiwalay na karera, dahil maaaring ibalik ng desktop network stack ang DNS pagkatapos na nakaangat na ang tunnel. Subukan ang mga lookup nang hiwalay gamit ang resolvectl query internal.example sa halip na hulaan ang mga ito mula sa gumaganang ruta. Ang tunnel na tama ang routing at walang nireresolba ay problema sa DNS, hindi problema sa hook.

Panatilihing nakikita ang desisyon ng hook sa pamamagitan ng pagsulat ng phase, pangalan ng unit at resulta sa journal. Itala sa mga tala ng makina kung aling pagsubok ng paggising ang pinatakbo mo, upang makilala ang gumaganang pagbawi mula sa isang mapalad. Piliin ang pinakamaliit na nakakaabala na aksyon na nagbabalik ng serbisyo, at hayaang gawin iyon ng client na kusang bumabangon. Ang buong restart ay nagtatapon ng mga sesyong tumatakbo, na isang tunay na gastos sa isang laptop na gumising nang maraming beses sa isang araw.