Bitta bulut xizmati uchun mahalliy TLS, SSH yo'naltirish yoki VPN

Savol kamdan-kam hollarda ikki bulut mashinasi o'rtasida nimanidir shifrlash kerakmi degani; savol qaysi interfeysni shifrlayotganingiz va kim kimning shaxsini tekshirishi. Men bu suhbatlarni tarmoq diagrammasidan emas, xizmatdan boshlayman, chunki xizmat nima kerakligini allaqachon biladi. Uch chegara aksariyat holatlarni qamrab oladi: ilovaning o'z TLS, SSH orqali yo'naltirilgan bitta TCP port va har bir ishtirokchiga manzil beradigan marshrutlangan qatlam. Ular kuch bo'yicha emas, muammoning qancha qismini qamrab olishi bo'yicha tartiblanadi.

Tarmoqdan emas, xizmatdan boshlang

Jarayondan tashqariga chiqing. U qaysi protokolda gapiradi, mijoz qaysi nomni tekshiradi va kimga umuman ulanish ochishga ruxsat bor? Bu uch javob har qanday taqqoslash jadvalidan tezroq variantlarni yo'q qiladi, va xizmatning o'z konfiguratsiyasi odatda ularga bir necha daqiqada javob beradi.

8443 portida allaqachon HTTPS taqdim etayotgan kichik ichki API oling, api.internal.example uchun sertifikat bilan. Xostdagi ss -ltnp uning nimaga bog'langanini ko'rsatadi, openssl s_client -connect 127.0.0.1:8443 -verify_hostname api.internal.example esa sertifikat mijoz haqiqatda ishlatadigan nom uchun amal qiladimi-yo'qmi ko'rsatadi. Ikkalasi ham sog'lom bo'lsa, xizmat o'z oqimini himoya qila oladi va faqat yetib borish qoladi. Bu tarmoq qurishdan ancha kichik muammo.

1-qadam: xizmat o'zini himoya qiladimi?

Bu mos kelganda tanlanadigan variant va jamoalar taxmin qilganidan ko'proq mos keladi. Xizmatning shifrlashi mijoz va server o'rtasidagi butun yo'lni, ular orasidagi har bir sakrashni qamrab oladi, uni o'rtani aylanib o'tuvchi hech qanday tunnel yaxshilamaydi. Kutilgan nom va ishonchni aniq belgilang, mijozning standart omborida tasodifan bor narsaga tayanish o'rniga.

Shifrlash va yetib borish alohida nazorat bo'lib qoladi va ularni birlashtirish aynan shu variant xato qiladigan joy. Cheklanmagan ommaviy tinglovchidagi TLS xizmati hali ham har kimdan ulanish urinishlarini qabul qiladi, shuning uchun tinglovchi va tarmoq qoidalari foydali yuk himoyalanganligidan qat'i nazar belgilanishi kerak. Keyin bog'liqliklarni tekshiring, chunki TLS ustidagi API aniqlash oxirgi nuqtasi, administrator porti yoki yonidagi ommaviy uzatish kanali haqida hech narsa aytmaydi. Ularning har biri o'z javobiga muhtoj, va bitta himoyalanmagan aka butun chegarani xayolga aylantirish uchun yetarli.

2-qadam: bitta TCP port butun talabmi?

Talab haqiqatan bitta TCP port bo'lsa, yo'naltirish ishlaydigan eng kichik narsa. SSH mahalliy yo'naltirishi o'sha portni allaqachon mavjud autentifikatsiyalangan ulanish orqali olib o'tadi.

Shakl ssh -N -L 8443:127.0.0.1:8443 [email protected] va muhim tafsilot maqsad manzili: 127.0.0.1 uzoq tomonda hal qilinadi, shuning uchun xizmatga ulanish noutbukingizdan emas, bastiondan ochiladi. Mahalliy tinglovchini -L 127.0.0.1:8443:... sifatida tor bog'lang, xizmatni o'z mahalliy tarmog'ingizga tasodifan e'lon qilmaslik uchun. Server tomonda mijozning yaxshi xulqiga ishonish o'rniga hisob nimalarni yo'naltirishi mumkinligini cheklang. PermitOpen, AllowTcpForwarding local va standart GatewayPorts no umumiy releyi aniq kanalga aylantiradigan uch sozlamadir.

Shartnoma ikki tomonda ham tor. SSH o'z kanalini himoya qiladi, va bastiondan boshqa ilovaga keyingi sakrash o'z himoyasiga muhtoj. Faqat bastionning loopback'ida tinglaydigan xizmat boshqa tarmoq orqali yetib boriladigan xizmatdan butunlay boshqacha ta'sirga ega, va yo'naltirish buni o'zgartirmaydi. Tunnelni ularning o'rnini bosuvchi deb hisoblash o'rniga ilovaning autentifikatsiyasi va TLS tekshiruvlarini saqlang.

Bu bitta egasi bo'lgan bitta ulanish uchun yaxshi ishlaydi. Katta miqyosda bu tizimga aylanadi: mahalliy port to'qnashuvlari, nazorat, kalitlar rotatsiyasi va qayta yuklashdan keyin yo'naltirishni kim qayta boshlaydi degan savol.

3-qadam: marshrutlash haqiqiy talabmi?

Bu ro'yxat eng kichik variantning halol narxi, shuning uchun jamoalar oxir-oqibat unutilgan bir necha fon buyruqlarini boshqariladigan narsa bilan almashtiradi. Almashtirish avtomatik ravishda VPN emas. Agar talab hali ham bitta TCP port bo'lsa, hujjatlashtirilgan egasi bilan nazorat qilinadigan yo'naltirish qatlamdan arzonroq ishlaydi va ko'radigan usullaringizda muvaffaqiyatsiz bo'ladi. Nafosatni o'lchashdan oldin operatsion egalikni o'lchang.

Marshrutlash talab bo'lganda u to'g'ri javobga aylanadi. Oddiy IP ulanishiga muhtoj bir nechta ilova, TCP yo'naltirish olib o'ta olmaydigan protokollar yoki xostlar o'rtasida ko'chib yuradigan xizmatlar — barchasi bir yo'nalishga ishora qiladi.

Qatlam ishtirokchilarga manzil va marshrut beradi, so'ng haqiqiy ish boshlanadi: bir-biriga tushmaydigan diapazonlar, marshrut egaligi, DNS, ro'yxatga olish, bekor qilish va hamkor yo'qolganda nima bo'ladi. Bularning hech biri manzil bilan birga kelmaydi. Qatlamga qabul qilingan hamkor ham manzilidagi har bir operatsiyaga avtomatik vakolatli emas, shuning uchun xizmat darajasidagi autentifikatsiya qoladi.

Keyin nimaga egalik qilasiz

Qoldiradigan yozuvingizga ikki narsa tegishli. Birinchisi — mijoz tekshirishi kutilayotgan shaxs, chunki biror narsani ishga tushirish uchun nom tekshiruvi yumshatilganda bu chegaralarning har biri jimgina yomonlashadi. Ikkinchisi — olib tashlash qadami: qaysi kalit, qaysi qoida yoki qaysi marshrut kirish tugaganda yo'qoladi va buni kim bajaradi.

Bu sayohat boshlangan joyda, xizmatda tugaydi. Haqiqiy trafikni qamrab oladigan va tekshirmoqchi bo'lgan hamkorlarni tekshiradigan chegarani tanlang, so'ng kirish qanday yangilanadi, kuzatiladi va olib tashlanadi deb yozing. OpenSSH ma'lumotnomasi tor shartnoma va'da qilishdan oldin yo'naltirish parametrlarini tasdiqlaydigan joy. Olib tashlash qadamini bitta gap bilan tasvirlay olmasangiz, chegara muammodan kattaroq.