pfSense'da OpenVPN uzilishlarini qayta ulashning uch turi, uch mexanizm

pfSense'da „OpenVPN failover“ kamida uchta bir-biriga bog'liq bo'lmagan loyihani qamrab oladi va har biri boshqa mexanizmni talab qiladi. Tunnelni zaxira internet liniyasi orqali tirik saqlash, boshqa serverga qayta ulanish va LAN trafigini boshqa o'rnatilgan tunnelga yo'naltirish bitta funksiyaning variantlari emas. Shlyuz guruhini qurishdan oldin qaysi nosozlikdan himoyalanayotganingizni tanlang. Ulardan birini tuzatadigan guruh qolgan ikkitasi uchun hech narsa qilmaydi.

Guruh qurishdan oldin nosozlikni nomlang

Uzilish paytida to'g'ri bo'lishini xohlagan gapni yozing. „Tunnel zaxira WAN orqali qayta ulanadi“ va „filial hali ham boshqa tunnel orqali ilovaga yetib boradi“ — bu boshqa gaplar. Faqat birinchisi transport haqida.

Keyin uni mexanizmga bog'lang. Mahalliy WAN yo'qolishi — interfeys tanlash muammosi, o'lik uzoq nuqta — ulanishlar ro'yxati muammosi, o'rnatilgan tunnel ichidagi yaroqsiz yo'l esa marshrutlash va siyosat muammosi.

Mahalliy WAN: transportni ko'chirish

pfSense OpenVPN mijozi uchun qo'llab-quvvatlanadigan ko'p WAN tuzilmasi moslama bog'lanadigan interfeys sifatida tegishli shlyuz guruhini tanlaydi. Asosiy liniya ishlamay qolganda tashqi ulanishning zaxira liniyadan chiqishiga aynan shu imkon beradi. O'z-o'zidan u ichki trafikning qanday marshrutlanishini o'zgartirmaydi.

Xuddi shu loyihaning server tomoni alohida. Bir nechta ommaviy manzillar orqali yetib borilishi kerak bo'lgan OpenVPN serveri har bir yozuv uchun tinglovchi va kirish siyosatini talab qiladi, faqat ikkita liniyadan qo'ng'iroq qila oladigan mijoz emas. Ishlayotgan bitta ommaviy yozuv ikkinchisi sozlanganiga dalil emas.

Uzatiladigan LAN paketlari uchun siyosatga asoslangan marshrutlash qoidasi mahalliy yaratilgan VPN transport ulanishini ko'chiradigan sozlama emas. Bular ikki xil qidiruv va birini o'zgartirish ikkinchisini o'zgartirmaydi.

Uzoq nuqta: boshqa server

Alternativ remote — ulanishlar ro'yxatining funksiyasi. Joriy yozuv javob bermasa, mijoz keyingisini sinab ko'radi; bu aniq bir xost ishlamay qolganda foydali, o'zingizning yuqori liniyangiz ishlamay qolganda emas. Ikki nosozlik foydalanuvchi stolidan bir xil ko'rinadi va turli tuzatishlarni talab qiladi.

Har bir nomzod haqiqiy o'rinbosar bo'lishi kerak: mos autentifikatsiya, mos mijoz siyosati va bir xil xususiy resurslarga kirish. Bir xil buzilgan infratuzilmaga hal bo'ladigan ikkinchi xost nomi zaxira emas. Kerakli marshruti yo'q server ham emas, uning qo'l siqishi qanchalik sog'lom ko'rinmasin.

Bu mexanizm ikki tunnelni bir vaqtda uzatishga ham majburlamaydi. U bir ulanishni ikkinchisi bilan ketma-ket almashtiradi va ular orasidagi bo'shliq ishlab turgan hamma narsaga ko'rinadi.

Tunnel yo'li: boshqa chiqishni tanlash

Ikki tunnel allaqachon turgan bo'lsa va trafik sog'lomrog'idan foydalanishi kerak bo'lsa, mexanizm — o'z shlyuziga ega tayinlangan VPN interfeysi va to'g'ri trafikni u yerga yuboradigan aniq siyosat qoidasi. O'sha tayinlangan interfeyslar ustidagi shlyuz guruhi ustuvorlik va kuzatuvni ifodalashi mumkin.

Bu loyiha tanlov haqida, tiklash haqida emas. Yangi ulanishlarni ikkinchi tunnelga ko'chirish birinchisida allaqachon o'rnatilgan sessiyalar haqida hech narsa demaydi va qarshi tomon yangi manba manzilini qabul qiladimi, bu haqda ham hech narsa demaydi. Unga tiklash mexanizmi sifatida qarash — kutilmalarni juda baland qo'yish yo'li.

Agar talab mavjud sessiyalarning omon qolishi bo'lsa, buni aniq ayting. Ko'pchilik amalga oshirishlar tirik oqimni tunnellar orasida ko'chirmaydi, va ko'chiradi deb loyihalash diagrammada to'g'ri ko'rinadigan, amalda esa har bir ochiq ulanishni tashlab yuboradigan failover beradi.

Monitorlar, NAT va fail-closed qoidasi

Monitor tunnel yetkazishi kerak bo'lgan narsani sinashi kerak. Tunnel sherigidan javob beradigan, lekin uning orqasidagi ilova tarmog'idan javob bermaydigan nishon foydalanuvchilar hech narsa ko'rmayotganda sog'lom deb xabar beradi. Yetib bo'lmaydigan diagnostik nishon yo'l joyida bo'lganda o'lik deb xabar beradi. Manzilni ataylab tanlang va unga faqat mo'ljallangan tunnel orqali yetish mumkinligini tasdiqlang.

Ikkala chiqish uchun chiquvchi NATni tekshiring. Asosiyda ishlaydigan tarjima zaxiraning manba manzilini tavsiflamaydi va uzoq xususiy tarmoq siz taqdim qilgan manbaga mos keladigan qaytish marshrutini talab qiladi. Bir yo'lda to'g'ri bo'lgan tarjima boshqasida jimgina noto'g'ri bo'lishi mumkin.

Keyin hech qachon WAN ishlatmasligi kerak bo'lgan trafik bilan nima bo'lishini hal qiling. pfSense tanlangan shlyuzi ishlamay qolgan qoidalar uchun belgilangan xatti-harakatga ega va keyinroq keladigan keng o'tkazish qoidasi yoki standart marshrut niyatingizni bekor qilishi mumkin. Bloklangan natijani talab sifatida yozib qo'ying, so'ng yo'lni o'chirib uni tekshiring.

Yo'qotish va tiklashni alohida-alohida sinang, yaratishga ruxsat berilgan trafik bilan va bir vaqtda uch narsani kuzating: tashqi ulanishni ko'tarib turuvchi WAN, ilova so'rovini ko'tarib turuvchi tunnel va javob oladigan yo'l. Bir juft yashil shlyuz ko'rsatkichi o'sha uchtadan biri emas. Netgate'ning ko'p WAN bo'yicha qo'llanmasi bu tayanadigan transport bog'lanishi va eksport qilinadigan mijoz alternativalarini tavsiflaydi.