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 маселеси, илгич маселеси эмес.

Илгичтин чечимин журналга фазаны, бөлүктүн аталышын жана натыйжаны жазуу менен көрүнүктүү кармаңыз. Машина жазууларында кайсы ойгонуу тестин иштеткениңизди белгилеңиз, ошентип иштеген калыбына келтирүүнү ийгиликтүү болгондон ажыратууга болот. Кызматты кайтарган эң аз тоскоолдук кылган аракетти тандаңыз жана өзү калыбына келген клиентке ошону жасоого жол бериңиз. Толук кайра баштоо учуруп жаткан сессияларды таштайт, бул күнүнө бир нече жолу ойгонгон ноутбукта чыныгы чыгым.

Тектеш макалалар