ifconfig-noexec તમારું SSH સેશન બચાવતું નથી: તે ખરેખર શું કરે છે
તે OpenVPN નું પોતાનું ઇન્ટરફેસ સરનામું સેટિંગ દબાવે છે. તે SSH માટે જવાબનો રૂટ અનામત રાખતું નથી, બધા રૂટ ફેરફારો બંધ કરતું નથી કે ખૂટતું સરનામું પૂરું પાડતું નથી.
એક ફોરમ થ્રેડમાં, ifconfig-noexec ને એ ઉપાય તરીકે સૂચવવામાં આવે છે જે ટનલ ઉપર આવે ત્યારે SSH સેશન જીવંત રાખે છે. આ તર્ક ત્યાં સુધી વાજબી લાગે છે જ્યાં સુધી તમે ન જુઓ કે આ વિકલ્પ શું બદલે છે. તે OpenVPN ને ટનલ ઇન્ટરફેસનું સરનામું ગોઠવતા અટકાવે છે અને એ મૂલ્યો સ્ક્રિપ્ટોને સોંપે છે; તમારા મેનેજમેન્ટ કનેક્શનના જવાબો ક્યાં જાય છે તે વિશે તે કંઈ કહેતું નથી. ઊલટું માનવાથી એવી ટનલ બને છે જેમાં વાપરી શકાય એવું સરનામું નથી અને SSH સેશન તો પણ મરી જાય છે.
આ વિકલ્પ ખરેખર શું સોંપે છે
ડિફૉલ્ટ રૂપે ક્લાઇન્ટ ટનલ ડિવાઇસ ઉપર લાવે છે અને સર્વરે આપેલાં સ્થાનિક તથા દૂરસ્થ સરનામાં ફાળવે છે. ifconfig-noexec સેટ હોય ત્યારે એ પગલું છોડી દેવામાં આવે છે, અને વાટાઘાટ થયેલાં મૂલ્યો સ્ક્રિપ્ટ પર્યાવરણમાં નિકાસ થાય છે જેથી બીજું કંઈક તેમને લાગુ કરી શકે.
માલિકી બદલાય છે. તેની જગ્યાએ કંઈ નવું ઊભું કરવામાં આવતું નથી.
એટલે આ વિકલ્પ જે પ્રશ્નનો જવાબ આપે છે તે એ છે કે ઇન્ટરફેસ કોણ ગોઠવે છે, અને જે પ્રશ્નનો જવાબ તે નથી આપતું તે એ છે કે પેકેટ તમારા સુધી પાછા કઈ રીતે આવે છે. આ બે વાત અલગ રાખો, નહીં તો સરનામા વગરના ઇન્ટરફેસની ભરપાઈ કરવા તમે આખી સાંજ રૂટ સંપાદિત કરવામાં ગાળશો.
અલગ કામો સાથેની ત્રણ મળતી વિકલ્પો
આ કુટુંબ ભૂલવું સહેલું છે કારણ કે નામોમાં એક શબ્દનો ફરક છે અને લક્ષણો એકબીજા પર ચઢે છે. કોઈ પણ પસંદ કરતા પહેલાં દરેક શું દબાવે છે તે વાંચો.
| Option | What stops happening |
|---|---|
ifconfig-noexec | OpenVPN's own tunnel-address configuration; values go to scripts instead |
route-noexec | Automatic route addition and removal; route details go to a script |
route-nopull | Server-pushed routes and related options such as DNS are rejected |
આ અલગ અલગ સમજવાના વિકલ્પો છે, ભેગા પેસ્ટ કરવાનો સમૂહ નથી. સરનામાની ગોઠવણી દબાવવાથી રૂટ ફેરફારો, ફાયરવૉલ નિયમો કે DNS લઈ જતા ધકેલાયેલા વિકલ્પો દબાતા નથી. સોંપાયેલી સ્ક્રિપ્ટ પણ રૂટ બદલવા માટે મુક્ત છે, જે ટાળવાને બદલે તમે સોંપી રહ્યા છો એવો નિર્ણય છે.
જો કોઈ વેન્ડર ક્લાઇન્ટ એન્જિનને લપેટે છે, તો પ્રોફાઇલમાં નીચલા સ્તરનું નિર્દેશ ફેંકીને રેપર તેને માનશે એવી આશા રાખવાને બદલે તેનું સમર્થિત એકીકરણ વાપરો. રેપર ઘણી વાર કનેક્ટ થતી વખતે પ્રોફાઇલ ફરી બનાવે છે, એટલે હાથે કરેલો ફેરફાર કોઈ ભૂલ વિના અદૃશ્ય થઈ જાય છે. ફાઇલ પર આખી સાંજ ગાળતા પહેલાં ક્લાઇન્ટ પોતાના સેટિંગ ક્યાં રાખે છે તે તપાસો. આ કોષ્ટકની દરેક હારને લાગુ પડે છે, ફક્ત તમે જેના માટે આવ્યા તેને નહીં.
તમે જે SSH સેશન બચાવવા માંગતા હતા
SSH કનેક્શનમાં સ્રોત સરનામું, લક્ષ્ય સરનામું અને જવાબનો માર્ગ હોય છે. હમણાં જ પૂર્ણ-ટનલ ડિફૉલ્ટ સ્થાપિત કરેલા સર્વર પર, તમારા જાહેર સરનામાનો જવાબ ટનલ સાથે મેળ ખાય છે અને VPN ગેટવે તેને કાઢી નાખે છે.
ટનલ ઇન્ટરફેસની સરનામાંની ગોઠવણીમાં કંઈ પણ એ બદલતું નથી.
જે સુધારે છે તે છે ટનલ પહેલાંના ગેટવે થઈને તમારા મેનેજમેન્ટ સરનામા માટે વધુ ચોક્કસ રૂટ, અથવા એ ટ્રાફિકને વાળતો નીતિ-નિયમ, ઉપરાંત તમારો હોસ્ટ લાગુ કરે એ ફિલ્ટર સેટિંગ્સ. બંને સમસ્યાઓ ક્યારેક સાથે દેખાય છે, અને એ રીતે એકને બીજાનો ઉપાય માની લેવામાં આવે છે. તેમને અલગ તપાસો: વિકલ્પ વગર ટનલ ઉપર લાવો, ઇન્ટરફેસનું સરનામું અને જવાબનો માર્ગ જુઓ, પછી નક્કી કરો કે બંનેમાંથી ખરેખર ક્યું તૂટ્યું છે.
સોંપાયેલી સ્ક્રિપ્ટે શું સંભાળવું પડે
જો તમે ખરેખર ઇચ્છો કે બીજો માલિક ઇન્ટરફેસ ગોઠવે, તો કામની યાદી બનાવો: સ્થાનિક અને દૂરસ્થ સરનામું લાગુ કરો, ડિવાઇસ ઉપર લાવો, ટિયરડાઉન વખતે સરનામું પુનઃસ્થાપિત કરો કે દૂર કરો, અને ફરી કનેક્ટ થયા પછી એ જ ફરી કરો. એક સફળ સેશનનાં મૂલ્યો હાર્ડકોડ ન કરવાં, કારણ કે સર્વર આગલી વખતે બીજી જોડી આપી શકે છે.
ક્લાઇન્ટ નિકાસ કરે છે એ પર્યાવરણ ચલો જ એ કામ માટે સમર્થિત ઇનપુટ છે.
env | grep -E '^ifconfig_|^route_'એક route-up સ્ક્રિપ્ટની અંદર એ ચલો ઉપલબ્ધ હોય છે; ક્રોન જોબ કે હાથે ચલાવેલા શેલમાં નથી હોતા. તમારી આવૃત્તિ કયો લાઇફસાઇકલ હૂક વાપરે છે તેની પુષ્ટિ કરો, અને હૂક ઇન્ટરફેસ બદલવા પૂરતા અધિકારો સાથે ચાલે છે તેની પણ પુષ્ટિ કરો, કારણ કે ક્લાઇન્ટ કદાચ પહેલેથી અનધિકૃત વપરાશકર્તા પર ઉતરી ગયું હોઈ શકે.
આખું જીવનચક્ર તપાસો, એક સેશન નહીં
ટનલ ઉપર લાવો, ડિવાઇસ પરનું સરનામું તપાસો, પછી ફરી કનેક્ટ કરો અને ફરી તપાસો. જે ગોઠવણી એક વાર કામ કરે અને બીજા પ્રયાસે નિષ્ફળ જાય તેનો અર્થ ઘણી વાર એ હોય છે કે સોંપાયેલું પગલું ફક્ત પહેલા કનેક્શન પર ચાલે છે.
પછી બંને સ્વીકૃતિ માપદંડ સાથે તપાસો: ઇચ્છિત મેનેજમેન્ટ માર્ગ થઈને નવું SSH કનેક્શન કામ કરે છે, અને મંજૂર એપ્લિકેશન ટનલનો યોગ્ય રીતે ઉપયોગ કરે છે.
જૂનું SSH સેશન સંજોગવશાત્ ટકી રહે જ્યારે ટનલમાં સરનામું નથી, એ સફળતા નથી, અને જ્યારે કોઈ કામ સંભાળતું નથી ત્યારે આ વિકલ્પ બરાબર એ જ સ્થિતિ ઊભી કરે છે. પહેલાં ઇન્ટરફેસનું સરનામું તપાસો, પછી મેનેજમેન્ટના જવાબનો માર્ગ, પછી એપ્લિકેશન. જો ત્રણમાંથી બે ખોટા હોય, તો વિકલ્પે કામ ખસેડ્યું છે પણ તેને માલિક આપ્યો નથી.