Bitta OpenVPN mijozida ikkita xizmat manzili: iroute va lo

Ilova o’z tunnel manzilida javob beradi, u uchun hujjatlashtirgan manzil esa hech qayerga olib bormaydi. OpenVPN jurnalida hech narsa shikoyat qilmaydi, tengdosh ulangan ko’rinadi va hub aynan bitta mijozni ro’yxatlaydi. Kamchilik shundaki, mijozdagi ikkinchi manzil ikki alohida fakt: xost unga egalik qilishi kerak va hub qaysi tengdosh egalik qilishini bilishi kerak. Birini ikkinchisisiz hal qilsangiz, trafik yo hubda o’ladi, yo uyga qaytish yo’lisiz keladi.

Taxallus mahalliy, egalik uzoqda

Tunnel manzili muzokara qilinadi, shuning uchun ikkala tomon ham uni qo’l siqish paytida o’rganadi. Qo’shimcha xizmat manzili umuman muzokara qilinmaydi, shuning uchun uni qo’shish hubda o’z-o’zidan hech narsani o’zgartirmaydi. Mijoz manzilga darhol egalik qilishi mumkin, server esa bu trafikni baribir o’z standart yo’liga yuboradi yoki tashlab yuboradi. Ikki yozuv, ikki xil joyda yaratilishi kerak.

Mijozda manzil xostga tegishli va loopback jismoniy tarmoqda hech qachon ko’rinmasligi kerak bo’lgan xizmat identifikatori uchun tabiiy uydir. Hubda tengdoshning prefiksga moslashuvi faqat server o’qiydigan alohida deklaratsiyadir. Yozuvlarning hech biri ikkinchisini nazarda tutmaydi.

Ikkala diapazonni yozuvlaringizda ham alohida saqlang. Misoldagi manzillar hujjat qiymatlari bo’lib, ularni haqiqiy LAN bilan ustma-ust qo’yish ishlaydigan sozlamani buzilgandek ko’rsatishning eng tez yo’lidir.

Manzilni mijozga doimiy ravishda qo’shing

Xizmat manzilini xost prefiksi bilan loopbackka qo’ying, shunda xost uni yetib boriladigan quyi tarmoq emas, mahalliy kirish deb biladi. ip address add 10.66.0.10/32 dev lo buni bitta manzil uchun qiladi, buyruqni ikkinchi manzil uchun takrorlash esa ikkita xizmatni modellashtiradi.

Buni bir martalik sinov sifatida ishga tushiring, so’ngra xostning tarmoq konfiguratsiyasiga egalik qiluvchi narsaga ko’chiring, chunki ishlash vaqtidagi qo’shimcha qayta yuklashda yo’qoladi va qayta ulanishlar orasida nusxalar to’planadi. Tarmoqdan keyin tartiblangan systemd birligi bir variant, tarqatma tarmoq menejeri esa boshqasi. Nima tanlasangiz ham, manzil ilova bog’lanishidan oldin mavjud bo’lishi kerak, aks holda xizmat noto’g’ri soketda ko’tariladi. Qo’lda buyruqdan keyin emas, qayta yuklashdan keyin ip address show dev lo bilan tekshiring.

Bog’lash manzillashdan alohida qaror. Har bir manzilda tinglaydigan ilova siz hech qachon mo’ljallamagan interfeyslarda trafikni qabul qiladi, shuning uchun uni aniq xizmat manziliga yo’naltiring. Shunda mahalliy kirish siyosatida aniq moslashtiradigan narsa bo’ladi.

Uni hub haqiqatan o’qiydigan CCD faylida talab qiling

Serverda egalik deklaratsiyasi autentifikatsiya qilingan umumiy nom bilan tanlanadigan har bir mijoz fayliga kiradi, client-config-dir nomlagan katalog ichida. Satr iroute 10.66.0.10 255.255.255.255, har bir manzil uchun bitta, va u serverga o’sha manzil uchun qaysi tengdosh trafik olishi kerakligini aytadi.

Ikki tafsilot buni jimgina buzadi. Fayl nomi server haqiqatan ishlatadigan nomga mos kelishi kerak, u esa username-as-common-name o’yinda bo’lganda boshqacha bo’ladi. Va iroute faqat mijoz konfiguratsiyasi katalogi sozlangan TUN rejimida amal qiladi, shuning uchun o’sha satr ko’prikli joylashtirishda hech narsa qilmaydi. Mavjud faylga satrlar qo’shing, uni almashtirmang, chunki unda allaqachon qat’iy manzil yoki push parametrlari bo’lishi mumkin. OpenVPN 2.6 ma’lumotnomasi katalog va egalik direktivasini hujjatlashtiradi.

Hubning o’z yadrosiga ham o’sha manzillar uchun yo’l kerak, mahalliy yaratilgan trafik tunnel jarayoniga kirishi uchun. Server konfiguratsiyasidagi route 10.66.0.10 255.255.255.255 server o’zi yaratadigan trafikni qamrab oladi, boshqa mijozlar esa manzilni o’zlari o’rganish uchun push "route 10.66.0.10 255.255.255.255" kerak.

Marshrutlash va avtorizatsiya alohida qoladi. Yuborilgan marshrut mijozga paketlarni qayerga yuborishni aytadi va hech narsa bermaydi; xizmat hali ham qo’ng’iroq qiluvchini o’z shartlari bilan qabul qilishi kerak.

Kirish siyosati va javob yo’lini tekshiring

Taxallusga manzillangan paket egalik qiluvchi xostga mahalliy kirish sifatida yetib boradi, shuning uchun savol mahalliy tarmoq devori o’sha manba va portga ruxsat beradimi. Butun manzilni ochish o’rniga VPN manba diapazonidan aniq xizmat portiga ruxsat bering.

Javoblar qo’ng’iroq qiluvchiga qaytish yo’lini talab qiladi. Oddiy tunnel hovuzidagi qo’ng’iroq qiluvchi uchun bu yo’l allaqachon mavjud, chunki uni tunnel qurilmasi olib yuradi. Boshqa marshrutlangan tarmoq orqasidagi qo’ng’iroq qiluvchi o’sha tarmoqning qaytish marshrutini ham talab qiladi, va aynan shu yerda asimmetrik sozlamalar paketlarni yo’qotadi.

Xuddi shu portda boshqa manzilga bog’langan ikkinchi tinglovchiga e’tibor bering, chunki yadro mos kelgan soketga yetkazadi va natijalar tasodifiy ko’rinadi. ss -lntp bilan tekshiring va bog’langan manzil xizmat taxallusi ekanini tasdiqlang. Bu yerda manba NAT talab qilinmaydi, uni qo’shish esa jurnallaringiz bog’liq bo’lgan qo’ng’iroq qiluvchi identifikatorini yashiradi.

Manzillar va egalikni alohida sinab ko’ring

Ikki qadamda sinab ko’ring. Avval egalik qiluvchi xost o’z taxallusidagi xizmatga o’zidan yetib borishini tasdiqlang, bu bog’lash va tarmoq devori muammolarini marshrutlashdan ajratadi. Keyin ilovaning o’z autentifikatsiyasidan foydalanib haqiqiy VPN qo’ng’iroq qiluvchisidan sinab ko’ring. Birinchisi o’tib, ikkinchisi muvaffaqiyatsiz bo’lsa, yetishmayotgan qism hub tomonida.

Ulanishdan keyin ham qoladigan nosozlik rejimlarini tekshiring: tunnel past bo’lganda ham taxallus tayinlangan qoladi, tengdosh yo’q bo’lganda ham hub o’z marshrutini saqlaydi. Hech bir obyekt yolg’iz xizmat yetib borilishini isbotlamaydi, shuning uchun ikki qadamli sinov noutbukdan bitta pingdan ustun.