OpenConnect uzilgan VPN bilan qancha vaqt qayta ulanishga urinishi kerak?

--reconnect-timeout bitta tor savolga javob beradi: tunnel yiqilgandan keyin bu mijoz jarayoni taslim bo‘lib chiqishdan oldin qancha vaqt urinishda davom etadi. OpenConnect qo‘llanma sahifasi bu parametrni yo‘qolgan aloqa yoki javob berishni to‘xtatgan hamkordan keyingi qayta urinishlar uchun hujjatlashtirilgan 300 soniya standart qiymati bilan qayd etadi va bu son bitta ishlab turgan mijoz uchun muddat, VPN yetib borishda qolishining isboti emas. Bu jarayonni tirik saqlash siyosati ham emas, va chalkashlikning katta qismi shu yerdan boshlanadi.

Tepada ikkinchi mexanizm o‘tirsa, chalkashlik ortadi. Mijozni qayta ishga tushiruvchi nazoratchi, shlyuzni ping qiluvchi tekshiruvchi va ichki qurilgan qayta urinish oynasi bir xil nosozlikka javob berishi mumkin, va hodisa keyin hech kim kelishtira olmaydigan uchta vaqt chizig‘ini beradi.

Qayta ulanish oynasi aslida nimani cheklaydi

Kirish tarmog‘i bir necha soniya yo‘qolib qolishini tasavvur qiling. Mijoz aloqa uzilganini ko‘radi yoki o‘lgan hamkorning javoblarini eshitishni to‘xtatadi va o‘zi saqlab qola oladigan holatni ushlab, sessiyani qayta o‘rnatishni boshlaydi. Urinishlar shlyuz yana qabul qilmaguncha yoki oyna tugamaguncha davom etadi, va tugagan oyna nolga teng bo‘lmagan chiqish bilan yakunlanadi. Aynan shu chiqish, taymaut qiymati emas, hayot sikli egaligi jarayonni nazorat qiluvchiga o‘tadigan joy.

Oyna tekshiruvchi qanchalik tez-tez ishlashi haqida hech narsa demaydi va autentifikatsiyani uzaytira olmaydi. Agar shlyuz sessiyani bekor qilgan bo‘lsa yoki hisob endi yangi ikkinchi omilni talab qilsa, ko‘proq kutish eski sessiyani yana amal qiladigan qilmaydi. Qayta urinish faqat yo‘l qaytganda, shlyuz sessiyani hali taniyotganda va so‘ralgan hisob ma’lumotlari foydalanishga yaroqli bo‘lib qolganda muvaffaqiyatli bo‘ladi, shuning uchun bu sonni hayot oralig‘i emas, muddat deb o‘qing.

Oyna ishlab turgan paytda ilovalar nima qilishini ham tartibga solmaydi. Platforma va nosozlik qanchalik uzoqqa ketganiga qarab, mijoz marshrutlar hali o‘rnatilgan holatda yoki ular olib tashlangandan keyin qayta ulanayotgan bo‘lishi mumkin. Shuning uchun uzilish o‘rtasida berilgan so‘rov tez muvaffaqiyatsiz bo‘lish o‘rniga taymautgacha osilib turadi.

Nazoratchining qayta ishga tushirishlari va mijozning qayta urinishlari ikki qatlam

Ishlayotgan mijoz o‘z oynasini sarflasin, xizmat menejeri esa chiqishga javob bersin. systemd ostida qayta ishga tushirish siyosati bo‘lgan oldingi plandagi mijoz aynan shu bo‘linishni beradi: cheklangan davr uchun urinishlar, keyin bitta qayta ishga tushirish qarori. Natija keyin ham qayta qurish mumkin bo‘lgan bitta vaqt chizig‘i.

Fon rejimidagi mijoz va interfeys ko‘rinmasa boshqa nusxani ishga tushiruvchi mustaqil tekshiruvchi — bu noto‘g‘ri ketadigan andoza. Shunda ikkala jarayon bir xil qurilma tuguni, marshrutlar va resolver sozlamalari uchun raqobatlashadi. Agar chindan ham demon kerak bo‘lsa, parametrni mijoz haqiqatda boshlanadigan buyruq satriga qo‘ying:

sudo openconnect --background --pid-file=/run/openconnect/vpn.pid \
  --reconnect-timeout=180 \
  --user=<account> https://vpn.example.edu

Bu satrda ikkita tafsilot og‘irlikka ega. --background jarayonni ajratadi, shuning uchun pid fayli unga yagona ishonchli tutqichga aylanadi, va taymaut faqat o‘sha jarayon tirik bo‘lgan vaqtda sarflanadi; uni o‘ldirgan nazoratchi davom etish uchun byudjet qoldirmaydi.

Qasddan uzilishlar o‘z signaliga muhtoj. Rejalashtirilgan tanaffus va haqiqiy uzilish sodda kuzatuvchiga bir xil ko‘rinadi, ikkalasi ham «ulanmagan» deb o‘qiladi. Tanaffusni nazoratchining to‘xtatish amali yoki o‘ram tushunadigan belgi orqali boshqaring, shunda qasddan to‘xtash hech kim so‘ramagan qayta ishga tushirishni keltirib chiqarmaydi.

Topshirishning qayta urinish siklidan o‘zib ketishini oldini olish

Nazoratsiz tiklash odam hozir bo‘lmaganda yangilanadigan hisob ma’lumotlariga bog‘liq. Faqat interaktiv ish stoli sessiyasi ichida ochiladigan kalit bog‘lami yoki har doim terilgan kod talab qiladigan token yo‘l qaytganda mijozni autentifikatsiya bosqichida ushlab qoladi. Oynani uzaytirishdan oldin shu ish oqimini hal qiling, chunki uzunroq oyna faqat o‘sha bloklangan so‘rovga muvaffaqiyatsiz bo‘lish uchun ko‘proq vaqt beradi.

Server tekshiruvini so‘rovlarni kamaytirish uchun yumshatmaslik kerak. Shlyuzni tasdiqlovchi pin yoki ishonch langari aynan avtomatik qayta ulanishni xavfsiz qiladi, va sertifikat savolidan qochish uchun uni o‘chirish ko‘rinadigan uzilishni ko‘rinmas uzilish bilan almashtiradi. Tasdiqlangan shaxsni saqlang va o‘rniga so‘rovni tuzating; har qanday shlyuzga ulanishga tayyor mijoz to‘xtab kutadiganidan yomonroq.

Interfeys mavjudligi ham sog‘liq signali emas. Tunnel qurilmasi orqasida o‘lik sessiya bilan ham mavjud bo‘lishi mumkin, va ishga tushiruvchi jarayon umuman tunnelsiz ham mavjud bo‘lishi mumkin. Bu kuzatishlarning hech biri haqiqiy so‘rovga bardosh bermaydi. Sog‘liq foydalanuvchiga kerak bo‘lgan narsadan kelishi kerak, masalan, tunnel orqali ma’lum ichki xizmatga boradigan so‘rovdan.

Uzilish paytida va undan keyin nimani tekshirish kerak

To‘rtta hodisani alohida sinov sifatida o‘tkazing: oynadan qisqaroq uzilish, undan uzunroq uzilish, autentifikatsiya xatosi va qasddan to‘xtatish. Har biri boshqa, oldindan aytish mumkin bo‘lgan holatda tugashi kerak, va birinchi ikkitasi orasidagi chegara qiymat tanlashning butun sababi.

Tekshiruvlarni tashqariga qaratib turing, chunki jarayonlar jadvali o‘zi juda kam narsani isbotlaydi. pid qisqa uzilish davomida barqaror qolishini kuzating, keyin uzun uzilishdan so‘ng u ketganini va bir marta almashtirilganini tasdiqlang:

curl -sS --max-time 5 -o /dev/null -w '%{http_code}\n' https://intranet.example.internal/health
cat /run/openconnect/vpn.pid
ps -o pid,etime,cmd -p "$(cat /run/openconnect/vpn.pid)"

Qisqa uzilish paytida mijoz haqiqatan qayta urinmaganini emas, balki uriniganini, erta chiqib ketmaganini va marshrutlar hamda resolver yozuvlari takrorlanmasdan qaytganini tasdiqlang. Uzunroq uzilish uchun toza chiqish va undan keyin aynan bitta qayta ishga tushirish bo‘lganini tasdiqlang. Autentifikatsiya xatosi uchun mijoz uni rad etishda davom etadigan shlyuzga qarshi aylanmayotganini tasdiqlang. pid to‘planib qolmasdan bitta qiymatga qaytishini tekshirishni qo‘shing.

Qasddan to‘xtatish uchun sog‘liq URL yetib bo‘lmaydigan bo‘lib qolishi va jarayon pastda turishi kerak. Keyin siklni ilova tomondan yoping: o‘sha so‘rov tunnel yo‘q paytda muvaffaqiyatsiz bo‘lishi va u qaytgandan keyin sizning siyosatingiz kutgan manba manzilidan muvaffaqiyatli bo‘lishi kerak. Yashil tunnel belgisi isbot emas, lekin bajarilgan so‘rov isbot.