Soket sherigi yoki yo'naltirilgan sarlavha: qaysi manzilga ishonish kerak?

Ilovangizga keladigan so'rov manzil haqida ikki xil dalil olib keladi: tarmoq ulanishini ochgan sherik va avvalgi mijozning manzilini da'vo qiluvchi HTTP maydoni. Ular turli savollarga javob beradi. Soket sherigi kuzatiladi, sarlavhani esa uni yozgan kimsa da'vo qiladi, va hech biri jurnalda yoki kirish qoidasida ikkinchisini jimgina almashtirmasligi kerak. Quyidagi taqqoslash ikkalasini alohida tutadi, so'ng sarlavha foydali bo'ladigan yagona tartibni ko'rsatadi.

Biror narsani taqqoslashdan oldin yo'lni tavsiflang:

Client -> approved reverse proxy -> application origin

Bu tartibda manbaning soket sherigi odatda proksi bo'ladi, va yo'naltirish sarlavhasi proksining mijoz haqidagi da'vosini olib yurishi mumkin. Uning qiymati o'sha proksi bilan boshqariladigan munosabatdan keladi, sarlavha nomidan emas.

Manzil haqida ikki xil dalil

Soket sherigi bitta TCP ulanishi haqidagi fakt: nimadir o'sha manzildan qo'l berib ko'rishishni tugatdi. Bu siz uchun muhim bo'lgan inson, qurilma yoki hisob bo'lishi shart emas, chunki VPN yoki Tor chiqishi xizmat kuzatadigan manba bo'lishi qonuniy. Shunga qaramay bu hostning o'zi tasdiqlagan yagona manzil bo'lib qoladi, va uning butun qiymati shunda.

Yo'naltirish maydoni zanjir haqidagi metama'lumot. X-Forwarded-For, X-Real-IP va standartlashtirilgan maydon Forwarded ularni aks ettiruvchi yakuniy nuqtaga yetib boradigan har qanday mijoz tomonidan yozilishi mumkin, shuning uchun ularning ishonchliligi ularni sozlashga kimga ruxsat berilganiga to'liq bog'liq.

Ikkalasini ham so'rov kontekstida alohida nomlar ostida saqlang. Sherikni sarlavha bilan qayta yozadigan ilova keyinchalik ishonch xatosini qayta qurish qobiliyatini yo'qotadi, va bu sizga aynan kerak bo'lgan paytdir.

Sarlavha hech qachon ulanish yo'nalishini o'zgartirmaydi

Yo'naltirish maydoniga manzil yozish serverga yetib keladigan TCP ulanishining manbasini o'zgartirmaydi va yo'lda hech qayerda marshrutlashni o'zgartirmaydi. Oddiy VPN marshrutlash yoki manba NAT hech qanday HTTP sarlavhasiz trafikni yetkazadi. Xuddi shunday, tranzit darvoza TLS yakuniy nuqtasi tartibini o'zgartirmasdan to'g'ri himoyalangan HTTPS almashinuvini qayta yozmaydi.

Teskari xato ham shunchalik keng tarqalgan: HTTPS mijoz taqdim etgan yo'naltirish sarlavhasini haqiqiy qilmaydi. U yolg'on da'voni tashishni haqiqiydan kam himoya qilmaydi.

Agar hamkasb marshrutlash muammosini tuzatish uchun sarlavhani o'zgartirishni taklif qilsa, tashxis allaqachon noto'g'ri ketgan. Yo'lni tuzating yoki sarlavhani yozadigan proksi konfiguratsiyasini tuzating.

Da'vo qilishga ruxsat berilgan proksini nomlang

Ikki qoida yo'naltirish maydonini foydali qiladi, va ikkalasi ham kod emas, konfiguratsiya. Chet tashqaridan keladigan hamma narsani o'sha maydonlar uchun o'zining hujjatlashtirilgan xatti-harakatiga ko'ra normallashtiradi yoki tashlab yuboradi. So'ng manba almashtirish manzilini siz nomlagan proksi yo'lidan oladi, boshqa joydan emas. Ikkinchi qoida mijozlar manbaga boshqa yo'l bilan yetib bora olmaguncha amal qiladi, chunki ham to'g'ridan-to'g'ri, ham proksi orqali kelgan so'rovlarga javob beradigan manba qaysi biriga xizmat qilayotganini bilmaydi.

NGINX ning haqiqiy IP moduli bo'linishni aniq ko'rsatadi. set_real_ip_from da'vosi hisobga olinadigan jo'natuvchilarni nomlaydi, va real_ip_header qaysi maydon uni olib yurishini aytadi; birinchisi ishonchni amalga oshiradi, ikkinchisi faqat qayerga qarashni aytadi.

set_real_ip_from 10.20.0.0/24;
real_ip_header X-Forwarded-For;
# real_ip_recursive off - take the rightmost value in the field
# real_ip_recursive on  - walk the list back past every trusted address

Faqat sarlavha tanlash ko'rsatmasi o'zi hali qiymatni kim yuborgani haqida hech narsani belgilamaydi.

Transport xavfsizligi siz ishonadigan komponentlar orasida butun yo'lni bosib o'tishi kerak. To'g'ri normallashtiruvchi chet bu qiymatni pastdagi himoyalanmagan sakrash boshqa birovga da'voni yo'lda tahrirlashga ruxsat bergan paytda yo'qotadi.

Ko'p sakrashli zanjirlarni ongli ravishda boshqaring

Bir necha proksi aniq zanjir modelini talab qiladi. Qandaydir blog post shunday qilgan deb vergul bilan ajratilgan eng chap yoki o'ng qiymatni olmang; proksilaringizdan qaysi biri qo'shishini, qaysi biri almashtirishini va qaysi biri kiruvchi maydonni saqlab qolishini aniqlang. Masalan, NGINX ro'yxatni o'zining ishonchli to'plamiga qarshi orqaga qarab yurishi va o'ziga tegishli bo'lmagan birinchi manzilda to'xtashi mumkin, va bu o'sha mahsulot qoidasi, har bir freymvork amal qiladigan qonun emas. O'z proksingiz hujjatlarini xuddi shu ikki savol bilan o'qing: u qaysi qiymatni tanlaydi va qaysi jo'natuvchilarga ishonadi?

Zanjirni yozib qo'ying: sakrashlar tartibi, qaysi sakrash maydonni belgilaydi va qaysi sakrash kiruvchi nusxalarni olib tashlaydi. So'ng bu eslatmani faqat chiptada emas, proksi konfiguratsiyasi yonida saqlang. So'ng tasdiqlangan tekshirish jarayoni orqali soxta sarlavhali so'rov yuborib va manba uni e'tiborsiz qoldirishini tasdiqlab uni sinang.

Sakrash qo'shganingizda o'sha hujjatni qayta ko'rib chiqing. Ishonchli proksi oldiga qo'yilgan yangi yuk balanslagichi hech kim ilovani tahrir qilmasdan qaysi manzil g'olib bo'lishini o'zgartirishi mumkin.

Ikkala kuzatuvni jurnalda saqlang

Tashxisga ruxsat berilgan joyda ulanish sherigini va normallashtirilgan mijoz manzilini ikki alohida maydon sifatida yozib oling, va maqsadga haqiqatan kerak bo'lgan yo'naltirish metama'lumotlarini qo'shing. So'ng joylashtirishni ikki so'rov bilan isbotlang: ikkala qiymatni ham oqilona qayd etishi kerak bo'lgan proksi orqali biri, va manbaga to'g'ridan-to'g'ri qilingan, rad etilishi shart bo'lgan urinish.

Bu juftlik nimani anglatishini unutmang. Sarlavha siz ishonishni tanlagan komponent taqdim etgan kontekstni qo'shadi; sherik hostingiz haqiqatan ko'rgan yagona manzil bo'lib qoladi. Ikkalasi ham shaxsiy identifikatsiya dalili emas, va har qaysi birini dalil deb biladigan dizayn birov haqida xato qiladi.