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

ફાઇલ એક ક્ષણનું વર્ણન કરે છે, કરારનું નહીં

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

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

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

કોઈ સેટિંગને સ્પર્શ કરતાં પહેલાં નિષ્ફળતાનું તબક્કું વાંચો

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

What happensThe assertion that brokeSupported response
Name never resolvesThe host still exists under that nameGet a current endpoint from the operator
TCP connect times outThe listener is on that port and reachableCheck the current published port, then the local network
TLS or key exchange failsThe peer presents the expected identityCompare the certificate, not the cipher list
Authentication rejectedThe account is still validGet credentials reissued or stop using the service
dig +short vpn.example.net
curl -sS -o /dev/null -w 'connect=%{time_connect} tls=%{time_appconnect}\n' --max-time 8 https://vpn.example.net:443/
openssl s_client -connect vpn.example.net:443 -servername vpn.example.net -brief </dev/null

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

પ્રમાણપત્ર અને ઓળખના ફેરફારો જ શાંત છે

મોટાભાગની નિષ્ફળતાઓ પોતાની જાહેરાત કરે છે. ઓળખના ફેરફારો કરતા નથી, કારણ કે પ્રમાણપત્રનું નામ પિન કરતો ક્લાઇન્ટ સંપૂર્ણ સારું નવું પ્રમાણપત્ર એવા સંદેશ સાથે નકારશે જે ઘણા લોકો ભૂલ તરીકે વાંચે છે. ટનલ ઠીક છે. પિન જૂનો છે.

કંઈ પણ નિષ્કર્ષ કાઢતાં પહેલાં ઓળખના વિકલ્પો શોધો:

grep -nE '^(remote|proto|auth|verify-x509-name|tls-crypt|key-direction|ca) ' profile.ovpn
openssl x509 -in profile-ca.crt -noout -subject -dates

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

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

ફક્ત ઓપરેટર જ માન્ય બદલી પ્રકાશિત કરી શકે છે

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

ચકાસણી સસ્તી છે. પ્રકાશિત સ્થાન પરથી વર્તમાન ફાઇલ લાવો, એન્ડપોઇન્ટ અને પ્રોટોકોલને યાદી સાથે સરખાવો, અને ફાઇલના નામ પર ભરોસો કરવાને બદલે CA સામગ્રીની ફિંગરપ્રિન્ટની પુષ્ટિ કરો:

curl -sS -o current.ovpn https://example.org/nodes/current.ovpn
sha256sum current.ovpn profile.ovpn
grep -nE '^(remote|proto) ' current.ovpn

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

જૂની એન્ટ્રી નિવૃત્ત કરો અને શું થયું તે નોંધો

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

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

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

સંબંધિત લેખો