Oldida Nginx, VPN orqasida xususiy backend

Brauzer Nginx bilan gaplashadi, Nginx esa tunnelga ikkinchi ulanish ochadi. Ikkalasini ham yo'naltiring, ikkala sertifikatni ham tekshiring va ommaviy qayta yo'naltirishlarni ommaviy saqlang.

Poezdagi telefondan faqat xususiy tarmoq ichida mavjud bo'lgan backendgacha bitta so'rovni kuzatib boring. Telefon ommaviy nomni hal qiladi, 443 portidagi ommaviy manzilga ulanadi va oddiy TLS qo'l berishni yakunlaydi. Nginx bu ulanishni qabul qiladi va keyin faqat VPN interfeysi orqali yetib boriladigan manzilga ikkinchi, butunlay alohida ulanish ochadi. Telefonda hech narsa o'zgarmaydi va telefon tunnel ishtirok etganini hech qachon bilmaydi.

Bitta so'rovni ikkita ulanish orqali kuzatish

Kiruvchi qism ommaviy HTTP tranzaksiyasidir. Uning ommaviy nomi, ommaviy sertifikati va tashrif buyuruvchining o'sha paytdagi har qanday manzili uchun ishlashi kerak bo'lgan javob yo'li bor. Bu yo'lni buzadigan har qanday o'zgarish barcha tashrif buyuruvchilarni bir vaqtning o'zida buzadi. Shuning uchun ommaviy qism — tajriba qilishni eng kam xohlaydigan qism.

Chiquvchi qism xususiy. Nginx mijozga aylanadi, ichki nomni hal qiladi yoki qat'iy manzildan foydalanadi va internetdan keladigan ulanishni rad etadigan xizmatga yetib boradi.

Public client  -> frontend public address:443   (TLS, public name)
Frontend       -> VPN private backend 10.40.0.20:8443  (TLS, private name)

Ularni xayolingizda alohida saqlang, konfiguratsiya o'z-o'zidan ayon bo'ladi. Agar ularni birlashtirsangiz, oxir-oqibat ommaviy mijozi tunnelda ishtirok ettirishga urinasiz va bu dizayndagi chalkashlikning katta qismi shundan kelib chiqadi. Xususiy qism mo'rt bo'lishi mumkin. Ommaviy qism unday emas.

Bularning birortasini qurishdan oldin ilovani nashr etish qasddan ekanini tasdiqlang. Ishlaydigan proksi ham ishlaydigan fosh etishdir, va autentifikatsiya modeli qaror bo'lishi kerak, yon ta'sir emas.

Shlyuz nomi tunneldan omon o'tishi kerak

Nomlarni hal qilishda nozik tuzoq bor. Agar xususiy DNS VPN profili o'z shlyuzi uchun ishlatadigan aynan o'sha nomni qayta yozsa, qayta ulanish oxir-oqibat o'zi qurishi kerak bo'lgan tunnel orqali o'sha shlyuzga yetishga urinishi mumkin. Mijozga bu nom tunnel paydo bo'lishidan oldin hal qilingan bo'lishi kerak. U tunnel ichida hal qilinsa, ulanishni umuman qurib bo'lmaydi.

Shlyuz va backend uchun alohida tasdiqlangan nomlardan foydalaning va hal qiluvchi siyosatini har bir nom o'z iste'molchisiga kerak bo'lgan manzilga hal qilinadigan qilib cheklang. Ilovaning Host sarlavhasini o'zgartirish bu yerda hech narsa bermaydi, chunki qidiruvni VPN mijozi amalga oshiradi.

Keyin qamrov haqida o'ylang. Frontend backend manziliga marshrut kerak, shuningdek u ommaviy mijozlarga javob berishni davom ettirishi kerak. O'sha xostdagi to'liq tunnel birinchi talabni qondirib, ikkinchisini buzishi mumkin.

Siyosat ruxsat bergan joyda aniq manzilga tunnel tozaroq dizayn. Siyosat to'liq tunnelni talab qilgan joyda frontend alohida tarmoq kontekstiga tegishli, ma'lum tashrif buyuruvchilar uchun vaqtinchalik marshrutlar bilan yamalmaydi.

Server blokini ikkala qism ham tekshiradigan qilib yozing

Backend bu nom uchun sertifikat taqdim etadi deb faraz qilaylik: backend.corp.example va xususiy manzilda javob beradi. Nomni tekshirib turib manzilga ulanish — proksi modulining SNI va nom opsiyalarining aynan maqsadi.

upstream private_app {
    server 10.40.0.20:8443;
}

server {
    listen 443 ssl;
    server_name app.example.com;

    ssl_certificate     /etc/nginx/tls/app-fullchain.pem;
    ssl_certificate_key /etc/nginx/tls/app-key.pem;

    location / {
        proxy_pass https://private_app;
        proxy_ssl_server_name on;
        proxy_ssl_name backend.corp.example;
        proxy_ssl_trusted_certificate /etc/nginx/trust/backend-ca.pem;
        proxy_ssl_verify on;
        proxy_ssl_verify_depth 3;

        proxy_set_header Host app.example.com;
        proxy_set_header X-Forwarded-Proto https;
        proxy_set_header X-Forwarded-For $remote_addr;
    }
}

Yuqoridagi har bir yo'l va manzil o'rin egallovchi. Muhimi — tekshirishni yoqilgan holda ushlab turadigan qismlar: tekshiriladigan nom, unga qarshi tekshirish uchun ishonch to'plami va tasdiqlangan zanjirga mos chuqurlik.

proxy_set_header Host app.example.com qasddan. Backend bu ommaviy kelib chiqishni qabul qiladigan qilib sozlanishi kerak va uzatilgan sarlavhalarga faqat shu frontenddan ishonishi kerak. Quyidagini qayta yozish X-Forwarded-For mijoz manzili bilan bitta proksi uchun to'g'ri, zanjir uchun noto'g'ri, shuning uchun ko'p proksili joylashtirish o'zining ishonchli manzillar tartibiga muhtoj.

Ommaviy kelib chiqishni o'zini ommaviy kabi tutishga majbur qilish

Ilova ommaviy kelib chiqish uchun mutlaq URL, qayta yo'naltirish va cookie chiqarishi kerak. Agar u tashrif buyuruvchini quyidagiga yo'naltirsa: backend.corp.example, bu tashrif buyuruvchi o'zi hal qila olmaydigan nomga yuboriladi.

Buni ilovaning qo'llab-quvvatlaydigan tashqi URL sozlamasi va ko'rib chiqilgan qayta yo'naltirish siyosati orqali tuzating, javob tanasida xost nomlarini qayta yozish orqali emas. Ixtiyoriy tarkibdagi satrlarni almashtirish imzolangan yuklamalarni buzadi va kuzatish qiyin bo'lgan xatolarni keltirib chiqaradi.

Cookie ham xuddi shunday ehtiyotga loyiq. Xususiy nomga cheklangan cookieni faqat ommaviy nomni biladigan brauzer hech qachon yubormaydi.

Nginx haqiqatan ham ommaviy soketga ega bo'lishi mumkinligini ham tasdiqlang. 443 dagi mavjud veb-xizmat ko'chishi kerak yoki frontend boshqa joyda yashashi kerak, chunki ikki jarayon bir xil manzil va portni bog'lay olmaydi.

Har bir qismni u haqiqatan ishlaydigan joyda tekshiring

Konfiguratsiyani o'rnatilgan tahlilchi bilan har qayta yuklashdan oldin tekshiring, yozuv xatosi hozir xizmat ko'rsatayotgan tinglovchini yiqitmasin.

Keyin backend qismini frontend xostining o'zidan, Nginx ishlatadigan o'sha tarmoq kontekstida sinab ko'ring. Tunnel orqali ping yetib borishni isbotlaydi va TLS, avtorizatsiya yoki ilova haqida hech narsa aytmaydi.

Oxirida haqiqiy xost nomiga oddiy sertifikat tekshiruvi bilan yangi ommaviy so'rov yuboring va faqat javob tanasini emas, javob yo'lini kuzating.

Ikkala kuzatuvni ham joylashtirilgan konfiguratsiya bilan birga saqlang va tunnel mavjud bo'lmaganda nima bo'lishini yozib qo'ying. Frontend nazorat qilinadigan upstream xatosini qaytarishi kerak, hech kim hujjatlashtirmagan boshqa backendga jimgina o'tmasligi kerak. Aniq jurnal satri bilan 502 yaxshi natija. Kutilmagan manbadan keshlangan sahifa unday emas.

O'xshash maqolalar