systemd-socket-proxyd તેના SSH SOCKS ટનલ પછી પણ ટકી શકે છે

સોકેટ ફોરવર્ડિંગ સહાયકનું જીવનચક્ર તેની SSH નિર્ભરતા સાથે સુસંગત કરો જેથી મૃત ટનલ સ્વસ્થ દેખાતું ફ્રન્ટ એન્ડ છોડી ન જાય.

જો SSH બહાર નીકળ્યા પછી પણ ફ્રન્ટ પોર્ટ કનેક્શન સ્વીકારે છે, તો ત્રણેય યુનિટ તપાસો. એક્ટિવેશન સોકેટ, systemd-socket-proxyd સહાયક અને SSH દ્વારા બનેલ SOCKS શ્રોતાના જીવનકાળ અલગ છે:

સોકેટસહાયકSSHઅર્થઘટન
સાંભળી રહ્યું છેનિષ્ક્રિયનિષ્ક્રિયકદાચ સામાન્ય રીતે માંગની રાહ જોઈ રહ્યું છે
સાંભળી રહ્યું છેસક્રિયસક્રિયપ્રક્રિયાઓ અસ્તિત્વમાં છે; પરંતુ અંતિમ લક્ષ્યની સ્વાસ્થ્ય સાબિત નથી
સાંભળી રહ્યું છેસક્રિયનિષ્ક્રિયફ્રન્ટએન્ડ તેના બેકએન્ડ વગર કામ સ્વીકારી શકે છે

સહાયક અને SSH ને સાથે શરૂ કરવાથી પછીનું સ્ટોપ ટ્રાન્ઝિશન નક્કી થતું નથી. જે સહાયક તેની ટનલ વગર સક્રિય રહી ન શકે, તેના માટે systemd વધુ મજબૂત સંબંધ દસ્તાવેજ કરે છે:

[Unit]
BindsTo=ssh-socks.service
After=ssh-socks.service

વાસ્તવિક ડિઝાઇનમાં યોગ્ય યુનિટ પર તેને લાગુ કરો. Requires= અને ક્રમ માત્ર સંબંધનો ભાગ સંભાળે છે. પહેલેથી સક્રિય ફ્રન્ટએન્ડ તેના બેકએન્ડ અદૃશ્ય થયા પછી ફરી ક્યારેય એક્ટિવેશન ન કરી શકે. નિષ્ફળ યુનિટની સ્થિતિ અને સ્ટાર્ટ-રેટ મર્યાદાઓ પણ તપાસો; નિર્ભરતાઓ તે મર્યાદાઓને રદ કરતી નથી.

પછી સ્ટાર્ટઅપ તૈયારી સ્થાપિત કરો. After= કાર્યોનો ક્રમ ગોઠવે છે, Type=simple SSH શ્રોતાની તૈયારી નહીં. ધીમી પ્રમાણીકરણ દરમિયાન નિશ્ચિત રાહ નિષ્ફળ જઈ શકે. જરૂરી શ્રોતા સ્થાપિત કરતો સ્ટાર્ટઅપ કરાર વાપરો; ExitOnForwardFailure=yes ફોરવર્ડિંગ સેટઅપની નિષ્ફળતા પકડે છે, પછીની લક્ષ્ય-પહોંચ નહીં.

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

સંબંધિત લેખો