PPP-આધારિત VPN પરથી તેની ધારણાઓની નકલ કર્યા વિના સ્થળાંતર

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

પગલું 1: જૂનું જોડાણ શું આપે છે તેની યાદી બનાવો

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

L2TP/IPsec માટે, બે સ્તરોને સ્પષ્ટપણે અલગ કરો. IPsec પીઅરની ઓળખ મશીનોને પ્રમાણિત કરે છે; PPP વપરાશકર્તાને પ્રમાણિત કરે છે, સામાન્ય રીતે CHAP અથવા MSCHAPv2 સાથે.

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

પગલું 2: બદલીને ઇરાદાપૂર્વક ડિઝાઇન કરો

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

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

પગલું 3: તબક્કાવાર લાગુ કરો અને મંજૂરી તેમજ નકાર બંને ચકાસો

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

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

વ્યવસ્થાપકની ઍક્સેસ ખસેડતા પહેલાં ખાતરી કરો કે તમારી પાસે અધિકૃત પુનઃપ્રાપ્તિ માર્ગ છે જે તમે બદલી રહ્યા છો તે ટનલ પર આધારિત નથી.

પગલું 4: જૂની ઓળખ નિવૃત્ત કરો

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

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

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

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