રીબૂટ પછી SSH સાંભળતું નથી: VPN સરનામું મોડું આવે છે

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

બાઇન્ડ ભૂલ ખરેખર શું કહે છે

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

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

કઈ પ્રક્રિયા પોર્ટની માલિક છે

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

ss -ltnp 'sport = :22'
systemctl cat ssh.socket

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

તૈયારી સ્પષ્ટ કરો, ઊંઘ નહીં

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

ip -4 addr show dev tun0
systemctl edit ssh.service

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

સ્વચ્છ બૂટ અને પુનઃકનેક્શનની પરીક્ષા કરો

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

systemctl status ssh.service
ss -ltnp 'sport = :22'

પછી ટનલ નીચે ઉતારો અને ફરી સ્થાપિત કરો, કારણ કે પુનઃકનેક્શન સરનામું બદલી શકે છે અને હાર્ડકોડ કરેલું બંધન તેને અનુસરશે નહીં. પરીક્ષણ દરમિયાન આઉટ-ઓફ-બેન્ડ પુનઃપ્રાપ્તિ માર્ગ રાખો, જેથી ખરાબ ક્રમ ફેરફાર તમને હોસ્ટની બહાર લૉક ન કરી શકે.

સફળતાનો માપદંડ એ શ્રોતા છે જે તેના દસ્તાવેજીકૃત અવલંબન હેઠળ દેખાય છે, કોઈને ફરી શરૂ કરવાનું યાદ આવ્યું હોય તેવો નહીં.