VPN ખસી ગયું: તમારો OpenVPN ક્લાયંટ હજુ જૂના IP પર કેમ ડાયલ કરે છે
નવું DNS રેકોર્ડ ફક્ત એક પગલું છે. ફરી કનેક્ટ થવાની અપેક્ષા રાખતા પહેલાં રિઝોલ્વરનો જવાબ, ક્લાયંટ ખરેખર જે સરનામે ડાયલ કરે છે અને રીસ્ટાર્ટના વિકલ્પો સરખાવો.
પ્રોવાઇડરે તમારું જાહેર સરનામું બદલ્યું, તમે ડાયનેમિક DNS રેકોર્ડ અપડેટ કર્યું, અને ક્લાયંટ હજુ કનેક્ટ થઈ શકતો નથી. બહારથી એમ લાગે છે કે રેકોર્ડ ફેલાયો નથી. મોટા ભાગે રેકોર્ડ ઠીક હોય છે અને ક્લાયંટ એ સરનામે ડાયલ કરે છે જે તેણે ખસેડતાં પહેલાં રિઝોલ્વ કર્યું હતું, કારણ કે ચાલુ ટનલ અને સાચવેલી પ્રોફાઇલ બંનેને સર્વર ક્યાં રહે છે તેની પોતાની ધારણા હોય છે. ત્રણ સ્તરોએ સહમત થવું પડે, અને તે અલગ સમયપત્રકે અપડેટ થાય છે.
DNS શું કહે છે તે નહીં, પ્રોફાઇલ શું ડાયલ કરે છે તે જુઓ
તમે ખરેખર વાપરો છો તે કનેક્શન ખોલો અને remote લીટી વાંચો. ત્યાંનું આંકડાકીય સરનામું ક્યારેય હોસ્ટનામ અપડેટને અનુસરતું નથી, રેકોર્ડ ગમે તેટલું સાચું થાય.
પછી તપાસો કે તમે સંપાદિત કરેલી પ્રોફાઇલ એ જ છે જે ક્લાયંટે લોડ કરી. આયાત કરેલી પ્રોફાઇલ સામાન્ય છે: મેનેજરે મહિનાઓ પહેલાં નકલ લઈને પોતાની આવૃત્તિ રાખી હોઈ શકે, તેથી તમારા ડાઉનલોડ ફોલ્ડરની ફાઇલ અને એપની એન્ટ્રી અલગ હોઈ શકે. DNS ડિબગ કરવાનું શરૂ કરતાં પહેલાં ક્લાયંટની પોતાની કનેક્શન વિગતોમાંનો એન્ડપોઇન્ટ સરખાવો.
બે ફાઇલ, એક એન્ડપોઇન્ટ — અહીં સામાન્ય શોધ એ જ છે.
grep -nE '^remote|^resolv-retry|^persist-remote-ip|^float' client.ovpn
printf 'resolver says: '; dig +short vpn.example.netક્લાયંટનો આગલો કનેક્શન પ્રયાસ વાંચો
વિગતવાર લોગિંગ સાથે કનેક્શન ફરી શરૂ કરો અને જે લીટીમાં સંપર્ક કરવાનું સરનામું કહેવાયું છે તે વાંચો. એ મૂલ્ય જ મહત્વનું છે, તમારા બ્રાઉઝરે જે રિઝોલ્વ કર્યું તે નહીં.
રિઝોલ્વર કેશ હજુ અગાઉનો જવાબ રાખી શકે છે, અને કેટલાક નેટવર્ક તેને રેકોર્ડના TTL માંગે તેના કરતાં વધુ સમય રાખે છે. અન્યત્રથી ચકાસેલા જાહેર રિઝોલ્વરને નહીં, ક્લાયંટ ખરેખર વાપરે છે તે રિઝોલ્વરને પૂછો.
જો લોગ નવું સરનામું દર્શાવે અને કનેક્શન હજુ નિષ્ફળ જાય, તો સમસ્યા ખસી ગઈ છે: પેકેટ ક્યાંક જાય છે અને કોઈ જવાબ આપતું નથી. આ લિસનર, ફાયરવોલ કે પોર્ટ-ફોરવર્ડિંગનો પ્રશ્ન છે, અને તે ક્લાયંટના રિઝોલ્યુશન માર્ગમાં નહીં, સર્વર બાજુ હોય છે. આ બે નિષ્ફળતાઓ અલગ રાખો, કારણ કે અપ્રાપ્ય લિસનરને DNS સમસ્યા ગણવાથી તમે એ જ લૂપમાં બે વાર ફરો છો.
તમે કયો રીસ્ટાર્ટ કરી રહ્યા છો તે જાણો
બધા રીસ્ટાર્ટ એક જ સ્થિતિ જાળવતા નથી, તેથી પ્રક્રિયા કેવી રીતે રિસાયકલ થાય તેના આધારે સરનામા ફેરફાર અલગ રીતે વર્તી શકે. સિગ્નલથી શરૂ થતો સોફ્ટ રીસ્ટાર્ટ અગાઉના સેશનનો વધુ સંદર્ભ રાખે છે, જ્યારે સંપૂર્ણ સ્ટોપ અને સ્ટાર્ટ ફરીથી કન્ફિગરેશનથી શરૂ થાય છે. જો તમે ચકાસી રહ્યા છો કે ક્લાયંટ ફરી રિઝોલ્વ કરે છે કે નહીં, તો તમને કન્ફિગરેશનથી શરૂ થતો માર્ગ જોઈએ.
પર્સિસ્ટન્સ સેટિંગ્સ પણ મહત્વની છે, કારણ કે તે નવા સરનામાં પાછળ દોડવા નહીં, પરંતુ જે પ્રમાણિત થયું તે જાળવવા માટે બનાવાયેલી છે.
સૌથી સ્વચ્છ પરીક્ષણ ઇચ્છિત પ્રોફાઇલથી તાજી શરૂઆત છે, અને પછી એન્ડપોઇન્ટનું નામ આપતી લોગ લીટી પર નજર. અડધી જાળવેલી સેશનમાંથી તમે જે શીખો તે એ સેશન વિશેનું વિધાન છે.
ચાર વિકલ્પો અને તેમના અલગ કાર્યો
હોસ્ટનામ સાથે remote એ સેટિંગ છે જે ફરી રિઝોલ્વ કરવાનું શક્ય બનાવે છે; તે લીટી પરનું શાબ્દિક સરનામું તેને બાકાત કરે છે. resolv-retry નિયંત્રિત કરે છે કે લુકઅપ નિષ્ફળ થાય ત્યારે શું થાય, અને 2.6 તેને પહેલેથી જ ડિફોલ્ટ રૂપે અનંત રાખે છે. તેથી તે ઉમેરવાથી કંઈ બદલાતું નથી, અને તે ક્યારેય અલગ જવાબ માટે સામયિક તપાસ નિર્ધારિત કરતું નથી. જે કહે છે કે તે નવા સરનામાં માટે પૂછપરછ કરે છે, તેણે પુનઃપ્રાપ્તિ અને તાજગી ભેળવી દીધી છે.
persist-remote-ip તાજગી નહીં, સાતત્યનો પ્રશ્ન છે: તે છેલ્લે પ્રમાણિત થયેલા એન્ડપોઇન્ટનો, સમર્થિત સોફ્ટ રીસ્ટાર્ટ દરમિયાન ફરી ઉપયોગ કરે છે. જ્યારે તમે સ્થળાંતર ચકાસી રહ્યા છો, ત્યારે આ તમને જે જોઈએ તેનાથી ઊલટું છે. જો તમારું બિલ્ડ તેને ચાલુ કરે તો પરીક્ષણ માટે તેને બંધ કરો, અને નવો એન્ડપોઇન્ટ સાબિત થાય પછી પાછું ચાલુ કરો. ચાલુ રહે તો, સફળ પુનઃકનેક્શન DNS વિશે તમને કંઈ ન કહે.
float સેશનની વચ્ચે સરનામું બદલાયેલા પ્રમાણિત પીઅરને સ્વીકારે છે, અને ફક્ત તે જ ગોઠવણોમાં જે તેને સમર્થન આપે છે. તે DNS તાજું કરતું નથી, અને પ્રોવાઇડર ફેરફારને જાતે અનુસરશે નહીં. તેને ભટકતા પીઅર માટેની સ્થિતિસ્થાપકતા ગણો, સર્વર માટે ડાયનેમિક સરનામાની પદ્ધતિ નહીં.
ક્લાયંટને દોષ આપતાં પહેલાં નવો એન્ડપોઇન્ટ ખાતરી કરો
તમારા નેટવર્કની બહારથી તપાસો કે નવા સરનામા પાસે કન્ફિગર કરેલા પોર્ટ પર લિસનર છે અને પ્રોવાઇડરનું ફોરવર્ડિંગ તેની તરફ ઇશારો કરે છે. ખુલ્લો પોર્ટ ન હોય તેવી મશીન માટે સાચું A રેકોર્ડ બરાબર એ જ લક્ષણ ઉત્પન્ન કરે છે જે લોકો કેશિંગ પર ઢોળે છે.
પછી ફરી કનેક્ટ થાઓ અને બે વસ્તુ ચકાસો: ક્લાયંટ અપેક્ષિત સર્વર સર્ટિફિકેટ સામે પ્રમાણિત થયો, અને સેશન તમે ઇચ્છેલા સંસાધન સુધી પહોંચે છે. સરનામા ફેરફાર ઓળખની આવશ્યકતાઓ ઘટાડતું નથી, અને ખોટા એન્ડપોઇન્ટ પર સફળ થતું કનેક્શન નિષ્ફળ જતા કરતાં ખરાબ છે. OpenVPN 2.6 મેન્યુઅલ ચારેય વિકલ્પો તેમના પોતાના વ્યાપ સાથે સૂચિબદ્ધ કરે છે, અને એ જ પ્રોફાઇલની બાજુમાં રાખવાની ચેકલિસ્ટ છે.
તમારી વ્યવસ્થાપન પહોંચ વહન કરતી ટનલ ફરી શરૂ કરતાં પહેલાં સર્વરમાં જવાનો આઉટ-ઓફ-બેન્ડ માર્ગ રાખો. એ એક જ સાવધાની આ પરિસ્થિતિ ઉત્પન્ન કરતી મોટા ભાગની ઘટનાઓ અટકાવે છે.