Mos keladigan VPN mijoz manzillari hovuzini qanday rejalashtirish kerak
Server maydonidagi hovuzni tanlang, so'ngra mijoz haqiqatda oladigan manzilni o'qing, javobni orqaga kuzatib boring va diapazon, rejim, marshrut hamda DNS qamrovini yozib oling.
VPN serveridagi hovuz maydonidan boshlang, elektron jadvaldan emas. U yerga yozganingiz keyinchalik ulanadigan har bir mijoz uchun ichki manzil maydoniga aylanadi va u o'sha mijozlar yetib boradigan LAN, uning orqasidagi marshrutlangan saytlar va mijozning uyda allaqachon mavjud manzili bilan birga yashashi kerak. Hovuz saqlangandan so'ng darhol bitta mijozni ulang, chunki o'sha birinchi ulanish qiymat amalda ishlayotganini aytadi. U yerdan yo'riqnoma tashqariga qarab boradi: mijoz olgan manzil, javob yuradigan yo'l va siz qoldiradigan yozuv.
Hovuz maydonidan boshlang, hech bir mijoz ulanmasidan oldin
Har bir mahsulot buni boshqacha ko'rsatadi, shuning uchun manzillarni haqiqatda tayinlaydigan obyektni toping. OpenVPN'da keyingi bo'sh manzilni beradigan server tomonidagi hovuz ko'rsatmasi bor, IKEv2 shlyuzida hamkor konfiguratsiyasiga bog'langan hovuz bo'limi bor, WireGuard'da esa ikkisi ham yo'q, chunki har bir hamkor o'z manzilini o'z konfiguratsiya faylida olib yuradi. Hovuz ko'rsatmasi va har bir hamkor manzili o'zaro almashtirilmaydi va noto'g'risini tahrirlash yo'riqnomaning qolgan qismini behuda sarflaydi.
Maydonni olgach, allaqachon mavjud diapazonlarni sanab chiqing: ofis LAN, har bir marshrutlangan sayt, bulut VPC va xizmatda qolgan har qanday boshqa hovuz. Qoplanish prefiks arifmetikasi bilan hal qilinadi, xost raqamlari tanish ko'rinishi bilan emas, shuning uchun jamlamani o'sha diapazonlarning har biri bilan solishtiring. Ikkisi ham 10.x ga o'xshab ko'rinadigan ikkita diapazon jamlamalari kesishmasa zararsiz, kesishsa qo'llab-quvvatlash hodisasi bo'ladi.
Keyin manzil kim ulanishiga yoki qachon ulanishiga bog'liq funksiya ekanini hal qiling. Dinamik tayinlash bo'sh bo'lganini beradi, shaxsga ko'ra tayinlash esa qat'iy manzilni hisob ma'lumotlariga bog'laydi. Tanlovni yozib qo'ying, chunki u keyinchalik qayta ulanish qanday bo'lishi kerakligini o'zgartiradi.
Mijoz haqiqatda olgan manzilni o'qing
Bitta mijozni ulang va hovuz va'da qilganini emas, tunnel xabar qilganini o'qing. Mijoz ichki manzilini ulanish holatida ko'rsatadi, Linuxda esa interfeys uni bevosita olib yuradi.
O'sha manzilni saqlagan diapazoningiz bilan solishtiring. Agar u diapazondan tashqarida bo'lsa, siz tahrirlaganidan boshqa tayinlash yo'lini ko'ryapsiz. Prefiks uzunligini ham tekshiring, chunki /32 ga ega mijozda bog'lanishda hamkor yo'q va u har bir manzilni o'z standart marshruti orqali yuboradi.
ip -4 addr show tun0
ip route get 192.168.50.20
Xuddi shu diapazondan foydalanadigan uy routeridan ulanadigan mijoz ulanadi va keyin deyarli hech narsaga yetib bormaydi. Mijoz bu prefiks uchun o'z mahalliy marshrutini saqlaydi, shuning uchun tunnel manzili uning orqasidagi tarmoq bilan to'qnashadi va trafik noto'g'ri interfeysdan chiqadi. Bu holatni serverda tuzatib bo'lmaydi; hujjatlashtirilgan chora uy tarmog'ini qayta raqamlash yoki to'qnashuvlar kam qolishi uchun yetarlicha uzoq hovuz diapazonini tanlashdir. Muvaffaqiyatsizlikni ham, chorani ham yozib qo'ying, chunki yordam stoli yana unga duch keladi.
Xuddi shu mijozni qayta ulang va manzilni kuzating. Dinamik hovuz bir xil yoki boshqa qiymat qaytarishi mumkin va ikkisi ham to'g'ri, shaxsga ko'ra hovuz esa manzilni o'zgartirsa, bog'lanishga rioya qilmayapti. Bu tekshiruv bir necha soniya oladi va birinchi bo'limda yozgan rejim amaldagi rejim ekanini hal qiladi.
Xizmatdan javobni orqaga kuzatib boring
Hovuz faqat javoblar unga qaytib keta olganda ishlaydi. LANdagi xizmat ichki manzilga javob beradi, shuning uchun uning shlyuziga hovuz uchun marshrut yoki xizmat oldida tarjima kerak. So'rov tunneldan kelib, javob boshqa yo'ldan chiqqanda, holat saqlovchi xavfsizlik devori yoki teskari yo'l tekshiruvi uni tashlab yuboradi va mijoz ulanib, keyin osilib qoladigan xizmatni ko'radi. Har bir xostga marshrut qo'shish o'rniga hovuzni marshrutlash loyihasiga bitta umumlashtiriladigan blok sifatida joylashtiring.
Tarjima tizimning qolgan qismi ko'radigan narsani o'zgartiradi. Manba qayta yozilganda, xost xavfsizlik devoridagi va ilova jurnalidagi manzil tarjima qilingani bo'ladi, shuning uchun hovuz manziliga qarshi yozilgan qoida hech narsaga mos kelmaydi va jurnal satrini mijozgacha kuzatib bo'lmaydi. strongSwanning uzatish bo'yicha hujjati IKEv2 shlyuzi uchun o'sha yo'lning server tomonidagi yarmini qamrab oladi. DNS ham xuddi shu cheklovni olib yuradi, chunki mijoz yetib bora olmaydigan manzilga hal bo'ladigan nom keyinroq va boshqa joyda muvaffaqiyatsiz bo'ladi.
Ikki mijoz, so'ngra bitta bekor qilish
Bir vaqtda ikkita mijozni ulang va ikkala manzilni o'qing. Ular ajralib turishi, foydalanishga yaroqli bo'lishi va hovuz ichida bo'lishi kerak, har biri o'zi uchun mo'ljallangan xizmatga yetishi lozim. Takroriy manzillar beradigan hovuz odatda birinchi bitta-mijoz sinovida emas, aynan shu yerda ko'rinadi.
Boshqa mijoz ulangan holatda bitta hisob ma'lumotini bekor qiling, so'ngra omon qolgan mijozdan xizmatni sinab ko'ring. Boshqa sessiyani buzadigan bekor qilish umumiy holatga ishora qiladi, ko'pincha bitta hisob ma'lumoti yoki qurilmalar orasida qayta ishlatiladigan bitta manzil. Bekor qilingan mijozni qayta ulang va bo'shatilgan manzil berilishi o'rniga rad etilishini tasdiqlang.
Rad etilishi kerak bo'lgan manzil bilan yakunlang. Hamma joyga yetadigan mijoz ulangan, sinovdan o'tkazilmagan.
To'rt qiymatni keyingi o'zgarish ularni topadigan joyga yozing
Yozuv qisqa: hovuz diapazoni va prefiksi, tayinlash rejimi, qaytish yo'li yoki ishlatilayotgan tarjima va o'sha manzillar uchun javob beradigan DNS qamrovi. Uni chiptaga emas, server konfiguratsiyasi yoniga qo'ying va sana qo'ying. Keyinchalik to'rttadan birini o'zgartiradigan kishi qolgan uchtasini ko'z oldida ko'rishi kerak, chunki hovuz o'lchamining o'zgarishi marshrutni buzadi, marshrut o'zgarishi esa DNS javobini buzadi.
U bilan birga egalik eslatmasini saqlang: tunnel diapazoni VPN serveriga tegishli, va LANning DHCP qamrovida qilingan rezervlash tunnel ichidagi mijoz uchun hech narsa rezervlamaydi. O'sha bitta satr eng keng tarqalgan qayta ishlashni oldini oladi, unda kimdir rezerv qo'shadi va tunnel manzili unga ergashishini kutadi.