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

બંને નિશ્ચિત ઊંઘ કરતાં સારા છે, જે ના કોઈ વસ્તુની રાહ જુએ છે ને ના તો જણાવે છે કે શેની રાહ જોતી હતી.

local વિકલ્પ ખરેખર શું માંગે છે

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

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

સરનામાની રાહ કે બાઇન્ડનો ફરી પ્રયાસ

રાહ જોવી એટલે ExecStartPre જે સરનામું દેખાય ત્યાં સુધી પૂછપરછ કરે, મર્યાદિત પ્રયાસો સાથે અને સમય પૂરો થાય ત્યારે બિન-શૂન્ય એક્ઝિટ સાથે. ફરી પ્રયાસ એટલે મુખ્ય પ્રક્રિયાને નિષ્ફળ થવા દેવી અને સેવા વ્યવસ્થાપકને તેને ફરી શરૂ કરવા કહેવું, ઉદાહરણ તરીકે Restart=on-failure સાથે RestartSec=5. પ્રથમ ખૂટતી પૂર્વશરતને નિષ્ફળ યુનિટ તરીકે જણાવે છે, જ્યારે બીજું તેને રીસ્ટાર્ટની શ્રેણી તરીકે જણાવે છે જે આખરે અટકે છે; તે જર્નલમાં વધુ ઘોંઘાટ કરે છે પણ એવા સરનામા સામે ટકી રહે છે જે તમે અનુમાન ન કરી શકો તેવા કારણોસર મોડું આવે છે.

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

network-online.target કેમ પૂરતું નથી

network-online.target સક્રિય નેટવર્ક અમલીકરણ online થી જે અર્થ કરે છે તેનું વચન આપે છે, અને તેનાથી વધુ નહીં. systemd-networkd સાથે, systemd-networkd-wait-online નક્કી કરે છે કે તે લક્ષ્ય ક્યારે પ્રાપ્ત થાય, અને તેની મૂળભૂત online ધારણા તમારા ચોક્કસ સરનામા અસ્તિત્વમાં આવે તે પહેલાં સંતોષાઈ શકે છે. NetworkManager હેઠળ, wait-online સેવા પોતાના નિયમો લાગુ કરે છે. લક્ષ્ય પછી ક્રમ આપવો એ સ્વસ્થ પાયાની રેખા છે, એ બાંયધરી નહીં કે એક સરનામું, DNS જવાબ કે દૂરનો સાથી તૈયાર છે.

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

કોલ્ડ બૂટ પછી બાઇન્ડિંગ તપાસો

સેવા રીસ્ટાર્ટને બદલે સાચા કોલ્ડ બૂટ સાથે ચકાસો, કારણ કે રીસ્ટાર્ટ એ સરનામું વારસામાં લે છે જે બૂટ ક્રમે બનાવવું પડ્યું હતું. બૂટ પછી ss -lntp અથવા ss -lunp દરેક શ્રોતાએ ખરેખર જે સ્થાનિક સરનામા પર બાઇન્ડ કર્યું તે બતાવે છે, અને journalctl -b -u openvpn-server@server બતાવે છે કે પહેલો પ્રયાસ નિષ્ફળ ગયો કે નહીં. બાઇન્ડ થયેલા સરનામાને પ્રોફાઇલમાંના સાથે સરખાવો, પછી નેટવર્ક ફરી જોડાયા પછી સરખામણીનું પુનરાવર્તન કરો.

જો પ્રોફાઇલને કદી નિશ્ચિત સરનામાની જરૂર ન હતી, તો local દૂર કરવું કાયદેસર સરળીકરણ છે, પરંતુ તેને ટ્રબલશૂટિંગ ટેવને બદલે સુરક્ષા નિર્ણય બનાવો.

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

સંબંધિત લેખો