Зөөврийн компьютер сэрсний дараа OpenVPN яагаад үхдэг вэ?

Унтах нь OpenVPN сессийг устгаж, tun0-г үлдээж болно. Туннелийг шалгаад, дараа нь төхөөрөмжийг биш, systemd унтах дэгээнээс нэгжийг дахин эхлүүлнэ үү.

Машиныг унтуулж, дахин сэрээгээд, ямар ч тохиргоонд хүрэхийн өмнө энэ дарааллаар гурван зүйлийг шалга: tun0 одоо ч байгаа эсэх, дотоод хаяг руу очих зам одоо ч түүнийг сонгож байгаа эсэх, сервер энэ зэрэглэгчийг одоо ч жагсаасан эсэх. Зам өөр тийшээ заасан байхад унталтаас амьд гарсан төхөөрөмж бол үлдэгдэл, туннель биш. Зам зөв байхад урсгал мөнхөд үхэж байвал алдаа нь туннелийн дээр байгаа бөгөөд клиентийг дахин эхлүүлэх нь түүнийг өөрчлөхгүй. Дахин эхлүүлэхийг автоматжуулах нь эдгээр гурван тохиолдлын аль нь болохыг гараар хийсэн туршилт харуулсны дараа л утга учиртай.

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

Автоматжуулахын өмнө сэрэлтийг дахин үүсгэ

Унтах нь төхөөрөмжийг арилгахаас илүү олон удаа шифрлэсэн сессийг дуусгадаг. Туннелийг амьд байлгасан UDP урсгал зогсож, сервер зэрэглэгчийг хаяж болох бөгөөд клиент нь үүнийг анзаарч дахин холбогдох эсвэл ард нь юу ч байхгүй интерфейсийг хадгална. Зөвхөн интерфейсийг шалгах нь бага зүйлийг нотолдог, учир нь хуучин төхөөрөмж ажиллаж байгаа төхөөрөмжтэй яг адилхан харагддаг пакетууд түүгээр гарах хүртэл. Зам хайлт ба туннелээр дамжуулсан нэг бодит хүсэлтийг ажиллуулаад, сэрэлтийн мөчийн эргэн тойрон дахь журналыг унш.

Хэрэв клиент өөрөө буцаж ирвэл, дэгээ нь найдвартай байдлын оронд нэмэлт ажил нэмнэ. Хэрэв энэ хэзээ ч сэргэхгүй бол автоматжуулалт бол шударга шийдэл.

systemd унтах дэгээ үнэхээр хаана байдаг вэ

Олон хуучин гарын авлага /etc/pm/sleep.d-г заадаг, энэ нь pm-utils-ийн эзэмшлийн хавтас бөгөөд systemd-д суурилсан унталт хэзээ ч түүнээс зөвлөгөө авдаггүй. systemd дэгээнүүдийг /usr/lib/systemd/system-sleep/ ба /etc/systemd/system-sleep/-ээс уншиж, эхлээд үе шатыг, дараа нь үйлдлийг дамжуулдаг тул pre ба post нь дэгээ салбарладаг цорын ганц утга юм. Орон нутгийн хуулбарыг /etc доор байлгаж, багцлагдсан файлыг засварын оронд, скрипт шилжилтийн дунд root хэрэглэгчээр ажилладаг гэдгийг санаарай, тиймээс хурдан буцах ёстой.

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

try-restart нэгжид зөвхөн аль хэдийн идэвхтэй байхад нь хүрдэг тул санаатайгаар унтраасан туннель сэрэлтийн турш унтарсан хэвээр байна. --no-block нь клиент хэлэлцэж байх хооронд дэгээг хүлээхээс сэргийлдэг бөгөөд сүлжээ хараахан босоогүй үед энэ нь чухал. Хоёр туг хамтдаа сэрэлтийн бүх дарааллыг барихын оронд чимээгүйхэн бүтэлгүйтдэг дэгээг илэрхийлнэ. Нэгж аль хэдийн зогссон бол огт юу ч болохгүй, энэ нь яг тэнд хүсч буй үр дүн юм.

Үйлчилгээг сэргээж, tun0-г тайван орхи

tun0-г гараар буулгах нь демоныг өөрийн мэдэлд байхаа больсон интерфейсийг хянаж үлдээж, дараагийн төлөв өөрчлөлт нь будлиантай алдаа гаргана. Интерфейсийг биш, үйлчилгээ эсвэл түүний холболтын профайлыг зориорой; эхлээд нэгжийн яг нэрийг шалгаарай, учир нь түгээлтийн багцууд, OpenVPN 3 болон NetworkManager бүгд өөр өөр сонгодог. NetworkManager профайл тэр холболтыг дахин эргүүлэх үед буцаж ирдэг, тиймээс systemd нэгж тэнд зорилт биш. Механизм нь юу ч байсан, энэ нь таны гараар шалгасан ижил үйлдэл байх ёстой.

Дахин эхлүүлэх нь клиент холбогдох үед түлхсэн замуудыг дахин суулгана. Ихэнх сэрэлтүүд үүнийг хүсдэг. Өөрийн замыг нэмсэн машин хүсэхгүй, тиймээс сэргээлт тэдгээрийг буцаасан гэж таамаглахын оронд дахин шалгаж, дараагийн сэрэлт олж чадах газарт бичиж үлдээ.

Өөрөө хянаж чадахгүй цаг хугацааг зохицуул

Утасгүй холболт ба DHCP нь дэгээ ажилласны дараа дуусдаг нь олон, тиймээс сервер рүү зам хараахан байхгүй үед дахин эхлүүлэх нь бүтэлгүйтэж болно. Тэр хаягийг бага зэрэг хүлээж, дахин нэг удаа оролдож, үр дүнг журналд бич.

Нэр шийдвэрлэлт нь тусдаа уралдаан, учир нь ширээний компьютер сүлжээний стек нь туннель аль хэдийн боссны дараа DNS-ийг сэргээж болно. Ажиллаж буй замаас дүгнэхийн оронд resolvectl query internal.example-тэй хайлтуудыг тусад нь шалга. Зөв чиглүүлдэг боловч юуг ч шийддэггүй туннель бол DNS-ийн асуудал, дэгээний асуудал биш.

Журналд үе шат, нэгжийн нэр, үр дүнг бичиж дэгээний шийдвэрийг харагдахуйц байлга. Машины тэмдэглэлд ямар сэрэлтийн туршилт хийснээ бичвэл ажиллаж буй сэргээлтийг азтай сэргээлтээс ялгаж болно. Үйлчилгээг буцаадаг хамгийн бага саадтай үйлдлийг сонгож, өөрөө сэргэдэг клиентийг тийм байлга. Бүрэн дахин эхлүүлэх нь үргэлжилж буй сессийг унагадаг бөгөөд энэ нь өдөрт хэд хэдэн удаа сэрдэг зөөврийн компьютерт бодит зардал юм.

Холбоотой нийтлэлүүд