સોકેટ પીઅર વિરુદ્ધ ફોરવર્ડેડ હેડર: કયા સરનામા પર ભરોસો કરવો?

તમારી એપ્લિકેશનમાં આવતી વિનંતી બે પ્રકારના સરનામા-પુરાવા ધરાવે છે: નેટવર્ક જોડાણ ખોલનાર પીઅર, અને અગાઉના ક્લાયન્ટનું સરનામું દાવો કરતું HTTP ક્ષેત્ર. તેઓ જુદા જુદા પ્રશ્નોના જવાબ આપે છે. સોકેટ પીઅર અવલોકિત થાય છે, જ્યારે હેડરનો દાવો તે લખનાર કોઈપણ કરે છે, અને કોઈપણે લોગ અથવા પ્રવેશ નિયમમાં બીજાને ચૂપચાપ બદલવું ન જોઈએ. નીચેની તુલના બંનેને અલગ રાખે છે અને પછી તે એક જ ગોઠવણ બતાવે છે જેમાં હેડર ઉપયોગી બને છે.

કંઈપણ સરખાવતા પહેલા માર્ગનું વર્ણન કરો:

Client -> approved reverse proxy -> application origin

તે ગોઠવણમાં ઉદ્ભવનું સોકેટ પીઅર સામાન્ય રીતે પ્રોક્સી હોય છે, અને ફોરવર્ડિંગ હેડર પ્રોક્સીનો ક્લાયન્ટ વિશેનો દાવો વહન કરી શકે છે. તેનું મૂલ્ય તે પ્રોક્સી સાથેના નિયંત્રિત સંબંધમાંથી આવે છે, હેડરના નામમાંથી નહીં.

સરનામાના બે પ્રકારના પુરાવા

સોકેટ પીઅર એક TCP જોડાણ વિશેની હકીકત છે: કંઈકે તે સરનામેથી હેન્ડશેક પૂરો કર્યો. તે જરૂરી નથી કે તે તે વ્યક્તિ, ઉપકરણ કે ખાતું હોય જે તમારા માટે મહત્વનું છે, કારણ કે VPN અથવા Tor એક્ઝિટ કાયદેસર રીતે તે સ્રોત હોઈ શકે જે સેવા અવલોકન કરે છે. તેમ છતાં તે એકમાત્ર સરનામું છે જે હોસ્ટે પોતે ચકાસ્યું છે, અને તેનું આખું મૂલ્ય એમાં જ છે.

ફોરવર્ડિંગ ક્ષેત્ર એ શૃંખલા વિશેનો મેટાડેટા છે. X-Forwarded-For, X-Real-IP અને માનકીકૃત ક્ષેત્ર Forwarded તેને પ્રતિધ્વનિ કરતા અંતિમ બિંદુ સુધી પહોંચતો કોઈપણ ક્લાયન્ટ લખી શકે છે, તેથી તેમની વિશ્વસનીયતા સંપૂર્ણપણે એના પર આધાર રાખે છે કે તેમને સેટ કરવાની પરવાનગી કોને હતી.

બંનેને વિનંતીના સંદર્ભમાં અલગ નામો હેઠળ રાખો. જે એપ્લિકેશન પીઅરને હેડરથી ઓવરરાઇટ કરે છે તે પછી ભરોસાની ભૂલ પુનર્નિર્માણ કરવાની ક્ષમતા ગુમાવે છે, અને તે જ સમયે તમને તેની જરૂર પડે છે.

હેડર ક્યારેય જોડાણને ફરીથી માર્ગ આપતું નથી

ફોરવર્ડિંગ ક્ષેત્રમાં સરનામું લખવાથી સર્વર પર આવતા TCP જોડાણનો સ્રોત બદલાતો નથી, અને માર્ગમાં ક્યાંય રૂટિંગ બદલાતું નથી. સામાન્ય VPN રૂટિંગ અથવા સ્રોત NAT કોઈપણ HTTP હેડર વિના ટ્રાફિક પહોંચાડે છે. તે જ રીતે, ટ્રાંઝિટ ગેટવે TLS અંતિમ બિંદુની ગોઠવણ બદલ્યા વિના યોગ્ય રીતે સુરક્ષિત HTTPS વિનિમયને ફરીથી લખતું નથી.

ઊલટી ભૂલ પણ એટલી જ સામાન્ય છે: HTTPS ક્લાયન્ટ દ્વારા આપવામાં આવેલા ફોરવર્ડિંગ હેડરને સાચું બનાવતું નથી. તે ખોટા દાવાના પરિવહનને સાચા દાવા જેટલી જ સારી રીતે સુરક્ષિત કરે છે.

જો સહકર્મી રૂટિંગ સમસ્યા ઠીક કરવા હેડર ફેરફારની દરખાસ્ત કરે, તો નિદાન પહેલેથી જ ખોટું ગયું છે. માર્ગ ઠીક કરો, અથવા હેડર લખતી પ્રોક્સી ગોઠવણી ઠીક કરો.

દાવો કરવાની પરવાનગી ધરાવતી પ્રોક્સીનું નામ આપો

બે નિયમો ફોરવર્ડિંગ ક્ષેત્રને ઉપયોગી બનાવે છે, અને બંને કોડ નહીં પણ ગોઠવણી છે. કિનારો બહારથી આવતું બધું તે ક્ષેત્રો માટેના પોતાના દસ્તાવેજીકૃત વર્તન અનુસાર સામાન્ય બનાવે છે અથવા કાઢી નાખે છે. પછી ઉદ્ભવ તમે નામ આપેલા પ્રોક્સી માર્ગમાંથી બદલીનું સરનામું લે છે, બીજે ક્યાંયથી નહીં. તે બીજો નિયમ ત્યારે જ લાગુ પડે છે જ્યારે ક્લાયન્ટ બીજી રીતે ઉદ્ભવ સુધી પહોંચી શકતા નથી, કારણ કે સીધી અને પ્રોક્સી બંને વિનંતીઓનો જવાબ આપતું ઉદ્ભવ જાણતું નથી કે તે કોને સેવા આપી રહ્યું છે.

NGINX યથાર્થ IP મોડ્યુલ વિભાજન સ્પષ્ટપણે બતાવે છે. set_real_ip_from જેના દાવાની ગણતરી થાય તેવા પ્રેષકોનાં નામ આપે છે, અને real_ip_header કહે છે કે કયું ક્ષેત્ર તેને વહન કરે છે; પહેલું ભરોસો કરે છે, બીજું ફક્ત કહે છે કે ક્યાં જોવું.

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

ફક્ત હેડર-પસંદગી સૂચના પોતે મૂલ્ય કોણે મોકલ્યું તે વિશે હજી કંઈ સ્થાપિત કરતી નથી.

પરિવહન સુરક્ષાએ તમે ભરોસો કરો છો તે ઘટકો વચ્ચે આખો માર્ગ કાપવો પડે. યોગ્ય રીતે સામાન્ય બનાવતો કિનારો તે મૂલ્ય તે ક્ષણે ગુમાવે છે જ્યારે નીચેનું અસુરક્ષિત પગલું બીજા કોઈને મુસાફરી દરમિયાન દાવો સંપાદિત કરવા દે છે.

બહુ-પગલાં શૃંખલાઓનું સભાનપણે સંચાલન કરો

અનેક પ્રોક્સીને સ્પષ્ટ શૃંખલા મોડેલની જરૂર પડે છે. કોઈ બ્લોગ પોસ્ટે એમ કર્યું છે તેથી અલ્પવિરામથી અલગ થયેલું સૌથી ડાબું કે જમણું મૂલ્ય ન લો; શોધો કે તમારી કઈ પ્રોક્સી ઉમેરે છે, કઈ બદલે છે અને કઈ આવતું ક્ષેત્ર જાળવે છે. ઉદાહરણ તરીકે, NGINX પોતાના વિશ્વસ્ત સમૂહ સામે યાદીને પાછળની તરફ ચાલી શકે છે અને તેની માલિકીના ન હોય તેવા પહેલા સરનામે અટકી શકે છે, અને તે તે ઉત્પાદનનો નિયમ છે, દરેક ફ્રેમવર્ક અનુસરે તેવો કાયદો નહીં. તમારી પોતાની પ્રોક્સીનું દસ્તાવેજીકરણ એ જ બે પ્રશ્નો સાથે વાંચો: તે કયું મૂલ્ય પસંદ કરે છે, અને કયા પ્રેષકો પર વિશ્વાસ કરે છે?

શૃંખલા લખો: પગલાંનો ક્રમ, કયું પગલું ક્ષેત્ર સેટ કરે છે અને કયું પગલું આવતી નકલો દૂર કરે છે. પછી તે નોંધ પ્રોક્સી ગોઠવણીની બાજુમાં રાખો, ફક્ત ટિકિટમાં નહીં. પછી મંજૂર થયેલી માન્યતા પ્રક્રિયા દ્વારા બનાવટી હેડર સાથે વિનંતી મોકલીને અને ઉદ્ભવ તેને અવગણે છે તેની ખાતરી કરીને તેનું પરીક્ષણ કરો.

જ્યારે તમે પગલું ઉમેરો, ત્યારે તે દસ્તાવેજ ફરી જુઓ. વિશ્વસ્ત પ્રોક્સીની સામે દાખલ કરાયેલું નવું લોડ બેલેન્સર કોઈ એપ્લિકેશન સંપાદિત કર્યા વિના કયું સરનામું જીતે છે તે બદલી શકે છે.

બંને અવલોકનો લોગમાં રાખો

જ્યાં નિદાનની અધિકૃતતા હોય ત્યાં જોડાણનું પીઅર અને સામાન્યીકૃત ક્લાયન્ટ સરનામું બે અલગ ક્ષેત્રો તરીકે લોગ કરો, અને ફક્ત હેતુને ખરેખર જરૂરી હોય તેવો ફોરવર્ડિંગ મેટાડેટા ઉમેરો. પછી બે વિનંતીઓ સાથે જમાવટ સાબિત કરો: એક પ્રોક્સી દ્વારા જે બંને મૂલ્યો વાજબી રીતે નોંધવા જોઈએ, અને એક સીધો ઉદ્ભવ તરફનો પ્રયાસ જે નકારવો જોઈએ.

યાદ રાખો કે આ જોડીનો અર્થ શું છે. હેડર તમે ભરોસો કરવાનું પસંદ કરેલા ઘટક દ્વારા પૂરો પાડેલો સંદર્ભ ઉમેરે છે; પીઅર એકમાત્ર સરનામું રહે છે જે તમારા હોસ્ટે ખરેખર જોયું છે. બંનેમાંથી કોઈપણ વ્યક્તિગત ઓળખનો પુરાવો નથી, અને કોઈપણને પુરાવો ગણતી રચના કોઈક વિશે ખોટી ઠરશે.