ખરેખર કઈ OpenVPN ઇન્સ્ટન્સ તમારી PiVPN પ્રોફાઇલ વાપરે છે?

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

હેલ્પર અને ડિમન અલગ વસ્તુઓ છે

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

systemd હોસ્ટ પર ડિરેક્ટરી સૂચિને બદલે સક્રિય યુનિટથી શરૂ કરો. નામ પેકેજિંગ પર આધાર રાખે છે: Debian અને Raspberry Pi OS ઇમેજ સામાન્ય રીતે ટેમ્પલેટ ઇન્સ્ટન્સ આપે છે, જેમ કે openvpn-server@server, જ્યારે જૂની ઇન્સ્ટોલેશન openvpn@server વાપરે છે. ફાઇલના નામ પરથી અનુમાન કરવાને બદલે મેનેજરને પૂછો કે કઈ ચાલી રહી છે.

systemctl list-units --type=service --all | grep -i openvpn
systemctl cat openvpn-server@server

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

ડિમને ઉકેલેલી કોન્ફિગરેશન ચેઇનને અનુસરો

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

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

systemctl show -p ExecStart --value openvpn-server@server
grep -E '^(config|dev|proto|port|local|log|log-append|status|ca|cert|key|tls-auth|tls-crypt)' /etc/openvpn/server/server.conf

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

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

લોગને પ્રક્રિયા સાથે મેળવો, તમને યાદ હોય તે ભૂલ સાથે નહીં

બે લોગ ગંતવ્યો સામાન્ય છે, અને તેમાંથી માત્ર એક જ જર્નલ છે. log-append સેટ હોય ત્યારે ડિમન એ ફાઇલમાં લખે છે અને જર્નલ સ્ટાર્ટઅપ લાઇન સિવાય થોડું રાખે છે. તેના વિના, journalctl ઘટનાઓનો સ્રોત છે.

journalctl -u openvpn-server@server -n 80 --no-pager

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

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

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

ટનલ ફરીથી બાંધવી નિદાનનું પગલું નથી

લલચાવતો શોર્ટકટ બીજી, સરળ ટનલ ઊભી કરવાનો છે: સ્ટેટિક કી, પ્રમાણપત્રો નહીં, વધારાનું પ્રમાણીકરણ નહીં. તે ઘણી વાર જોડાશે, અને તે ફક્ત એ સાબિત કરે છે કે બે હોસ્ટ તેમની વચ્ચે UDP કે TCP પસાર કરી શકે છે. પ્રમાણપત્ર-પ્રમાણિત ડિપ્લોયમેન્ટ કેમ નિષ્ફળ જાય તે વિશે તે કંઈ કહેતું નથી, અને તમને રાખવા કહેવાયું હતું તે સુરક્ષા મોડેલ ચૂપચાપ બદલી નાખે છે.

એ જ લાગુ પડે છે tls-auth અથવા tls-crypt નિષ્ક્રિય કરવા, verify-x509-name ઢીલું કરવા, અથવા લીલો દરજ્જો મેળવવા બીજું પરિબળ છોડી દેવા પર. જે ટનલ ચકાસણી દૂર કરવામાં આવી હોવાથી જોડાય છે તે અલગ સિસ્ટમ છે, સુધારેલી નહીં.

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

આગળની વ્યક્તિને શું આપવું

ચાર હકીકતો ત્યાં સુધી લખો જ્યાં સુધી તમારી પાસે છે: openvpn --version તરફથી OpenVPN આવૃત્તિ, સક્રિય યુનિટ, ઇન્ક્લુડ સાથેની કોન્ફિગરેશન ચેઇન, અને એક પ્રયાસ આવરી લેતી લોગ વિન્ડો. એ ચાર અસ્પષ્ટ ફરિયાદને પુનરુત્પાદનયોગ્ય કેસમાં ફેરવે છે.

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

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