OpenVPN શરૂ થતું નથી: પ્રથમ લીટી વાંચો, કન્ફિગ નહીં

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

ત્રણ ફક્ત-વાંચવાના આદેશો તમને ત્યાં પહોંચાડે છે: પહેલાં journalctl -u openvpn@server -b --no-pager, પછી systemctl status openvpn@server, અને UDP શ્રોતાઓ તથા તેમના માલિકો માટે ss -lunp.

પહેલી લીટી શાખા પસંદ કરે છે

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

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

બીજું કોણ 1194 પોર્ટ પકડી રાખે છે

દોષિત સામાન્ય રીતે કોઈએ જાણી જોઈને ગોઠવેલું બીજું સર્વર હોતું નથી. બીજા ટર્મિનલમાં હજી જીવતું હાથે શરૂ કરેલું ક્લાયન્ટ, એ જ પોર્ટ પસંદ કરી બેઠેલી બીજી પ્રોફાઈલ, અથવા એવું વેન્ડર બંડલ જેનું પોતાનું ટનલ 1194 પકડી રાખે છે તેની અપેક્ષા રાખો. સોકેટનો માલિક ss -lunp માં દેખાય છે; કોઈ યુનિટ જવાબદાર છે કે નહીં તે જાણવા એ PID systemctl status ને આપો. સિગ્નલથી નહીં, તેના પોતાના નિયંત્રણ માર્ગથી તેને નીચે ઉતારો.

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

પર્જ પછી રહી ગયેલા યુનિટ

પર્જ બાઈનરીઓ કાઢી નાખે છે; હાથે લખાયેલી યુનિટ ફાઈલો, સામાન્ય રીતે /etc/systemd/system હેઠળ, તેમાંથી બચી જાય છે. પછી Systemd એવું યુનિટ ફરી પ્રયત્ન કરે છે જે હવે અસ્તિત્વમાં ન હોય તેવા પાથ તરફ ઈશારો કરે છે, અને સંદેશ ગઈકાલની દૂર કરવાની ક્રિયા વિશે નહીં, એ ગુમ ફાઈલ વિશે હોય છે. systemctl status યુનિટનો ફ્રેગમેન્ટ પાથ ઉપરની નજીક દેખાડે છે, તેથી કંઈ પણ કાઢવા પહેલાં તેને dpkg -S થી તપાસો. અનાથ ગયા પછી systemctl daemon-reload અને systemctl reset-failed સ્થિતિ સાફ કરે છે; નહીં તો પછીનું દરેક સ્થિતિ-તપાસ તેને વારસામાં લે છે.

જ્યારે which openvpn /usr/local હેઠળ કંઈક જવાબ આપે, ત્યારે વપરાયેલી બાઈનરી apt તરફથી નહીં, વેન્ડર ઇન્સ્ટોલર તરફથી આવી છે. એવો ઇન્સ્ટોલર સામાન્ય રીતે પોતાનું શ્રોતા, પોતાની બૂટ એન્ટ્રી અને પોતાનું કન્ફિગ ડિરેક્ટરી લાવે છે, તેથી દૃશ્ય આદેશ કાઢી નાખવાથી સોકેટ પકડાયેલું જ રહે છે.

વેન્ડર જે દસ્તાવેજ કરે તે પ્રમાણે તેને અનઇન્સ્ટોલ કરો, ss -lunp થી પોર્ટ મુક્ત છે તેની ખાતરી કરો, અને જરૂર હોય તો જ ડિસ્ટ્રિબ્યુશન ક્લાયન્ટ ઉમેરો.

ફરી પ્રયાસ કરતા પહેલાં સ્થિતિ ગોઠવો

તેમાંથી તારણ કાઢતા પહેલાં નિષ્ફળ સ્થિતિ સાફ કરો: systemctl reset-failed કાઉન્ટરો દૂર કરે છે, અને પછી systemctl status યુનિટનો ઇતિહાસ નહીં, તેની વર્તમાન સ્થિતિ જણાવે છે. તેને એક વાર શરૂ કરો અને મશીનની એકંદર સ્થિતિ નહીં, તે ચાલનું પોતાનું જર્નલ વાંચો. ટનલ કંઈ વહન કરતું ન હોવા છતાં સક્રિય હોવાનું જણાવતું યુનિટ અલગ સમસ્યા છે, અને ઘણી વધુ સામાન્ય. બંને બગ રિપોર્ટમાં ભળી જાય છે કારણ કે બંને વપરાશકર્તા «VPN કામ કરતું નથી» કહેવા પર પૂરા થાય છે.

તમે લીધેલી શાખા નોંધો: પોર્ટ અથડામણ, ગુમ બાઈનરી, ગુમ કન્ફિગ. આગલી વાર ઓળખવું ઝડપી થશે.