Qayta ishga tushirishdan keyin VPN serverining tiklanishini sinab ko'ring: birinchi navbatda nima tekshiriladi

Hech kim tizimga kirmagan holda serverni qayta ishga tushiring, so'ng o'zingiz boshqarmaydigan tarmoqdan ulanib ko'ring. Aynan shu bitta sinov tiklanish haqiqiy yoki yo'qligini javob beradi, chunki kimdir qo'lda buyruq ishga tushirgandan keyingina ishlaydigan tunnel tiklanish emas, ta'mirlashdir. Tekshiruvlarning ko'pchiligi juda erta to'xtaydi: demon faol ko'rinadi, interfeys ko'tariladi, lekin sahifa baribir yuklanmaydi. Bo'shliq deyarli har doim tunnel atrofidagi qismlarning barqarorligida, tunnel buyrug'ining o'zida emas.

To'rt egasi, to'rt xil sinov

Qayta ishga tushirishdan oldin tunnelni nima qaytarishi kerakligini nomlang. Siz o'tkazadigan sinov va qo'llaydigan tuzatish ikkalasi ham shu javobga bog'liq, va to'rtta odatiy egasi bor: VPN demoni uchun systemd unit, WireGuard interfeysi uchun wg-quick nusxasi unit, konteyner runtime yoki tarmoq menejeri profili. Agar egasini nomlay olmasangiz, to'xtang va toping, chunki kutilgan ishga tushish yo'li bo'lmagan qayta ishga tushirish sinovi faqat biror narsa sodir bo'lganini aytadi.

Har bir egasi konfiguratsiyasini boshqa joyda saqlaydi. systemd boshqaradigan OpenVPN serveri konfiguratsiyasini ishga tushishda o'qiydi, shuning uchun yuklash paytida faylda nima bo'lsa, o'sha ishlaydi. wg-quick interfeysi manzillari, marshrutlari va DNSni o'sha fayldan oladi, ya'ni qobiqdan qo'lda ko'tarilgan va hech qachon unit sifatida yoqilmagan interfeys qaytmaydi. Konteyner o'z kirish nuqtasini qaytaradi, lekin xostning firewall o'zgarishlarini emas, agar ular konteynerdan tashqarida bo'lmasa.

Avval asosiy holat, aks holda natijaning ma'nosi yo'q

Ishlayotganda ish holatini yozib oling: tunneldagi manzillar, mijoz quyi tarmog'i uchun marshrutlar, NAT yoki yo'naltirish qoidalari, tinglayotgan soket va yo'naltirish sysctl. ip addr show wg0, ip route, nft list ruleset yoki iptables-save, ss -lunp va sysctl net.ipv4.ip_forward ko'p xostlarda yetarli.

Xizmat ishlayotganini emas, balki u qanday qilib ishga tushishga sozlanganini yozing. systemctl is-enabled wg-quick@wg0 va systemctl is-active wg-quick@wg0 turli savollarga javob beradi, va yuklash paytida aynan yoqilgan holat muhim, systemctl(1) da tasvirlanganidek. OpenVPN uchun xost qaysi shablondan foydalanishini tekshiring, chunki openvpn@server va openvpn-server@server turli standart qiymatlarga ega turli unitlar.

Qayta ishga tushirishni bajaring va birinchi nosozlikni o'qing

O'zingiz tanlagan vaqt oynasida ataylab qayta ishga tushiring, konsol yoki tasma tashqarisi yo'li ochiq holda. Yakuniy holatni emas, voqealar tartibini kuzating: xost yetib boriladigan, unit faollashtirilgan, interfeys mavjud, marshrutlar o'rnatilgan, firewall qoidalari mavjud, tinglovchi bog'langan, mijoz qabul qilingan. Sodir bo'lmagan birinchi qadam topilma; undan keyingi hamma narsa shovqin.

Tunnel yaroqsiz bo'lsa ham demon faol bo'lishi mumkin, va bu eng keng tarqalgan noto'g'ri o'tish. Agar unit faqat network.target ni kutib, network-online.target ni emas, ishga tushish tarmoq onlayn bo'lishidan oldin tugashi mumkin. Sertifikatlar, kalitlar yoki CRL kabi havola qilingan fayllar o'sha paytda o'qilmasligi mumkin, chunki mount yoki sirlar yo'li hali tayyor emas. Ikkala muammo ham unit jurnalini o'qimaguningizcha systemctl status da ko'rinmaydi.

Xostdan tashqaridan sinab ko'ring. Xuddi shu LANdagi mijoz hech qanday masofaviy mijoz ishlatmaydigan marshrut orqali muvaffaqiyat qozonishi mumkin, va mashinaga SSH sessiyasi tunnel haqida hech narsani isbotlamaydi. Ulanib, ichki nomni hal qiling, xususiy resursga yetib boring, so'ng bekor qilish holati va kalitlar hali amal qilishini tasdiqlash uchun yana bir marta ulanib ko'ring.

Tuzatishingizni belgilaydigan uchta shart

Tunnel qaytsa, lekin mijozlar hech qayerga yetib bormasa, nosozlik marshrutlash yoki NAT barqarorligida. Agar mijozlar hatto qo'l berib ko'rishishni ham tugata olmasa, nosozlik interfeys yoki autentifikatsiya materialida. Agar xizmat hech qachon ishga tushmasa, nosozlik unit faylida yoki uning bog'liqliklarida. Bu uch shox turli tuzatishlarga olib boradi, shuning uchun asosiy holatsiz ko'r-ko'rona qayta ishga tushirish tejaganidan ko'ra ko'proq vaqt oladi.

Tuzatishni sozlama egalik qiladigan joyda qiling. Yo'naltirishni sysctl drop-in ga, NAT qoidalarini yuklash paytida yuklanadigan qoidalar to'plamiga qo'ying, unitni ishga tushirish o'rniga yoqing va sirlarni unit boshlanishidan oldin mavjud bo'lgan yo'lda saqlang. Unitga uyqu qo'shish bog'liqlikni e'lon qilish o'rniga yashiradi.

Natijani runbookda qayd eting

O'z-o'zidan nima qaytganini, nima ishga tushirishga majbur bo'lganingizni va bo'shliq qancha davom etganini yozing. Tekshirish uchun ishlatgan aniq buyruqlarni kiriting, keyingi odam yangisini o'ylab topmasdan sinovni takrorlashi uchun. Agar biror qadam qo'lda buyruq talab qilgan bo'lsa, o'sha buyruq konfiguratsiyaga tegishli, runbookda doimiy qadam sifatida emas.

So'ng keyingi sinovni xost tarmoq stekidagi keyingi o'zgarishdan keyingi vaqtga rejalashtiring, olti oydan keyingi kalendar sanaga emas. Siz himoya qilayotgan nosozlik rejimi doimiy bo'lib tuyulgan vaqtinchalik buyruqdir, va ular kimdir firewall qoidalarini tahrirlaganda yoki xizmatni yangi unitga ko'chirganda aynan paydo bo'ladi.