OpenVPN client-connect xatosi: disconnect paytida tozalash kafolatlanganmi?
Rad etilgan mijoz firewall qoidasini yoki yozilgan yozuvni qaytarmaydi. Callback shartnomasini hookingiz o‘zi bajarishi kerak bo‘lgan qaytarish bilan solishtiring.
Qachon client-connect skripti nolga teng bo‘lmagan kod bilan chiqsa, OpenVPN mijozni rad etadi va operatorlar odatda mos keluvchi client-disconnect skripti hammasini tartibga soladi deb o‘ylaydilar. Ko‘pincha u umuman ishga tushmaydi, chunki disconnect qayta ishlanishi connect bosqichi nimalarni tugata olganiga bog‘liq. Rad etish va qaytarishni bitta mexanizm deb qarash muvaffaqiyatsiz kirishni oqib ketgan firewall qoidasiga yoki egasiz yozuvga aylantiradigan narsadir. Bular ikkita alohida majburiyat va ulardan faqat bittasi avtomatik. Serverni holat qoldirganlikda ayblashdan oldin hookning o‘z chiqish yo‘lini o‘qing.
Nolga teng bo‘lmagan chiqish mijozni rad etadi; u ishingizni qaytarmaydi
client-connect chiqish holati qabul qilish qaroridir. Nol qabul qilish degani, boshqa har qanday qiymat nusxani to‘liq o‘rnashmasdan turib buzish degani. Bu shartnomada skriptning tashqi dunyoga nima qilganini tekshiradigan hech narsa yo‘q. Agar skript iptables qoidasini qo‘shgan, satr yozgan yoki hisoblagichni oshirgan bo‘lsa, bu o‘zgarishlar rad etishdan keyin ham saqlanib qoladi.
Xuddi shu assimetriya plaginlarga ham tegishli, bu yerda bitta nusxa uchun bir nechta connect funksiyalari ishlashi mumkin. Keyingi muvaffaqiyatsizlik avvalgi muvaffaqiyatni orqaga qarab bekor qilmaydi va avvalgi funksiya qardosh funksiya muvaffaqiyatsiz bo‘lganini bilishning yo‘lini topa olmaydi.
Rad etish avtomatik, tozalash esa emas
OpenVPN 2.6 qo‘llanmasi client-disconnect qayta ishlanishini avvalgi connect qayta ishlanishining muvaffaqiyatiga bog‘laydi. Hujjatlashtirilgan istisno kaskad zanjirlarni qamrab oladi: agar bitta connect qadami allaqachon muvaffaqiyat qaytargan bo‘lsa, nusxa buzilayotganda tegishli disconnect qadamlar baribir ishlaydi, hatto keyingi connect qadami muvaffaqiyatsiz bo‘lsa ham. Bu istisno tor va qancha callback sozlanganiga bog‘liq, shuning uchun bitta shell skriptini sinash zanjir haqida sizga hech narsa aytmaydi.
Dizayn qilishdan oldin haqiqiy konfiguratsiyani xaritaga tushiring: qaysi skript, qaysi plagin va qanday tartibda ishlaydi. Quyidagi jadval yarim tugallangan sozlama orqada nima qoldirishini sanab o‘tadi.
| What the hook did before failing | What the client sees | What stays behind |
|---|---|---|
| Created a firewall entry | A rejection, with no tunnel | A rule matching an address nobody owns |
| Wrote a state row | A rejection, with no tunnel | A record of a session that never started |
| Allocated a tunnel address | A rejection, with no tunnel | An address marked busy until something releases it |
Har bir satr mijoz uchun bir xil, xost uchun esa boshqacha tugaydi. Mijoz ulardan qaysi biri sodir bo‘lganini ayta olmaydi, shuning uchun hook muvaffaqiyatsizlik holatini qaytarishdan oldin qilganini qaytarishi kerak.
Muvaffaqiyatsiz bo‘lgan skriptning ichida qoplang
Umumiy holatga tegishdan oldin imkoni boricha hammasini tekshiring: sertifikat maydonlari, manzil mavjudligi, mijoz tegishli bo‘lgan guruh. Eng arzon rad etish har qanday ajratishdan oldin sodir bo‘ladiganidir. Sozlama bir nechta tashqi operatsiyani qamrab olganda, qaysilari tugaganini yozib boring va muvaffaqiyatsizlik holatini qaytarishdan oldin ularni teskari tartibda qaytaring.
Aniq holat: skript har bir mijoz uchun firewall yozuvini yaratadi, so‘ngra uni tavsiflovchi holat satrini yozishda muvaffaqiyatsizlikka uchraydi. Muvaffaqiyatsiz shox hozir yaratilgan yozuvni olib tashlashi va keyin nolga teng bo‘lmagan kod bilan chiqishi kerak. Hech qachon rejalashtirilmasligi mumkin bo‘lgan disconnect hodisasini kutish qoidaning o‘zi mo‘ljallangan sessiyadan uzoqroq yashashining yo‘lidir.
Qoplashni idempotent va egali qiling
Tozalash ikki marta ishga tushirish uchun xavfsiz va nimalarni o‘chirishi mumkinligi bo‘yicha aniq bo‘lishi kerak. Avvalgi urinishdan kechikkan hodisa yangiroq sessiyaning ajratilishini faqat ikkisi umumiy nom yoki qayta ishlatilgan tunnel manzilini bo‘lishgani uchun olib tashlamasligi kerak. Muayyan tutqich yoki operatsiya identifikatorini resurs bilan birga yozib qo‘ying va nom bo‘yicha emas, o‘sha kalit bo‘yicha o‘chiring. Ma’lumotlar bazasi tranzaksiyalari faqat bazaning o‘z o‘zgarishlariga yordam beradi; bu chegaradan tashqaridagi firewall qoidasi aniq qoplash qadamini talab qiladi.
Jarayon o‘zgarish va tozalash orasida o‘lishi mumkin deb hisoblang va jadval bo‘yicha tashqi holatni qabul qilingan mijozlar ro‘yxati bilan solishtiruvchi moslashtiruvchini qo‘shing.
Haqiqatan farq qiladigan uchta yo‘lni sinab ko‘ring
Uchta holatni mashq qiling: hech narsa ajratilmasdan oldin rad etish, qisman ajratishdan keyin rad etish va keyinroq tugaydigan oddiy qabul qilingan sessiya. Bu uchtasi turli jurnal satrlari va turli qoldiqlar hosil qiladi. Har biridan keyin tashqi holatni tekshiring, faqat mijozning muvaffaqiyatsizlik xabarini emas, chunki uchtadan ikkitasida mijozning muvaffaqiyatsizligi kutilgan natijadir.
hook bosqichini, chiqish holatini va nima ajratilgani yoki bo‘shatilganini hisob ma’lumotlarisiz yozib oling. O‘zi yaratgan resursni nomlaydigan hook jurnali oqib ketgan qoidani olti oydan keyin topish imkonini beradigan narsadir.