FreeBind વિરુદ્ધ After=: systemd સોકેટને VPN સરનામા સાથે બાંધવું

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

બે અલગ સમસ્યાઓ, બે અલગ સ્વિચ

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

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

FreeBind: સરનામા પહેલાં શ્રોતા અસ્તિત્વમાં

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

[Socket]
ListenStream=
ListenStream=10.8.0.1:8443
FreeBind=yes

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

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

After= અને Wants=: ક્રમ એ તૈયારી નથી

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

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

systemctl cat અને systemctl show -p After -p Wants -p Requires વડે એકમ ખરેખર શું ઘોષિત કરે છે તે તપાસો. ત્રણ અલગ ડિરેક્ટરીઓમાંથી drop-in એવી સૂચનાઓ ઉમેરી શકે છે જે તમે ક્યારેય લખી નથી, અને systemd ફક્ત અસરકારક એકમ વાંચે છે.

network-online.target જે કરતું નથી

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

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

તમે ખરેખર પસંદ કરેલું જીવનચક્ર ચકાસો

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

systemd-analyze verify myapp.socket
systemctl cat myapp.socket
ss -ltn "sport = :8443"

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

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