પોર્ટ 1194 પહેલેથી વપરાશમાં છે: આ OpenVPN સોકેટ કોનું છે?

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

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

ચોક્કસ બાઈન્ડ ભૂલ વાંચો

આ કુટુંબની બે ભૂલો જુદા જુદા અર્થ ધરાવે છે, અને તેમને ભેળવી દેવાથી તમે ખોટા સ્તરે પહોંચો છો. "સરનામું પહેલેથી વપરાશમાં છે" કહે છે કે બીજું સોકેટ તમે માગેલું અંતિમ બિંદુ ધરાવે છે. "સરનામું ઉપલબ્ધ નથી" કહે છે કે તમે માગેલું સરનામું આ હોસ્ટ પર હજી અસ્તિત્વમાં નથી, જે તૈયારીની સમસ્યા છે, નકલ નહીં.

systemctl status openvpn-server@lab --no-pager
journalctl -u openvpn-server@lab -n 20 --no-pager

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

સોકેટની યાદી બનાવો, પોર્ટની નહીં

પોર્ટ નંબર અપૂર્ણ યાદી છે. અંતિમ બિંદુ એ ટ્રાન્સપોર્ટ, સરનામા કુટુંબ, સ્થાનિક સરનામું અને પોર્ટ છે, બધું એક જ નેટવર્ક નામસ્પેસની અંદર. એક જ નંબર પર UDP શ્રોતા અને TCP શ્રોતા જુદા સોકેટ છે, અને જુદા નામસ્પેસમાં એક જ નંબર પરની બે પ્રક્રિયાઓ ક્યારેય મળતી નથી.

ss -lunp | grep -F ':1194'
ss -ltnp | grep -F ':1194'
ss -lunp 'sport = :1194'

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

કઈ પ્રક્રિયા તેની માલિક છે તે શોધો

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

sudo ss -lunp 'sport = :1194'
sudo fuser -v -n udp 1194

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

એક માલિક, અથવા બે રચાયેલા ઇન્સ્ટન્સ

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

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

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

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

બીજા કંઈપણ પહેલાં બાઈન્ડ ચકાસો

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

ss -lunp 'sport = :1194'
systemctl is-active openvpn-server@lab
journalctl -u openvpn-server@lab -f

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