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

પગલું 1: વપરાશકર્તાઓ આજે શું કરે છે તે લખો

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

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

પગલું 2: ટનલને લોગિનથી અલગ કરો

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

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

અધિકૃતતા જ્યાં પહેલેથી છે ત્યાં જ રાખો. NISTનો શૂન્ય-વિશ્વાસ આર્કિટેક્ચર સારાંશ મુદ્દો સીધો કહે છે: નેટવર્ક સ્થાન સંવેદનશીલ ક્રિયા આપવાનું કારણ નથી. ટનલની અંદર હોવું ફક્ત-વાંચન ખાતાને એડમિનિસ્ટ્રેટરમાં ફેરવવું જોઈએ નહીં.

પગલું 3: જે કૉલર કર્મચારી નથી તેમને શોધો

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

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

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

પગલું 4: ફક્ત DNS રેકોર્ડ નહીં, જાહેર રૂટ નિવૃત્ત કરો

પ્રકાશન શૃંખલામાં ચાલો: DNS, લોડ બેલેન્સર લિસનર, રિવર્સ પ્રોક્સી નિયમો, હોસ્ટ ફાયરવોલ અને જૂના સરનામા તરફ હજી પણ નિર્દેશ કરતું કોઈપણ વૈકલ્પિક નામ. બંને સરનામા કુટુંબો તપાસો. મુખ્ય A રેકોર્ડ બદલવાથી લગભગ કંઈ સાબિત થતું નથી જો જૂનું CNAME અથવા IPv6 લિસનર હજી એપને સેવા આપતું હોય.

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

VPN પ્રેક્ષકોને એપ્લિકેશનના પાથ સુધી મર્યાદિત કરો. ઑફિસ નેટવર્કમાં વિશાળ ઍક્સેસ એક એક્સપોઝર નિર્ણયને મોટા નિર્ણય સાથે બદલે છે, અને વહીવટી ઇન્ટરફેસને વપરાશકર્તા નિયમ વારસામાં લેવાને બદલે પોતાના મંજૂર સ્રોતની જરૂર છે.

પગલું 5: સ્વીકૃતિ જાતે કરો

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

દરેક જાળવેલા એકીકરણ માટે પુનરાવર્તન કરો, અને તમારા પોતાના પરીક્ષણ સાધનનો 200 એ જ વસ્તુ છે એમ ધારવાને બદલે પ્રદાતાનો ડિલિવરી લોગ વાંચો. સફળ VPN લોગિન આ પરિણામોમાંથી કોઈનો પુરાવો નથી.

પગલું 6: ખરાબ દિવસની તાલીમ લો

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

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

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

સંબંધિત લેખો