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

બન્ને ગેટ જુદી જુદી વસ્તુઓને અધિકૃત કરે છે

એપ્લિકેશન ગેટ નક્કી કરે છે કે આ વિનંતી, આ ઓળખમાંથી, આ સુરક્ષિત સંસાધન સુધી પહોંચી શકે છે કે નહીં. Google નું Identity-Aware Proxy વિહંગાવલોકન બરાબર એ જ સ્વરૂપ વર્ણવે છે: HTTPS એપ્લિકેશનો સામેનું કેન્દ્રીય અધિકૃતિ સ્તર, જે IAM ભૂમિકા દ્વારા સંચાલિત છે. સીમા સંસાધન છે, અને પ્રવેશનો એકમ વિનંતી છે. રૂટેડ VPN કંઈક વધુ જાડું અને પહોળું કરે છે: તે ક્લાયન્ટને નિર્ધારિત નેટવર્ક વિસ્તારમાં પ્રવેશ આપે છે, પછી એપ્લિકેશન હજુ પણ નક્કી કરે છે કે તે ક્લાયન્ટ શું કરી શકે.

બન્નેમાંથી કોઈ મોડેલ બીજાને ધારતું નથી. ગેટ પસાર કરવાથી ચોક્કસ રેકોર્ડ વાંચવા વિશે કંઈ કહેવાતું નથી, અને નેટવર્ક પર હોવાથી કાર્ય કરવાની પરવાનગી વિશે કંઈ કહેવાતું નથી.

પ્રોક્સી શું આવરી લેતું નથી, અને VPN શું આવરી લે છે

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

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

ક્લાયન્ટ કાર્યપ્રવાહ આર્કિટેક્ચર ડાયાગ્રામ કરતાં વધુ નક્કી કરે છે

રીડાયરેક્ટ અને ક્યારેક MFA પડકાર સાથે બ્રાઉઝર સાઇન-ઇન એ બુકમાર્ક પર ક્લિક કરતી વ્યક્તિ માટે સારો અનુભવ છે. cron કાર્ય, CLI અથવા બિલ્ડ એજન્ટ પાસે બ્રાઉઝર નથી અને તે ઇન્ટરેક્ટિવ પ્રોમ્પ્ટનો જવાબ આપી શકતું નથી, તેથી તેને દસ્તાવેજીકૃત બિન-ઇન્ટરેક્ટિવ માર્ગ અથવા ટનલની જરૂર છે. તે જરૂરિયાતની શોધ સામાન્ય રીતે ડિઝાઇન મંજૂર થયા પછી થાય છે.

એપ્લિકેશન ગણતા પહેલાં ક્લાયન્ટ ગણો. એક ડેશબોર્ડ સો લોકોને સેવા આપી શકે છે; એક ડેટાબેઝ પોર્ટ આખી ટીમને અવરોધી શકે છે.

ઉપકરણની સ્થિતિ બન્ને ગેટમાંથી કોઈની મિલકત નથી

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

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

કંઈપણ નિવૃત્ત કરતા પહેલાં વૈકલ્પિક માર્ગો શોધો

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

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

જો તમે આ અઠવાડિયે નિર્ણય લેતા હો, તો ઉત્પાદનોની યાદીને બદલે કામગીરીની યાદીથી શરૂ કરો, બ્રાઉઝર કઈ કરી શકે તે ચિહ્નિત કરો, અને બાકીને ટકી રહેતા નેટવર્ક પ્રવેશને વજાબ આપવા દો.

સંબંધિત લેખો