નવું રાઉટર, એ જ VPN સર્વર: તેનું જાહેર પ્રવેશ બદલો

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

બદલીને એક નહીં, બે સોંપણી તરીકે ગણો અને કામ કરતી વખતે એડમિન ઇન્ટરફેસમાં જવાનો સ્થાનિક રસ્તો રાખો.

પ્લગ કાઢતા પહેલાં સોંપણી લખી લો

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

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

એ રેકોર્ડ સુરક્ષિત જગ્યાએ રાખો. રાઉટર બેકઅપમાં WAN લિંકની ઓળખપત્રો હોઈ શકે. નિકાસ ફાઈલને સેટિંગ્સની નોંધ નહીં, પાસવર્ડની જેમ વાપરો.

પહેલાં સરનામું ખસેડો, પછી ફોરવર્ડ

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

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

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

કોણ જાહેર નામ અપડેટ કરશે તે નક્કી કરો

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

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

બહારથી બદલી સાબિત કરો

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

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

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

નવું મેપિંગ તમારી પુનઃપ્રાપ્તિ નોંધ સાથે રાખો

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

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