Ikki OpenVPN serveridagi mijozlar bir-biriga yetib bora oladimi?

Ikkinchi OpenVPN serverni ishga tushirish mijozlar ulanadigan ikkinchi joyni beradi, undan boshqa hech narsa emas. U bu mijozlarni birinchi serverning tarmog‘iga qo‘ymaydi va client-to-client deb nomlangan parametr faqat bitta server jarayoni ichidagi uzatishni o‘zgartiradi. Ikki hovuz siz ular orasida ataylab marshrutlash qilganingizda bitta tarmoqqa aylanadi, har bir yo‘nalish uchun egasi bilan. Quyidagilarning barchasi foydalanuvchi fazosidagi TUN rejimini, o‘sha ichki uzatish o‘chirilgan holda nazarda tutadi, shuning uchun qarorni yadro qabul qiladi.

Afsona: bitta hisob ro‘yxati, bitta tarmoq

Autentifikatsiya va yetib borish imkoniyati bir-biriga aralashib ketadi, chunki ikkisi ham server konfiguratsiyasida yashaydi. Ikki shlyuzdan istalgan biriga kira oladigan foydalanuvchi tashqaridan ikkita eshigi bor bitta tizimning foydalanuvchisidek ko‘rinadi. Ichkarida har bir server o‘z hovuzidan manzillar beradi va faqat o‘zi tugatadigan mijozlar uchun marshrutlar o‘rnatadi. Shuning uchun A shlyuzidagi mijoz B shlyuzidagi mijozga paket yuborsa, o‘z serveri hech qachon eshitmagan manzilni so‘raydi. Paket A ning standart marshrutiga ketadi, tunneldan chiqadi va unga ruxsat berish hech qachon so‘ralmagan xavfsizlik devoriga yetib boradi.

Shuning uchun ikkinchi server qo‘shish ortiqchalik, aniqlash yoki umumiy broadcast domenini qo‘shmaydi. U reja talab qiladigan marshrutlangan tarmoqni qo‘shadi va reja manzillashdan boshlanadi.

Har bir shlyuzga o‘z hovuzi va tranzit manzilini bering

Boshqa hech narsa bilan kesishmaydigan ikki diapazon va xostlar orasidagi kichik tranzit aloqa — bu butun manzil rejasi. Tranzitni o‘zingiz nazorat qiladigan xususiy segmentda saqlang va raqamlarni biron server ijara bermasdan oldin yozib qo‘ying.

Profillar bir xil qolishi uchun ikki serverga bir xil hovuz berish vasvasasiga qarshi turing. Yadro marshruti umumiy diapazon ichidagi ixtiyoriy manzil hozir ikki xostdan qaysi biriga tegishli ekanini ayta olmaydi, shuning uchun marshrutlash jadvali bitta shlyuzga ishora qiladi, mijoz esa boshqasiga ulangan bo‘lishi mumkin. Interfeys nomlari mahalliy an’analar, umumiy holat emas. Bu yerda ikkala xost tunnel qurilmasini tun0, tranzit aloqani esa transit0 deb ataydi, bu joyida, chunki hech qanday paket bu nomlarni olib yurmaydi.

Marshrutni ikki tomonga ham o‘rnating

Har bir shlyuzga tranzit manzil orqali ikkinchisining hovuziga marshrut kerak va istalgan biri hop bo‘lib ishlashi uchun uzatish yoqilgan bo‘lishi shart. Avval joriy jadvalni tasdiqlang, so‘ng yozuvni qo‘shing va uni qayta ulanish ilgagi o‘rniga xostning tarmoq menejeri orqali doimiy qiling.

sysctl net.ipv4.ip_forward
ip route add 10.64.20.0/24 via 172.28.44.2 dev transit0
ip route get 10.64.20.37

Hovuzlarni almashtirib, buni ikkinchi xostda aks ettiring. Aynan o‘sha marshrutni aloqasiz skriptdan qayta-qayta qo‘shish — xostda bir nechta nusxa va keyingi safar kimdir jadvalni o‘qiganda sirli o‘zgarish paydo bo‘lishining yo‘li. Agar tranzit aloqaning o‘zi tunnel bo‘lsa, marshrut o‘sha tunnel topologiyasiga ishora qiladi va hop uning qayta ulanishidan omon qolishi kerak. O‘ttiz soniya yo‘qoladigan tranzit manzil hovuzlar orasidagi yo‘lni ham birga olib ketadi, bu esa aniqlashdan ko‘ra aytib qo‘yishga arziydigan dizayn xossasidir.

Egalikni soxtalashtirmasdan mijoz marshrutini suring

Mijozlarga uzoq hovuzga marshrut kerak, aks holda ularning operatsion tizimi paketni standart shlyuzga yuboradi va tunnel uni hech qachon ko‘rmaydi. Uni yetkazishning tabiiy joyi server konfiguratsiyasi.

push "route 10.64.20.0 255.255.255.0"

Ko‘zgu satrini ikkinchi server konfiguratsiyasiga qo‘ying, so‘ng sinov mijozini qayta ulang va uning jadvalini o‘qing. Surilgan marshrutlarni e’tiborsiz qoldiradigan mijozga o‘zining tasdiqlangan konfiguratsiyasi kerak, hech qachon kelmaydigan marshrut esa kirish nazorati emas. Mijozga boshqa shlyuzning butun hovuzi uchun iroute bermang. Bu direktiva bitta ulangan mijoz orqasidagi subnet uchun mavjud va undan shlyuzlar orasidagi yetishmayotgan marshrutni yashirish uchun foydalanish o‘zi yetib bora olmaydigan manzillarga egalik qiladi deb hisoblaydigan serverni keltirib chiqaradi.

Bitta so‘rovni isbotlang va boshqasini rad eting

Haqiqiy amalni tanlang, masalan, 10.64.10.21 dagi mijozdan 10.64.20.37 dagi xizmatga HTTPS va ikkala xostda ham aynan shunga ruxsat bering. Har bir xavfsizlik devori so‘rovni kirish tomonida va kuzatilgan javobni qaytish tomonida qabul qiladi; manzilning o‘z xizmat siyosati baribir uni qabul qilishi kerak.

iptables -A FORWARD -i tun0 -o transit0 -s 10.64.10.21 -d 10.64.20.37 -p tcp --dport 443 -j ACCEPT
iptables -A FORWARD -i transit0 -o tun0 -d 10.64.10.21 -s 10.64.20.37 -p tcp --sport 443 -m conntrack --ctstate ESTABLISHED -j ACCEPT

O‘zaro marshrutlar mavjud bo‘lsa, manba NAT keraksiz va bu yerda faol zararli: manbani tarjima qilish so‘rovni qaysi mijoz yuborganini yashiradi va manzil tomonidagi manbaga asoslangan siyosatni buzadi. Internetga chiqish uchun mavjud masquerade qoidasi bu yo‘lni ham ushlamasligini tekshiring. So‘ng rad etishni sinab ko‘ring. B hovuzida mahalliy qolishi kerak bo‘lgan xizmat A hovuzidan yetib bo‘lmaydigan bo‘lib qolishi kerak, bir xil shlyuzdagi mijoz juftliklari ham sinovdan o‘tkazilishi lozim, chunki siz hozir o‘zgartirgan uzatish siyosati ularga ham tegishli.

Aqliy modelga yana bir tuzatish: tranzit aloqa shifri ochilgan ichki paketlarni tashiydi, shuning uchun u ishonch chegarasi, xususiy kafolat emas. Agar u siz nazorat qilmaydigan tarmoqdan o‘tsa, o‘sha hopni tasdiqlangan shifrlangan tunnel bilan himoyalang va uning haqiqiy topologiyasi orqali marshrutlang. Uchdan-uchga TLS baribir ilovani o‘zi autentifikatsiya qiladi, shuning uchun ichki xizmat undan foydalanishda davom etishi kerak.