Noutbuk uyg'ongandan keyin OpenVPN nima uchun o'ladi?

Mashinani uyquga yuboring, uyg'oting, so'ng har qanday konfiguratsiyaga tegishdan oldin shu tartibda uch narsani tekshiring: tun0 hali ham bormi, ichki manzilga boradigan yo'l hali ham uni tanlaydimi va server bu peer'ni hali ham ro'yxatga oladimi. Yo'l boshqa joyni ko'rsatib turganda uyqudan omon qolgan qurilma qoldiq, tunnel emas. Yo'l to'g'ri bo'lib, trafik baribir o'lsa, nosozlik tunnel tepasida va mijozi qayta ishga tushirish buni o'zgartirmaydi. Qayta ishga tushirishni avtomatlashtirish faqat qo'lda qilingan sinov bu uch holatdan qaysi biri ekanini ko'rsatgandan keyingina mantiqan to'g'ri.

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

Avtomatlashtirishdan oldin uyg'onishni qayta hosil qiling

Uyqu shifrlangan sessiyani qurilmani olib tashlashdan ko'ra ko'proq tugatadi. Tunnelni tirik ushlab turgan UDP oqimi to'xtaydi, server peer'ni tashlab yuborishi mumkin, mijoz esa buni payqab qayta ulanadi yoki orqasida hech narsa yo'q interfeysni saqlab qoladi. Faqat interfeysni tekshirish oz narsani isbotlaydi, chunki eskirgan qurilma ishlayotgan qurilmaga xuddi o'xshab ko'rinadi paketlar undan o'tishi shart bo'lmaguncha. Yo'l qidiruvini va tunnel orqali bitta haqiqiy so'rovni bajarib, keyin uyg'onish lahzasining atrofidagi jurnalni o'qing.

Agar mijoz o'zi qaytsa, ilgak ishonchlilik o'rniga ortiqcha ovoragarchilik qo'shadi. Agar u hech qachon tiklanmasa, avtomatlashtirish halol yechimdir.

systemd uyqu ilgagi aslida qayerda yashaydi

Ko'p eski qo'llanmalar /etc/pm/sleep.d ni ko'rsatadi, bu pm-utils ga tegishli katalog va systemd asosidagi uyqu unga hech qachon murojaat qilmaydi. systemd ilgaklarni /usr/lib/systemd/system-sleep/ va /etc/systemd/system-sleep/ dan o'qib, avval fazani, keyin amalni uzatadi, shuning uchun pre va post ilgak shoxlanadigan yagona qiymatlardir. Mahalliy nusxani paketlangan faylni tahrirlash o'rniga /etc ostida saqlang va skript o'tishning o'rtasida root sifatida ishlashini yodda tuting, shuning uchun u tez qaytishi kerak.

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

try-restart blokka faqat u allaqachon faol bo'lganda tegadi, shuning uchun ataylab o'chirgan tunnellingiz uyg'onish davomida o'chiq qoladi. --no-block ilgakning mijoz muzokara qilayotganda kutishini oldini oladi, bu tarmoq hali ko'tarilmaganda muhim. Ikkala bayroq birgalikda butun uyg'onish ketma-ketligini ushlab turish o'rniga jimgina muvaffaqiyatsiz bo'ladigan ilgakni anglatadi. Blok allaqachon to'xtatilgan bo'lsa, umuman hech narsa sodir bo'lmaydi, bu esa o'sha yerda xohlagan natijadir.

Xizmatni tiklang, tun0 ni yolg'iz qoldiring

tun0 ni qo'lda tushirish demonni endi o'ziga tegishli bo'lmagan interfeys ustidan nazorat qilib qoldiradi, keyingi holat o'zgarishi esa chalkashtiruvchi xatolar keltiradi. Interfeys o'rniga xizmat yoki uning ulanish profilini nishonga oling; avval blokning aniq nomini tekshiring, chunki distributiv paketlar, OpenVPN 3 va NetworkManager barchasi har xilini tanlaydi. NetworkManager profili o'sha ulanish qayta aylantirilganda qaytadi, shuning uchun systemd bloki u yerda nishon emas. Mexanizm qanday bo'lishidan qat'i nazar, bu siz qo'lda tekshirgan o'sha amal bo'lishi kerak.

Qayta ishga tushirish mijoz ulanayotganda itarib yuborgan yo'llarni qaytadan o'rnatadi. Ko'p uyg'onishlar shuni xohlaydi. O'z yo'llaringizni qo'shgan mashina xohlamaydi, shuning uchun tiklash ularni qaytardi deb o'ylash o'rniga ularni qayta tekshiring va keyingi uyg'onish topa oladigan joyga yozib qo'ying.

Siz nazorat qila olmaydigan vaqt bilan shug'ullaning

Simsiz ulanish va DHCP ko'pincha ilgak ishlagandan keyin tugaydi, shuning uchun serverga yo'l hali yo'q paytda qayta ishga tushirish muvaffaqiyatsiz bo'lishi mumkin. O'sha manzilni biroz kuting, yana bir marta urinib ko'ring va natijani jurnalga yozing.

Nomlarni hal qilish alohida poyga, chunki ish stoli tarmoq steki tunnel allaqachon ko'tarilgandan keyin DNS ni tiklashi mumkin. Qidiruvlarni ishlaydigan yo'ldan chiqarib olish o'rniga resolvectl query internal.example bilan alohida sinab ko'ring. To'g'ri marshrutlaydigan va hech narsani hal qilmaydigan tunnel DNS muammosi, ilgak muammosi emas.

Jurnalga fazani, blok nomini va natijani yozib, ilgak qarorini ko'rinadigan qilib turing. Mashina qaydlarida qaysi uyg'onish sinovini o'tkazganingizni yozing, shunda ishlaydigan tiklanish omadli tiklanishdan ajraladi. Xizmatni qaytaradigan eng kam xalaqit beradigan amalni tanlang va o'zi tiklanadigan mijozga shuni qilishiga ruxsat bering. To'liq qayta ishga tushirish davom etayotgan sessiyalarni tashlaydi, bu kuniga bir necha marta uyg'onadigan noutbukda haqiqiy xarajat.