HAProxy 302 થી ખાનગી એપ: બીજી ઝંપ કોણ ખોલે છે?

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

કન્ફિગરેશનમાં સમાન દેખાતા બે માર્ગ

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

GET /app        client -> proxy
302 Location    proxy  -> client   (http://10.40.0.20:8080/)
GET /app        client -> 10.40.0.20:8080   client network, no route

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

GET /app        client -> proxy
GET /app        proxy  -> 10.40.0.20:8080   over the VPN
response        proxy  -> client

HAProxy નું રીડાયરેક્ટ દસ્તાવેજીકરણ બરાબર એ જ રેખા દોરે છે: ક્લાયન્ટને રીડાયરેક્ટ સાથે જવાબ આપવો એ વિનંતી બેકએન્ડને મોકલવાથી અલગ ક્રિયા છે. બે નિર્દેશ કન્ફિગરેશન ફાઇલમાં થોડી લાઇનના અંતરે છે અને સાવ જુદી રીતે વર્તે છે. એક વિનંતી સમાપ્ત કરે છે, બીજું પ્રોક્સીની માલિકીની બીજી વિનંતી શરૂ કરે છે.

બ્રાઉઝરને શું જોઈએ અને સર્વરનું VPN તેને શું આપતું નથી

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

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

જ્યારે ફક્ત પ્રોક્સી જ એપ સુધી પહોંચી શકે

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

backend private_app
    mode http
    option httpchk GET /health
    server app1 10.40.0.20:8080 check

તે બ્લોકને પ્રોક્સીના રૂટિંગ કોષ્ટક વિશેના નિવેદન તરીકે વાંચો: 10.40.0.20 પ્રોક્સી હોસ્ટમાંથી જ પહોંચી શકાય તેવું હોવું જોઈએ, જેનો અર્થ અહીં ડિફોલ્ટ રૂટને બદલે VPN ઇન્ટરફેસ દ્વારા છે. check કીવર્ડ ફક્ત જણાવે છે કે તે રૂટ શું કરે છે, અને આરોગ્ય માર્ગ એપ્લિકેશન પર હોવો જોઈએ, નહીં તો દરેક તપાસ સર્વરને ડાઉન ચિહ્નિત કરે છે. સફળ તપાસ ક્લાયન્ટ વિશે કંઈ સાબિત કરતી નથી અને કોણ બેકએન્ડ વાપરી શકે તે નક્કી કરતી નીતિનું સ્થાન લેતી નથી.

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

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

એપના પોતાના રીડાયરેક્ટ હજી અંદર તરફ ઈશારો કરે છે

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

એપ્લિકેશનનું દસ્તાવેજીકૃત બાહ્ય URL અને તેના પ્રોક્સી વિકલ્પો સેટ કરો, પછી Host હેડરને વર્ચ્યુઅલ હોસ્ટ અને પ્રમાણપત્રની અપેક્ષાઓ સાથે મેળવો. આંતરિક નામ સાથે મર્યાદિત કૂકી જાહેર નામ દ્વારા પાછી નહીં આવે, અને તે પછીનું સાઇન-ઇન લૂપ પ્રમાણીકરણ બગ તરીકે વંચાય છે. પહેલાં બાહ્ય URL બદલો, સ્વચ્છ બ્રાઉઝર પ્રોફાઇલમાંથી ફરી ચકાસો, અને અપેક્ષા રાખો કે અડધું સ્થળાંતરિત સેટિંગ્સ સફળ થતું લોગિન અને તરત મરતું સેશન બનાવશે.

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

તમારી પાસે ખરેખર કઈ રચના છે તે નક્કી કરો

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

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

રિવર્સ પ્રોક્સી પ્રકાશિત કરવું એ અલગ પ્રવેશ નિર્ણય છે, પ્રોક્સીના પોતાના VPNનું તેના જાહેર URLને લોડ કરી શકે તેવા દરેક સુધી પારદર્શક વિસ્તરણ નહીં. આકૃતિમાં બંને સરખા દેખાય છે, અને તેઓ કોને અંદર આવવા દેવાય તેમાં ભિન્ન છે. તૈનાતી પછી એ પ્રશ્નનો નિર્ણય કરવો એ જ રીતે આંતરિક એપ્લિકેશન આકસ્મિક રીતે જાહેર બની જાય છે.

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