openfortivpn ulanayotganda marshrutlar va DNS kimga tegishli bo'lishi kerak?

Ishlayotgan openfortivpn sessiyasida to'rt bosqich bir-birining ustiga qatlanadi. Mijoz shlyuzda autentifikatsiyadan o'tadi va TLS aloqasini boshlaydi, so'ngra shu aloqa ichida PPP ishga tushiradi, keyin manzil va DNS ma'lumotini oladi, oxirida xost marshrutlari va resolver sozlamalarini qo'llaydi. Har bir bosqich keyingisi yo'q bo'lganda ham tirik bo'lishi mumkin, shuning uchun qo'llab-quvvatlash mavzularida “ulangan” so'zi shunchalik silliq.

Chalkashlikning ko'pini bartaraf etadigan qaror — oxirgi bosqich kimga tegishli ekani. Yo VPN mijozi xost o'zgarishlarini o'zi qo'llaydi, yoki buni boshqa komponent qiladi, ikkalasini yarim yo'lda aralashtirish esa marshrutlar va resolver fayllari turli sessiyalarni tasvirlashiga olib keladi.

Bitta aloqaga o'xshab ko'rinadigan to'rt bosqich

Birinchi bosqich — qabul. nomlangan autentifikatsiya domeni yoki bir martalik kod orqali, davom etish uchun kerakli parametrlarni oladi. Mijoz shlyuzga ulanganini chop etganda, bu TLS transporti ishlayotganini bildiradi. Bu PPP kelishganini bildirmaydi va albatta ichki ilova yetib borishini bildirmaydi.

Ikkinchi bosqich — PPP aloqasi. Mijoz tunnel qurilmasiga qarshi PPP jarayonini boshlaydi, ikki tomon aloqa parametrlari va manzillarni kelishadi. Shundan keyingina xost sessiya qaysi lokal va uzoq manzillarni ishlatishini biladi, va shundagina tunnelga qaratilgan marshrut mazmunga ega bo'ladi.

Uchinchi bosqich — bu ma'lumotni xostga qo'llash, va aynan shu yerda egalik muhim. Mijoz marshrutlarni qo'shishi va resolver konfiguratsiyasini qayta yozishi mumkin, yoki unga chekinib, ikkalasini o'sha mashinada tarmoqni boshqaradigan narsaga qoldirish aytilishi mumkin. Loyihaning README bularni bitta avtomatik xatti-harakat emas, alohida mas'uliyatlar deb tavsiflaydi.

Marshrutlash jadvalini kim tahrirlaydi

Odatiy holda egasi mijoz. U jismoniy interfeys orqali shlyuzga marshrut, tunnel sherigi uchun marshrut va sessiyaga foydalanish ruxsat etilgan tarmoqlar uchun marshrutlar qo'shadi, so'ngra jarayon chiqqanda ularni olib tashlaydi. Bu odatiy qiymat bitta tarmoq menejeri bo'lgan va boshqa VPN dasturi yo'q noutbukda qulay.

O'tkazishni faqat boshqa narsa marshrutlashga haqiqatan ega bo'lganda tanlang. Tarmoq menejeri integratsiyasi, konteyner tarmoq nomlar fazosi yoki butun sayt marshrutlash agenti o'sha prefikslarni qanday o'rnatish va tozalashni allaqachon bilishi mumkin. no-routes parametrini berish u holda ikki yozuvchining bir xil jadval uchun kurashini oldini oladi, bu esa toza nosozlik emas, bitta subnetworkning vaqti-vaqti bilan yo'qolishi ko'rinishida namoyon bo'ladigan poyga.

Qatlamlanish — o'tkazishning ikkinchi sababi. Agar itarilgan marshrutlar lokal tarmoq allaqachon ishlatadigan prefiksni o'z ichiga olsa, mijoz ziddiyatni siz uchun hal qila olmaydi. Kimdir bu prefiks tunnel orqali, jismoniy aloqa orqali yoki aniqroq marshrut orqali yetib borishini hal qilishi kerak, va bu qaror topologiyaga ega bo'lgan kishiga tegishli.

Tozalash — uchinchisi. Marshrutlarini olib tashlashdan oldin qulagan mijoz sessiyadan uzoq yashaydigan qora tuynuk qoldiradi, va keyingi aloqa uning ustiga nusxa qo'shishi mumkin. Kim marshrutlashga ega bo'lsa, eski yozuvlar yo'qolganini tekshirishga ham ega. Bu tekshiruvni ishga tushish yo'lining qismiga aylantiring, ixtiyoriy tozalash qadami emas.

DNS va resolver fayliga kim ega

DNS — xuddi shu qaror, lekin qirralari o'tkirroq. Mijoz shlyuz yoki PPP sherigi bildirgan DNS serverlarini qabul qilib, ularni xost resolver konfiguratsiyasiga yozishi mumkin. Oddiy mashinada aynan shu narsa kerak, chunki ichki nomlar faqat tunnel ishlayotganda hal qilinadi.

Zamonaviy Linux xostida resolverni lokal stub boshqarishi mumkin, va resolver faylini o'sha stubning orqasida qayta yozish to'g'ri ko'rinadigan, ammo izchil bo'lmagan xatti-harakat qiladigan konfiguratsiya yaratadi. Agar xost allaqachon resolver menejerini ishga tushirsa, DNS unga tegishli bo'lsin va tunnel serverlarini uning qo'llab-quvvatlanadigan interfeysi orqali bering. Mijozning no-dns parametri u yerda to'g'ri tanlov, aylanib o'tish emas.

Bo'lingan DNS — faylni kim yozishidan alohida savol. Har bir so'rovni tunnel orqali yuborish oddiy va sekin; u orqali faqat ichki zonalarni yuborish ko'pchilik oddiy mijozlar taklif qilmaydigan domen bo'yicha konfiguratsiyani talab qiladi. Mijozning resolver o'zgarishlarini yoqishdan oldin xostga qanday xatti-harakat kerakligini hal qiling. Bu yerda noto'g'ri tanlov tunnelning o'zi yaxshi bo'lsa ham nomlarni hal qilish uzilishiga o'xshaydi.

Imtiyoz, tayyorlik va o'tkazish

Tunnel qurilmasini yaratish va xost marshrutlari yoki resolver holatini tahrirlash yuqori tarmoq vakolatini talab qiladi. Odatiy xato — shu sababli hamma narsa root sifatida ishlashi kerak deb xulosa qilish, jumladan brauzer yoki tunneldan foydalanadigan ilova. Imtiyozli qismni kichik saqlang: mijoz va uning konfiguratsiya fayli administratorga tegishli, foydalanuvchi ilovalari esa odatiy hisobini saqlab qoladi.

Tayyorlik har bir iste'molchi uchun belgilanishi kerak. Nazoratchi xizmatni mijoz jarayoni ishlayotganda va tunnel qurilmasi mavjud bo'lganda boshlangan deb hisoblashi mumkin. Zaxira vazifasi VPNni faqat saqlash oxirgi nuqtasi tunnel orqali javob berganda ishlatsa bo'ladigan deb hisoblashi kerak. Bular turli tekshiruvlar, va kuchsizroqni kuchliroq maqsad uchun ishlatish juda erta boshlanadigan va vaqti-vaqti bilan muvaffaqiyatsiz bo'ladigan ishlarni keltirib chiqaradi. Tanlangan ta'rifni yozib qo'ying, chunki tayyorlik haqida kelishmaydigan nazoratchi va vazifa — sodir bo'lishini kutayotgan qo'llab-quvvatlash chiptasi.

Shartnomani to'rt kuzatish bilan sinab ko'ring: shlyuz bosqichi tugaydi, PPP manzillarni tayinlaydi, ko'zda tutilgan marshrut mavjud va ichki xostga so'rov muvaffaqiyatli bo'ladi. So'ngra mijozni to'xtatib, ularning har biri olib tashlangan yoki tiklanganini tasdiqlang. Agar tunnel yopilgandan keyin ham xost ichki nomlarni hal qilsa yoki hali ham marshrutni ushlab tursa, egalikni o'tkazish to'liq emas.