શું તમને લાગે છે કે Pritunl સર્વરનું નામ બદલવાથી તેનો એન્ડપોઇન્ટ બદલાય છે?

Pritunl સર્વરનું નામ બદલવાથી કન્સોલમાં એક લેબલ બદલાય છે. તે ક્લાયન્ટ પ્રોફાઇલ્સ જે એડ્રેસ સાથે જોડાય છે તે બદલતું નથી, અને તે DNS રેકોર્ડ બનાવતું નથી. મહત્વનું મૂલ્ય હોસ્ટનું પબ્લિક એડ્રેસ છે, અને તે એડ્રેસ જેટલી સરળતાથી નામ સ્વીકારે છે.

ક્લાયન્ટ્સ જે નામ સાથે જોડાય છે તે હોસ્ટના એક ફીલ્ડમાં રહે છે

Pritunl હોસ્ટની પબ્લિક એડ્રેસ સેટિંગ દ્વારા એન્ડપોઇન્ટ ખુલ્લો કરે છે, જે પબ્લિક IP એડ્રેસ અથવા DNS નામ સ્વીકારે છે. ત્યાં vpn.example.net મૂકો, અને બનેલી પ્રોફાઇલ્સ તથા પ્રમાણિત સિંક તે નામ ક્લાયન્ટ્સને આપશે. રેકોર્ડ પહેલેથી હોવો જોઈએ અને VPN ટ્રાન્સપોર્ટ સ્વીકારતા લિસનર તરફ રિઝોલ્વ થવો જોઈએ; આ ફીલ્ડ ગંતવ્યની જાહેરાત કરે છે, તેને પ્રકાશિત કરતું નથી. સર્વર ઑબ્જેક્ટનું દર્શાવાતું નામ વહીવટી મેટાડેટા છે અને ક્યારેય ક્લાયન્ટના કનેક્શન પ્રયાસ સુધી પહોંચતું નથી.

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

ત્રણ ફીલ્ડ જે સરખા દેખાય છે અને છે નહીં

લોકલ એડ્રેસ Pritunl હોસ્ટ્સ વચ્ચે રેપ્લિકેશન અને રાઉટિંગ માટે કામ કરે છે. લિંક એડ્રેસ જણાવે છે કે જોડાયેલા સર્વર્સ એકબીજા સુધી કેવી રીતે પહોંચે છે. બંનેમાંથી કોઈ એ એડ્રેસ નથી જેની સાથે ક્લાયન્ટ જોડાય છે, અને પબ્લિક નામ તેમાં કૉપી કરવાથી તેઓ જે ટોપોલોજી વર્ણવે છે તે તૂટે છે. પબ્લિક IPv6 એડ્રેસ પોતાના રેકોર્ડ અને પથ સાથે અલગ ફીલ્ડ છે; IPv4 માટે A રેકોર્ડ IPv6 સુલભતા સ્થાપિત કરતો નથી.

DNS નામ પણ કોઈ પોર્ટ મેપિંગ કે લિસનર ધરાવતું નથી. જો સેવા 1194 UDP પર સાંભળે છે, તો નામ હજી પણ એવા હોસ્ટ તરફ રિઝોલ્વ થાય છે જેને 1194 UDP સ્વીકારવું પડે. પોર્ટ 443 પરનો HTTP રિવર્સ પ્રોક્સી જે વેબ કન્સોલ આપે છે તે VPN ટ્રાન્સપોર્ટ એન્ડપોઇન્ટ નથી, જ્યારે બંને એક જ નામ વહેંચે ત્યારે પણ.

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

નવું નામ હાજર ક્લાયન્ટ્સ પર મોકલો

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

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

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

વાસ્તવિક કનેક્શન સાથે ફેરફાર સ્વીકારો

રિઝોલ્યુશન સૌથી નબળી શક્ય કસોટી છે. dig +short vpn.example.net એડ્રેસ પરત આપે તો તે ફક્ત સાબિત કરે છે કે રેકોર્ડ હાજર છે.

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

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