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

મૂલ્ય સર્વરથી આવે છે, ટનલથી નહીં

PHP વિનંતીનું પર્યાવરણ જેણે સ્ક્રિપ્ટ ચલાવી તેની પાસેથી મેળવે છે. PHP સર્વર ચલોનો સંદર્ભ આ નોંધોને વેબ સર્વરે બનાવેલી કહે છે, અને તેમની ઉપલબ્ધતા એના પર આધાર રાખે છે કે વિનંતી કેવી રીતે પહોંચી.

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

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

નંબર પર ભરોસો કરતાં પહેલાં વિનંતીનો માર્ગ જુઓ

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

ચાર સામાન્ય માર્ગ ચાર જુદાં નિરીક્ષણ આપે છે.

Path to the listenerWhat can be reported
Client routed straight to the private listener, no translationThe client's tunnel address
Gateway translates the source before forwardingThe gateway's translated address
Reverse proxy terminates the client and opens its own backend connectionThe proxy's backend address
Load balancer in front of two proxiesWhichever hop the server treats as its peer

માર્ગ ગંતવ્યના નામ, સરનામાંના પરિવાર અને દરેક અનુવાદ બિંદુ સાથે લખો. તે નકશા વગર સાચું અને ખોટું મૂલ્ય લોગની એક લાઇનમાં સરખાં દેખાય છે. આકૃતિની બે લાઇન બપોરભરની ચર્ચા બચાવે છે.

બદલી ફક્ત ત્યાં જ થાય છે જ્યાં તે સેટ છે

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

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

સર્વરના માલિકને પૂછો કે આ સ્થાપનામાં કયું ક્ષેત્ર પ્રામાણિક છે અને બદલી થાય ત્યારે મૂળ સમકક્ષ કેવી રીતે જળવાય છે. જો કોઈ જવાબ ન આપી શકે તો લોગ હજી કંઈ સાબિત કરતું નથી.

ફોરવર્ડિંગ હેડર ભરોસાથી ન વાંચો

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

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

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

નિર્ણયો માટે એપની ઓળખ વાપરો

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

જો સંચાલનને કોઈ વિનંતીને VPN સત્ર સાથે જોડવી હોય, તો નિરીક્ષિત સરનામું અને સમય-છાપ તમે દસ્તાવેજ કરેલા અનુવાદ મોડેલ મુજબ પ્રામાણિક સત્ર રેકોર્ડ સાથે જોડો. એથી એવો સંબંધ બને છે જેનો તમે બચાવ કરી શકો; એકલું સરનામું એવું કરતું નથી.

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

સંબંધિત લેખો