SoftEther SecureNAT: DHCP va NAT ikki alohida qaror

SecureNAT ikkita xizmatni yoqadigan bitta katakcha, va u haqidagi chalkashlikning katta qismi shu yerdan kelib chiqadi. Virtual DHCP server mijozga manzil, maska, shlyuz va ko'pincha hal qiluvchi beradi. Virtual NAT esa server xostining o'z tarmoq stegi yordamida paketlarni shu shlyuzdan nariga uzatadi. Ikkalasi konfiguratsiyada yonma-yon turadi va bir-biridan mustaqil ishdan chiqadi: mijozning mukammal ijarasi bo'lib, ishlaydigan yo'li bo'lmasligi mumkin, yoki ishlaydigan yo'li bo'lib, sozlamalari noto'g'ri hal qiluvchiga ishora qilishi mumkin. Ularni ikki qaror sifatida tekshiring, tashxis qisqaradi.

Bitta katakcha ortidagi ikki xizmat

Virtual DHCP tomoni konfiguratsiya savoliga javob beradi: bu mijoz bu virtual hub ichida qanday sozlamalarni oladi. Virtual NAT tomoni uzatish savoliga javob beradi: mijoz hubdan tashqaridagi manzilga paket yuborganda, server uni tarjima qilib uzatadimi. Birinchisi hub uchun lokal va yuqori tarmoqni talab qilmaydi. Ikkinchisi butunlay xostga bog'liq.

Virtual xost interfeysi birinchi qarorga tegishli, ikkinchisiga emas. Uning manzili, ko'pincha standart bo'yicha 192.168.30.1 kabi narsa, DHCP xizmati taklif qiladigan shlyuzdir. Bu serverning ommaviy tinglash manzili emas, va ikkalasini aralashtirish o'sha tarmoqda mavjud bo'lmagan mashinaga qaratilgan fayrvol qoidalari va mijoz sozlamalarini keltirib chiqaradi.

Qaror 1: manzilni kim beradi

Agar virtual DHCP yoqilgan bo'lsa, mijozlar siz sozlagan hovuzdan ijara olishi kerak, shlyuz sifatida virtual xost interfeysi va hal qiluvchi sifatida siz bergan qurilma. Mijozning holat matnini emas, ijarani ko'zdan kechiring, chunki «ulangan» tunnelni tasvirlaydi, manzil taqsimotini emas:

vpncmd localhost /SERVER /CMD SecureNatStatusGet
vpncmd localhost /SERVER /CMD DhcpGet
ip -4 addr show
ip route

Boshqa narsani tuzatishdan oldin bilishga arziydigan ikki nosozlik usuli bor. Avvalgi loyihadan qolgan statik manzilga ega mijoz uni saqlab qoladi va ijarani e'tiborsiz qoldiradi, bu esa DHCP javob berishdan bosh tortayotgandek ko'rinadi. Va ko'prikli segmentdagi ikkinchi DHCP manbasi o'sha mijozlar uchun raqobatlashadi, natijada manzillar vaqti-vaqti bilan o'zgaradi va muammoni qayta hosil qila olmaydigan qo'llab-quvvatlash navbati paydo bo'ladi.

Ustma-ust tushadigan hovuzlar ham shu yerga kiradi. Agar virtual DHCP hovuzi xostning LAN quyi tarmog'i yoki boshqa hub hovuzi bilan ustma-ust tushsa, mijoz noaniq marshrutlanadigan manzil oladi va keyingi har bir sinov natijasiz bo'ladi.

Qaror 2: virtual shlyuzdan nariga kim uzatadi

Virtual NAT yoqilganda server hubdan chiqadigan trafikni tarjima qiladi va xostning marshrutlash jadvali orqali yuboradi. Bu uzatish zanjiri quyidagicha degani: mijozdan virtual shlyuzga, virtual NATdan xost stegiga, xost stegidan o'zining standart yo'liga. Har bir bo'g'in boshqalarga tegmasdan ishdan chiqishi mumkin va nosozlik belgilari turlicha.

Ikkinchi qarorni hubdan chiqishi shart bo'lgan narsa bilan sinab ko'ring, unga lokal narsa bilan emas. Virtual shlyuzni ping qilish faqat birinchi bo'g'inni isbotlaydi, undan boshqa hech narsani:

vpncmd localhost /SERVER /CMD NatGet
vpncmd localhost /SERVER /CMD NatTable
dig +short example.com
ip route get 203.0.113.10

Agar nomlarni hal qilish ishlab, ommaviy manzilga ulanishlar muvaffaqiyatsiz bo'lsa, siz DHCPda emas, uzatish zanjirida turibsiz. Ikkalasi ham muvaffaqiyatsiz bo'lsa, avval hal qiluvchini tekshiring, chunki yetib bo'lmaydigan ichki manzil sifatida yuborilgan hal qiluvchi ishlaydigan yo'lni butunlay buzilgan ko'rinishga keltiradi.

SecureNATning uzatishini server jarayoni amalga oshiradi, ko'prik bilan ishlatadigan yadro uzatish yo'li emas. Bu qulay va ko'priklashdan sekinroq, shuningdek xostning o'z fayrvol qoidalari va marshrutlash qarorlari tarjima qilingan trafikka ham tegishli ekanini bildiradi. Virtual NAT xost siyosatini chetlab o'tmaydi; undan foydalanadi.

Xostning o'z yo'li uchinchi narsa

Yuqoridagilarning barchasi server xosti manzilga yeta oladi deb hisoblaydi. Ishlaydigan yuqori marshruti yo'q, chiqish siyosati qattiq yoki o'zida bo'lmagan manzil oilasiga ega xost hub konfiguratsiyasi qanchalik to'g'ri bo'lsa ham ikkinchi qarorda muvaffaqiyatsiz bo'ladi. Xostni alohida, tunneldan tashqarida tekshiring, uning nosozligini SoftEtherga yuklashdan oldin.

SecureNAT serverga ulangan har bir tarmoqqa yetish huquqi ham emas. U o'ziga yetib kelgan trafikni tarjima qiladi va uzatadi; xost nimaga yetishi mumkinligini hal qilish hali ham xostning fayrvoli va marshrutlashi ishi, va kirish berishda tunnelga tayanadigan loyiha haddan tashqari ko'p berishdan bitta yomon qoida uzoqda.

Manzil oilalari o'z tekshiruviga loyiq. Ishlaydigan IPv4 DHCP misoli sizning qurilmangizda IPv6ning har bir imkoniyati borligini isbotlamaydi, shuning uchun ikkilamchi stek xatti-harakatini va'da qilishdan oldin haqiqatda ishlatadigan versiyangiz qo'llanmasini o'qing. Qo'llanmaning SecureNAT bo'limi joriy nashr uchun virtual NAT va DHCP funksiyalarini qamrab oladi.

Har bir qarorni o'z sinovi bilan tasdiqlang

Birinchi qarorni ijara tekshiruvi bilan qabul qiling: manzil hovuzda, shlyuz virtual xost interfeysiga teng, hal qiluvchi siz sozlagan. Ikkinchisini mijozdan chiqadigan so'rov va serverdagi NAT jadvaliga bir nazar bilan qabul qiling, chunki seanslar sonining o'sishi tarjima sodir bo'layotganining, shunchaki yoqilganining emas, yagona bevosita isboti.

So'ngra bo'linishni loyiha yozuviga qayd eting: qaysi komponent manzil beradi, qaysi komponent uzatadi va trafik qaysi xost interfeysidan chiqadi. Qayta ishga tushirish xatti-harakatni o'zgartirsa, o'sha yozuv uchdan qaysi birini tekshirish kerakligini aytadi, hammasini qayta ishga tushirib simptom ko'chadi deb umid qilish o'rniga.

Yana bitta qaror yozuvga tegishli, bugun qabul qilmasangiz ham: SecureNAT va lokal ko'prik bir hub uchun turli loyihalar, va ikkalasi ham kerak bo'lgan hub boshqa reja kerak bo'lgan hubdir. Ongli ravishda tanlang, sababini yozing, keyingi odam uni ishlab turgan konfiguratsiyadan teskari muhandislik qilishi shart bo'lmaydi.