VPN orqali DHCP: translyatsiyani ko‘prik bilan o‘tkazish yoki relemi?
Tunnelning narigi tomonidagi mijozlar manzil olmaydi. Translyatsiyani olib o‘tish yoki rele orqali yuborishni hal qiling va DHCPni ARPdan alohida saqlang.
Tunnelning narigi tomonidagi yangi noutbuk manzil olmaydi, holbuki o‘sha noutbuk bosh ofisda ishlaydi. Odatiy birinchi taxmin tunnel DHCPni to‘sib turgani. Ko‘pincha translyatsiyaning yo‘li umuman bo‘lmagan: sozlanmagan mijoz 255.255.255.255 manziliga yuboradi, oddiy IP marshrutizator esa bu paketni uzatmaydi. Tunnel aynan marshrutlangan tunnel qiladigan ishni qilmoqda.
Ikki loyiha buni o‘zgartirishi mumkin va ular teng emas. Biri translyatsiyani olib yuradi; ikkinchisi so‘rovni rele orqali yuboradi.
Translyatsiya hech qachon marshrutizatordan o‘tmaydi
Manzilsiz DHCPv4 mijozi 0.0.0.0 dan cheklangan translyatsiya manziliga UDP 67 va 68 portlari orqali yuboradi. Bu paket dizayni bo‘yicha o‘z havolasida qoladi. Uni uzatadigan marshrutizator o‘zi xizmat qiladigan har bir segmentni suv bosgandek to‘ldirardi.
Shuning uchun marshrutlangan sayt-sayt tunnel releni serverga ulaydi. U mijozning translyatsiya domenini kengaytirmaydi va hech bir xavfsizlik devori qoidasi buni qilmaydi.
Ko‘prik qilingan tunnel aslida nimani kengaytiradi
Ataylab ko‘prik qilingan VPN o‘z qo‘llab-quvvatlanadigan topologiyasida Ethernet translyatsiyasini olib yurishi mumkin, shunda DHCP mahalliy trafik sifatida o‘tadi. Bu haqiqiy variant, lekin 2-qavat loyihaviy qarori. Siz translyatsiya bilan birga nosozlik domeni va kirish chegarasini ham kengaytirmoqdasiz.
Ko‘prik translyatsiya bo‘roni, ARP skanerlash yoki yolg‘on DHCP server qayerga yetib borishini ham o‘zgartiradi. Agar masofaviy ofisni o‘sha kommutatorga ulamayotgan bo‘lsangiz, faqat manzil tarqatish uchun tunnelni ko‘prik qilmang. Yoqishdan oldin o‘sha ta’sir radiusini sinab ko‘ring.
Bu manzil berishdan kattaroq qaror va uni ataylab qabul qilish kerak.
Buning o‘rniga so‘rovni rele orqali yuboring
Odatiy javob mijozning mahalliy tarmog‘idagi rele. U translyatsiyani qabul qiladi, uni unicast so‘rovga aylantiradi va o‘z manzilini shlyuz manzili maydoniga qo‘yadi. Server o‘sha rele manziliga javob beradi.
Misol uchun masofaviy ofisda rele ofisning LANida turadi, serverga esa sayt VPNi orqali yetiladi. O‘sha ofis uchun qamrovni, rele va server identifikatorlarini hamda to‘liq qaytish yo‘lini sozlang. Tunnel orqali UDP 67 ga ruxsat berish serverga qaysi hovuzni ishlatishni aytmaydi.
Uzatadigan, lekin hech qachon javob olmaydigan rele odatda qaytish yo‘li muammosi. Qamrovni o‘zgartirishdan oldin rele manziliga qaytish marshrutini tekshiring.
DHCPni ARPdan va tunnel manzillaridan ajrating
DHCP UDP/IP ustida ishlaydi. Ethernetda xost nomzod manzil allaqachon band yoki yo‘qligini tekshirish uchun ARPdan ham foydalanishi mumkin. Bu to‘qnashuv tekshiruvi alohida havola-mahalliy amal, DHCP xabarlarining transporti emas. DHCP mohiyatan ARP deb aytish xato; ikkalasi hech qachon bog‘liq emas deb aytish juda keng.
VPN mijozi tunnel manzilini DHCP translyatsiyasidan emas, VPN protokolidan yoki serverning o‘z hovuzidan ham olishi mumkin. Nomida DHCP bor opsiya rele qilingan DHCP paketini emas, mijozga surilgan sozlamalarni tavsiflashi mumkin. DHCP umuman ishtirok etadi deb taxmin qilishdan oldin server hovuzini tekshiring.
Qabul qiluvchi tarmoqni, taqsimot egasini, qamrovni, rele bor-yo‘qligini va uzilish vaqtida kutiladigan xatti-harakatni yozib qo‘ying. So‘ngra shu model orqali yangi ijara va yangilanishni sinab ko‘ring. Agar ikki sayt bir xil boshqarilmaydigan hovuzga xizmat qila olsa, sizda birinchi ko‘chib yuruvchi noutbukni kutayotgan to‘qnashuv bor.