NGINX stream kontekstida TLS passthrough ulanishiga ruxsat berish

Shifrlangan baytlarni sertifikatni hech qachon ushlamasdan uzatish TLS passthrough relayning ishi, va bu tartib qulay hamda bir oz chalg’itadi. Hech narsa deshifrlanmaganligi sababli filtrlash uchun HTTP shaklidagi hech narsa yo’q, shuning uchun odatdagi location bloki va uning kirish qoidalari bu yerda hech qanday foyda bermaydi. NGINX ega bo’lgan qaror ulanishning o’ziga tegishli: qaysi tarmoq peeri taqillatdi va uni umuman uzatish kerakmi.

Qaror HTTPda emas, streamda

stream kontekstida NGINX TCP sessiyalari bilan ishlaydi. U ulanishning peer manzilini ko’radi va har qanday bayt backendga yetib bormasdan oldin unga tartiblangan allow va deny qoidalarini qo’llashi mumkin. Bu to’liq qabul qilish qarori va u shaxsiy kalit, sertifikat yoki HTTP tahlilini talab qilmaydi.

O’sha uch qator hech qachon bir-birini almashtirmaydi. HTTP kirish direktivasini 443 portini eslatuvchi har qanday faylga ko’chirish hech narsani o’zgartirmaydi, chunki stream serveri http kontekstini hech qachon o’qimaydi.

Ulanishni uzatishdan oldin qabul qiling

stream va stream-access modullari mavjud bo’lgan amaldagi o’rnatish, VPN mijozlari manba manzillarini 10.90.0.0/24 ichida saqlaydi va 192.168.50.20:443 dagi backend allaqachon mo’ljallangan HTTPS identifikatsiyasini taqdim etadi deb faraz qiling.

stream {
    server {
        listen 443;

        allow 10.90.0.0/24;
        deny all;

        proxy_pass 192.168.50.20:443;
    }
}

Buni ishlab turgan konfiguratsiyaning bevosita o’rnini bosuvchisi emas, yangi listenerning bo’lagi sifatida o’qing. Avval mavjud listener va includelarni ko’rib chiqing, chunki allaqachon band qilingan portdagi ikkinchi listener so’rov vaqtida emas, reload vaqtida muvaffaqiyatsiz bo’ladi.

Nima yo’qligiga e’tibor bering: listen ... ssl yo’q, sertifikat direktivasi yo’q. NGINX shifrlangan oqimni uzatadi va backend TLSni tugatib, mijoz tekshiradigan sertifikatni taqdim etadi. allowlistdan o’tmagan mijozning TCP sessiyasi rad etiladi, HTTP 403 sahifasi emas, va holat kodini kutayotgan har qanday vosita foydasiz narsa xabar qiladi.

allowlist nimani qamrab oladi va nimani olmaydi

Agar relay backendlarni server nomi bo’yicha tanlasa, modul mavjud bo’lsa ssl_preread va map bu ishni davom ettirishi mumkin. Nomni hali ham mijoz beradi va nom taqdim etish mijozning VPNga qo’shilganini isbotlamaydi.

Misol qoidasi butun stream listenerni qamrab oladi. Bu uni ommaviy va faqat VPN saytlar aralashmasini taqdim etuvchi bitta kirish nuqtasi uchun yaroqsiz qiladi, u yerda har bir nom uchun istisno kerak bo’lardi; alohida listenerlar odatda hech kim o’qiy olmaydigan nomga bog’liq siyosatdan aniqroq.

Yana ikkita bo’shliqni nomlash joiz. Prefix mosligi paket qaysi interfeysdan kelganini aytmaydi va boshqa joydagi HTTP qoidasi bu listenerni cheklay olmaydi. Ikkalasi ham bitta allow qatorini butun chegara deb hisoblash o’rniga xost darajasidagi ingress siyosatini rasmda saqlash sabablari. Chegarani kelishishi kerak bo’lgan ikkita nazorat sifatida yozing, shunda har biridagi o’zgarish ko’rib chiqiladi.

NGINX aslida kimning manzilini ko’radi?

Yuk balanslagichi, boshqa proxy yoki source NAT NGINX oldiga vositachi qo’yishi mumkin, shuning uchun kuzatilgan peer VPN mijozining ichki manzili emas. Prefix tanlashdan oldin haqiqiy yo’lni tekshiring, chunki noto’g’ri manzil uchun yozilgan allowlist yo tarjimon orqasidagi barchani qabul qiladi, yo hech kimni.

PROXY protokoli va haqiqiy IP bilan ishlash qonuniy javoblar va ular faqat mos keladigan, aniq ishonchli jo’natuvchilar uchun sozlanishi kerak. Ikkala mexanizm ham jo’natuvchi aytganiga ishonadi va aynan shuning uchun jo’natuvchilar ro’yxati qisqa bo’lishi kerak. Har qanday internet mijozi identifikatsiya sarlavhasiga ishonish manba ma’lumotini yana ishonchli qilmaydi; u to’g’ri rad etishni soxta qabulga aylantiradi.

reload oldidan ikkala natijani sinab ko’ring

Konfiguratsiyani tekshiring, reload qiling, so’ngra ikki marta sinang: ishlashi kerak bo’lgan yangi ruxsat etilgan sessiya va ishlamasligi kerak bo’lgan rad etilgan sessiya. Ruxsat etilgan testda oddiy backend sertifikat tekshiruvini saqlang, chunki ulanadigan, lekin backendni tekshira olmaydigan relay bir muammoni hal qilib, boshqasini yaratdi.

nginx -t
ss -tnp | grep ':443'

Backend yo’li va javobni alohida ham tekshiring. allowlistdan o’tish faqat NGINX sessiyani qabul qilganini isbotlaydi; u yetib bo’lmaydigan backendni javob berishga majburlay olmaydi va siz boshlashdan oldin yo’q bo’lgan qaytish yo’lini tuzata olmaydi.