VPN so‘nggi nuqtasi nomi va xususiy xizmat nomi: ikki egasi

Ikki nom bir filialni tasvirlab, butunlay boshqa savollarga javob berishi mumkin. vpn.branch.example uzoq hamkorga VPN so‘nggi nuqtasi qayerdan topilishini aytadi va har qanday tunnel paydo bo‘lishidan oldin hal qilinishi kerak. inventory.branch.example vakolatli foydalanuvchiga xususiy dastur qayerda joylashganini aytadi va tunnel ko‘tarilgandan keyingina muhim. Birini saqlash ikkinchisiga hech narsa qilmaydi.

Ikkalasini ham tuzatishdan oldin ikkala yozuvni nomlang

Ikkalasini egalari bilan birga yozing. So‘nggi nuqta uchun ommaviy manzilni kim yangilashini va VPN mijozi javobini qanday yangilashini yozing. Xizmat uchun xususiy manzil egasini, qaysi zona yozuvni saqlashini va qaysi hal qiluvchilar unga javob berishini yozing.

Bu qisqa ro‘yxat ushbu sohadagi eng keng tarqalgan noto‘g‘ri tashxisni oldini oladi: butunlay ichida yashaydigan yozuvni tuzatish uchun ishlayotgan filial tunnelini qayta ishga tushirish. Tunnel xizmat nomi uchun transport, u uning hokimiyati emas.

O‘zgarish taklif qilinganda, u ikki yozuvdan qaysi biriga tegishini so‘rang. Hech kim javob bera olmasa, o‘zgarish rejalashtirishga tayyor emas.

So‘nggi nuqta har qanday tunnel paydo bo‘lishidan oldin hal qilinishi kerak

Faraz qilaylik, filialning internet aloqasi yangi ommaviy manzil oldi. So‘nggi nuqta yangilovchisi yangi manzilni e’lon qiladi, uzoq VPN amalga oshirilishi esa o‘zgargan javobni o‘qiy olishi kerak. Qaysi hal qiluvchi bu javobni bersa ham, u tunnelsiz yetib borishi kerak, aks holda mijoz o‘zi topa olmaydigan narsaga ulangandan keyingina hal qila oladigan nom orqasidan quvadi.

Bu boshlang‘ich bog‘liqlikni ochiq aytishga arziydi, chunki barcha ichki hal qiluvchilar VPN orqasida bo‘lganda uni tasodifan yaratish oson. So‘nggi nuqtani qidirish uchun tunneldan oldingi yo‘lni saqlang va yangi javob darhol olinadi deb o‘ylash o‘rniga mijozning qayta ulanish xatti-harakatini tasdiqlang.

Dinamik DNS hamda yozuvni yangilash kesib o‘ta olmaydigan chegaralarga ega. Yozuvni yangilash hech qanday xavfsizlik devori portini ochmaydi, NAT xaritasini yaratmaydi va hamkorning shaxsini isbotlamaydi. Yopiq portli e’lon qilingan manzil to‘g‘ri hal qiladigan, lekin hech narsaga ulana olmaydigan mijozni beradi.

Oxirida, ishlayotgan mijoz qayta ulanmaguncha keshlangan so‘nggi nuqtadan foydalanishda davom etishi mumkin. Yozuvlaringizda e’lon qilishni, keshni va qayta ulanish siyosatini ajrating, eskirgan hamkor buzuq yangilovchi deb o‘ylanmasin.

Xizmat nomi dastur qayerda joylashganini tasvirlaydi

Endi tunnel sog‘lom qoladi, lekin inventar serveri 172.26.14.20 dan 172.26.14.35 ga ko‘chadi deb faraz qilaylik. Ommaviy so‘nggi nuqta yozuvi ta’sirlanmaydi, xususiy xizmat yozuvi esa o‘zgarishi kerak. Shu xizmat uchun ajratilgan manzil yoki statik taqsimlash buni kamroq uchraydigan qiladi; vakolatli yangilash yo‘li bu ataylab qilingan holatlarni hal qiladi.

Bu yerda ikkita yangilash mexanizmi aralashib ketadi. RFC 2136 zonada DNS yozuvlarini qo‘shish va o‘chirish protokolini belgilaydi, tijorat dinamik DNS provayderi esa boshqa maqsad uchun butunlay boshqa HTTP API taqdim etishi mumkin. Birini ishlatish ikkinchisi sizning muhitingizda borligini bildirmaydi. Unga qarshi yangilovchi yozishdan oldin zonangiz qaysi mexanizmni haqiqatda qabul qilishini tekshiring.

To‘g‘ri xususiy javob faqat birinchi shart. Uzoqdan qo‘ng‘iroq qiluvchi undan foydalanishi uchun mijozga xususiy zonani olib yuruvchi hal qiluvchi, shu hal qiluvchiga so‘rovlarga ruxsat beruvchi siyosat va qaytib keladigan manzil uchun yo‘naltirish kerak. Mijoz yeta olmaydigan manzilga hal bo‘ladigan nom server nosozligiga o‘xshab ko‘rinadigan vaqt tugashini keltirib chiqaradi.

Ikki yo‘lni alohida sinab ko‘ring

So‘nggi nuqtani tunneldan tashqaridan, xizmatni esa uning ichidan tekshiring va natijalarni ikki mustaqil fakt sifatida saqlang:

$ dig +short vpn.branch.example @1.1.1.1
$ dig +short inventory.branch.example @172.26.0.53
$ ip route get 172.26.14.35

Agar birinchi so‘rov muvaffaqiyatsiz bo‘lsa, muammo ommaviy e’lon qilishda yoki tunneldan oldingi hal qilish yo‘lida, va hech qanday ichki o‘zgarish yordam bermaydi. Ikkinchisi manzil qaytarsa, lekin uchinchisi tunnel orqali marshrut ko‘rsatmasa, DNS qatlami joyida, yo‘naltirish siyosati esa joyida emas.

Har bir manzil o‘zgarishidan keyin juftlikni ishga tushiring va qaysi yozuv siljiganini yozib qo‘ying. Faqat «DNS yangilandi» deb aytadigan topshirish keyingi muhandisga ikki hayot tsiklidan qaysi biri haqiqatda ishlaganini taxmin qilishga qoldiradi.