VPN mijoz IP manzillarini bulut chegarasida saqlang yoki SNAT qiling

VPN mijozining manzilini ilovagacha saqlash har bir jurnal satri va ruxsat etilganlar ro'yxatidagi har bir yozuv bir xil ma'noni berishini ta'minlaydi. Uni bulut chetida qayta yozish marshrutlash jadvalini soddalashtiradi va jurnallarni foydasizroq qiladi. Ikkala tanlov ham o'z-o'zidan noto'g'ri emas va uni hal qiladigan dalil kamdan-kam hollarda unumdorlik haqida bo'ladi. Uch shart hal qiladi: ilova qaysi inson ulanganini bilishi kerakmi, bulut to'qimasi yubormoqchi bo'lgan manbani qabul qiladimi va keyin qaytish marshruti mas'uliyatini kim o'z zimmasiga oladi.

Uch shart hal qiladi

Tarmoq diagrammasidan emas, ilova talabidan boshlang. Agar avtorizatsiya yoki audit alohida mijoz manziliga bog'liq bo'lsa, uni saqlash funksional talab, tarjima qilish esa orqaga qadamdir. Agar ilova faqat trafik masofaviy kirish yo'li bilan kelganini bilishi kerak bo'lsa, tarjima qilingan manzil yetarli va uni ishlatish ancha arzon.

Ikkinchi shart mexanik. Virtual tarmoq yuboruvchi interfeysga berilmagan manzilni da'vo qilgan paketga avtomatik ishonmaydi. Ko'pchilik bulut to'qimalari buni turli usullar va nomlar bilan talab qiladi, va buni e'tiborsiz qoldirgan dizayn diagrammada to'g'ri ko'rinadi, ishlab chiqarishda esa jimgina yo'qoladi.

Uchinchisi tashkiliy. Manbalarni saqlash ilova quyi tarmog'ining marshrutlash jadvali mijoz prefiksi uchun shlyuzga orqaga ishora qilishi kerakligini va keyinroq quyi tarmoq qo'shgan har bir jamoa bu marshrutni izchil saqlashi kerakligini bildiradi. Bu bir marta kichik xarajat va o'nlab hisoblar bo'ylab takrorlanadigan xarajat. Bu xatti-harakatni va'da qilishdan oldin uni kim to'lashini hal qiling.

Marshrut soxtalashtirishga ruxsat emas

Qaytish marshrutini qo'shish quyi tarmog'ingizga javoblar qayerga ketishini aytadi. Bu to'qimaga o'sha paketlarni uzatuvchi instans ularni begona manba bilan chiqarishga haqli ekanini aytmaydi. AWSda tegishli nazorat manba va manzil tekshiruvi bo'lib, u har bir instans uchun ko'rinadi:

aws ec2 describe-instances --instance-ids i-0a1b2c3d4e5f60718 \
  --query "Reservations[].Instances[].SourceDestCheck"
aws ec2 modify-instance-attribute --instance-id i-0a1b2c3d4e5f60718 \
  --no-source-dest-check

Uni faqat hujjatlashtirilgan ishi uzatish bo'lgan instans uchun o'chiring, boshqa hech narsa uchun emas. Tekshiruvni yoqilgan holda qoldirgan har bir ilova VMi qarzga olingan manba bilan trafik chiqarish uchun ishlatilishi mumkin bo'lgan bitta mashina kam degani. Agar platformangiz AWS bo'lmasa, xatti-harakat ko'chadi deb taxmin qilish o'rniga ekvivalent soxtalashtirishga qarshi yoki ruxsat etilgan manzil sozlamasini qidiring.

Tez paket tutish konsolni o'qishdan tezroq savolni hal qiladi. Agar javoblar chiqib ketsa va mijoz ularni hech qachon ko'rmasa, ilova emas, to'qima soxta manbani tashlab yuboryapti.

Tarjima nima sotib oladi va qanchaga tushadi

Manbani shlyuzda qayta yozish qaytish yo'li muammosini yo'q qiladi. Ilova unga qanday yetishni allaqachon biladigan bitta manzilni ko'radi va mijoz prefiksi hech qachon bulut marshrutlash jadvalida ko'rinishi shart emas. Linuxda qoida bitta satr, va qo'lingizdan kelgan eng tor variantni yozishga arziydi:

sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -s 172.20.8.0/24 -o ens5 -j SNAT --to-source 10.40.3.10

Ilova endi nimani yozishiga e'tibor bering: har bir foydalanuvchi uchun 10.40.3.10, har bir ulanishda, abadiy. O'sha qiymat asosida qurilgan har qanday manzil ruxsat ro'yxati endi butun masofaviy kirish aholisiga ruxsat beradi va har qanday hodisani ko'rib chiqish bu kim edi degan savolga javob berish uchun shlyuzga qaytishi kerak.

Yechim tarjimadan voz kechish emas, manzil shaxs degan da'voni to'xtatishdir. Mijoz shaxsini autentifikatsiya qilingan maydonda olib yuring, uni shlyuzda tarjima qilingan kortej bilan birga yozib qo'ying va ilova unga qo'shilishiga ruxsat bering. Qo'shilish kaliti bo'lmasa, tarjima tarmoq muammosini doimiy sud-tibbiy muammoga aylantiradi.

Relay boshqa interfeys

Ilova oldidagi teskari proksi marshrutlangan yo'l savolini butunlay chetlab o'tadi. Proksi o'zining backend ulanishini ochadi, shuning uchun mijoz prefiksi virtual tarmoq ichida hech qachon marshrutlanadigan bo'lishi shart emas, va ilova proksi o'rnatgan sarlavhada shaxsni olishi mumkin.

Bu sarlavha faqat backend uni proksidan qabul qilib, boshqa hech narsadan qabul qilmasa ishonchli bo'ladi. nginx atamalarida bu kelgan hamma narsaga ishonish o'rniga ishonchli hamkorni aniq nomlashni bildiradi:

set_real_ip_from 10.40.3.10;
real_ip_header X-Forwarded-For;
real_ip_recursive on;

Backendga to'g'ridan-to'g'ri yeta oladigan har qanday mijoz o'sha sarlavhani soxtalashtirishi mumkin, shuning uchun backend proksidan boshqa yo'l bilan yetib bo'lmaydigan bo'lishi kerak. Bu firewall haqiqati, konfiguratsiya fikri emas, va parchadan nusxa ko'chirishda odamlar aynan shu taxminni tashlab ketishadi.

Relay shuningdek nima sotib olayotganingizni ham o'zgartiradi. Siz ilova darajasidagi shaxs va uni yozib qo'yish uchun tabiiy joy olasiz; umumiylikdan voz kechasiz, chunki har bir yangi protokol o'zining proksi yordamiga muhtoj. HTTP xizmatlari uchun bu almashinuv odatda yaxshi, va HTTP bo'lmagan har qanday narsa uchun odatda umuman mavjud emas.

Har bir chegara nima ko'rishini yozib qo'ying

Nimani tanlamang, dizayn ko'rigi har bir sakrashda manba manzili va isbotlanishi mumkin bo'lgan shaxsni nomlaydigan bitta jadval bilan tugashi kerak. Usiz birinchi hodisa har biri boshqa mijozni tasvirlaydigan uchta jamoa keltirib chiqaradi.

Keyin tanlang. Ilova avtorizatsiyasi haqiqatan mijoz manziliga bog'liq bo'lsa va marshrutni o'z zimmangizga olsangiz, manbani saqlang. Aks holda va shaxsni tarmoqqa bog'lanmagan holda olib yura olsangiz, tarjima qiling, va platformaga xos uzatish sozlamalari uchun AWSning uzatuvchi instanslar bo'yicha qo'llanmasidan foydalaning. Xizmat HTTPda gaplashsa va shaxs umuman manzil bo'lmasligini istasangiz, relayga murojaat qiling.