ISP બદલો, સાઇટ VPN સરનામાં ફરી નંબર કર્યા વિના

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

સ્વતંત્ર રીતે ચાલતી બે સરનામા યોજનાઓ

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

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

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

બાહ્ય ટનલ આંતરિક વાતચીત વહન કરે છે

ગેટવે-થી-ગેટવે ટનલમાં બાહ્ય IP હેડર બે ગેટવેને સરનામું આપે છે. આંતરિક હેડર હજી પણ એપ્લિકેશનના વાસ્તવિક અંતિમ બિંદુઓનું નામ આપે છે. RFC 7296નું ગેટવે-થી-ગેટવે વર્ણન આને સામાન્ય રાઉટિંગ તરીકે ગણે છે જે ટનલના અંતિમ બિંદુઓ દ્વારા ટ્રાફિક પહોંચાડે છે.

તેથી ગેટવેનું જાહેર સરનામું બદલાય ત્યારે શાખા સર્વર 10.55.8.20 જાળવી શકે છે. આંતરિક પેકેટમાં પ્રદાતાનું સરનામું બિલકુલ હોતું નથી.

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

પ્રદાતા ખસેડવાની હજી પણ ચેકલિસ્ટ છે

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

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

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

શું ટકતું નથી: જાહેર સ્રોત અને સત્રો

સ્થિર ખાનગી સર્વર સરનામું સ્થિર જાહેર સ્રોત નથી. જો બ્રાઉઝિંગ સીધું નવા પ્રદાતા દ્વારા બહાર જાય, તો વેબસાઇટો નવું પ્રદાતા-તરફી સરનામું જુએ છે.

તે સરનામું સ્થિર રાખવા માટે પોતાની ઉપલબ્ધતા અને નીતિ સાથે જાણી જોઈને કરેલી બહિર્ગમ ડિઝાઇન જરૂરી છે. તે ટનલ સાથે મફતમાં આવતું નથી.

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

ચાર તપાસ સાથે ખસેડવાની ખાતરી કરો

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

Linux ગેટવે પર, આ ત્રણ તે યાદીના મધ્ય ભાગને આવરી લે છે:

ip route get 10.55.8.20
ip xfrm policy list
curl -sS -o /dev/null -w "%{http_code}" --max-time 8 http://10.55.8.20/health

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