ઇન્ટરેક્ટિવ લૉગિન પછી OpenConnect ને બૅકગ્રાઉન્ડમાં કેવી રીતે ચલાવવું
લૉગિન ફોરગ્રાઉન્ડમાં પૂરું કરો અને પછી ટનલ ક્લાયન્ટના પોતાના બૅકગ્રાઉન્ડ મોડને સોંપો. જે ચકાસણીઓ તેને શોધી શકાય તેવું અને બંધ કરી શકાય તેવું રાખે છે.
તમે MFA પ્રોમ્પ્ટ પૂરો કરો છો, ટનલ ઉપર આવે છે, અને ટર્મિનલ બંધ કરવાથી કનેક્શન પણ જતું રહે છે. આ દેખરેખની સમસ્યા છે, પ્રમાણીકરણની નહીં, અને OpenConnect પાસે તેને હલ કરતો સ્વિચ પહેલેથી છે. ઉકેલ એ છે કે સ્ટાર્ટઅપ પૂરો થયા પછી ક્લાયન્ટને બૅકગ્રાઉન્ડમાં ફોર્ક થવા દેવું, જ્યારે ઇન્ટરેક્ટિવ ભાગ ખરેખર પૂરો થઈ ગયો હોય. નીચે ચકાસણીઓની શ્રેણી છે: ક્રમમાં આગળ વધો અને તમારા ગેટવે માટે જે પ્રથમ લાગુ ન પડે ત્યાં થોભો.
લૉગિન વખતે ગેટવે શું માગે છે તેની ખાતરી કરો
કમાન્ડ લખતા પહેલાં ડિપ્લોયમેન્ટ જે ક્રેડેન્શિયલ પથ લાદે છે તે નોંધો. ફક્ત સર્ટિફિકેટ, પાસવર્ડ સાથે ટોકન, અને SAML પ્રદાતા દ્વારા બ્રાઉઝરની આવ-જા—આ ત્રણે અલગ રીતે વર્તે છે, અને બૅકગ્રાઉન્ડ મોડ તેમાંથી કંઈ પણ છોડી શકતું નથી. આ વિકલ્પ સ્ટાર્ટઅપ પછી શું થાય તે બદલે છે, ક્યારેય તે દરમિયાન શું થાય તે નહીં.
લલચાવતો ઉપાય પ્રોમ્પ્ટને આપમેળે કરવો છે. પાસવર્ડ પ્રોમ્પ્ટ ઓળખે ત્યારે નિશ્ચિત જવાબ ટાઇપ કરતું રેપર તે ક્ષણે તૂટી પડે છે જ્યારે ગેટવે એક વખતનો કોડ માગે છે, અને તે બીજા ખાતા વાંચી શકે તેવી ફાઇલમાં ક્રેડેન્શિયલ મૂકી જાય છે. જો વ્યક્તિએ સેશન મંજૂર કરવું પડે, તો વ્યક્તિને ચક્રમાં રાખો.
પ્રથમ સેશન ફોરગ્રાઉન્ડમાં ચલાવો અને આઉટપુટ વાંચો
એક વાર સામાન્ય રીતે કનેક્ટ થાઓ અને આખું હેન્ડશેક છપાવા દો. વપરાતું પ્રોટોકોલ, સર્ટિફિકેટ કે ટોકનનો પથ, સર્વર આપતું ટનલ સરનામું, અને કનેક્શન સ્વીકારતા પહેલાંની દરેક ચેતવણી નોંધો. એ ટ્રાન્સક્રિપ્ટ તમારી આધારરેખા છે અને પછીથી ક્લાયન્ટ સમસ્યાને ગેટવે ફેરફારથી અલગ પાડવાનો એકમાત્ર સસ્તો રસ્તો છે. તેને ટર્મિનલ બફરની બહાર સાચવો.
પછી એ જ કૉલ બૅકગ્રાઉન્ડ મોડ અને PID ફાઇલ ઉમેરીને પુનરાવર્તિત કરો, ઉદાહરણ તરીકે openconnect --background --pid-file /run/openconnect.pid vpn.example.net, અને તમારા ગેટવેને જરૂરી પ્રોટોકોલ તથા પ્રમાણીકરણ વિકલ્પો એ જ લાઇનમાં રાખો. OpenConnect મેન્યુઅલ આ વિકલ્પને સ્ટાર્ટઅપ પૂરો થયા પછી બૅકગ્રાઉન્ડમાં ચાલુ રાખવા તરીકે વર્ણવે છે, અને તેથી જ ઇન્ટરેક્ટિવ તબક્કો પહેલા પૂરો થવો જોઈએ.
ચાલતી પ્રક્રિયાને શોધી શકાય તેવી અને બંધ કરી શકાય તેવી બનાવો
PID ફાઇલ ત્યારે જ પુરાવો છે જ્યારે તે જીવંત પ્રક્રિયા સાથે મેળ ખાય. તેને સેવા ખાતાની માલિકીના ડિરેક્ટરીમાં મૂકો, અને કોઈ સિગ્નલ મોકલતા પહેલાં નોંધાયેલ નંબરને પ્રક્રિયા કોષ્ટક સાથે સરખાવો. રીબૂટ અને ક્રૅશ ફાઇલ છોડી જાય છે, અને જૂની ફાઇલ એ સામાન્ય કારણ છે કે સ્ટોપ સ્ક્રિપ્ટ સફળતા જાહેર કરે જ્યારે ટનલ હજી ચાલુ હોય. ચકાસણીને સ્ટોપ પ્રક્રિયાનો ભાગ ગણો, વૈકલ્પિક પગલું નહીં.
ચકાસાયેલ PID ને સિગ્નલ મોકલો, પછી એક્ઝિટ સ્ટેટસ પર ભરોસો કરવાને બદલે ટનલ ઇન્ટરફેસ ખરેખર અદૃશ્ય થયું છે તેની ખાતરી કરો. જો ઇન્ટરફેસ ગોઠવવા ક્લાયન્ટને ઉચ્ચ અધિકારો જોઈએ, તો સિગ્નલ એવા ખાતામાંથી આવવો જોઈએ જેને તે મોકલવાની પરવાનગી હોય.
બૅકગ્રાઉન્ડ મોડને સુપરવાઇઝર હેઠળ ઢગલો ન કરો
systemd અને સમાન સુપરવાઇઝર તેમણે શરૂ કરેલી પ્રક્રિયાની માલિકી ધરાવવાની અપેક્ષા રાખે છે, તેથી દૂર ફોર્ક થતું ક્લાયન્ટ તેમને મૂંઝવે છે. સુપરવાઇઝર લૉન્ચરને નીકળતું જુએ છે જ્યારે સાચું કનેક્શન ચાલુ રહે છે, તેથી રીસ્ટાર્ટ લોજિક, સ્ટેટસ રિપોર્ટિંગ અને સ્ટોપ ટાઇમઆઉટ એવી વસ્તુ વર્ણવે છે જે હવે સાચી નથી. યુનિટને સમર્થિત ફોરગ્રાઉન્ડ ગોઠવણમાં લખો અને ડીમનનું કામ સુપરવાઇઝરને કરવા દો.
--background એવા સેશન માટે રાખો જે વ્યક્તિ શરૂ કરે અને પછી જતી રહે. જો જરૂરિયાત એવી ટનલની હોય જે કોઈ લૉગિન કરે તે પહેલાં અસ્તિત્વમાં હોય, તો ખૂટતો ભાગ મંજૂર કરેલી બિન-ઇન્ટરેક્ટિવ ઓળખ અને તેને નવીકરણ કરવાની યોજના છે, અને કોઈ કમાન્ડ-લાઇન ફ્લેગ બંનેમાંથી એક પણ આપતું નથી. બૂટ સ્ક્રિપ્ટમાં ફ્લેગ ઉમેરવાથી એવી ટનલ બને છે જે પ્રથમ સમાપ્ત ક્રેડેન્શિયલ પર શાંતિથી નિષ્ફળ જાય છે.
સેશન કૂકીને ક્રેડેન્શિયલ ગણો
OpenConnect --authenticate દ્વારા અલગ પ્રમાણીકરણ તબક્કો દસ્તાવેજ કરે છે, અને પરિણામી સામગ્રી --cookie-on-stdin થી પાછી આપી શકાય છે. આ જોડી ઇન્ટિગ્રેશન કામ માટે છે, અને તે જે ઉત્પન્ન કરે છે તે તેને બનાવનાર પાસવર્ડ જેટલું જ સંવેદનશીલ છે.
મૂલ્યને શેલ ઇતિહાસ, લૉગ અને તમે ખોલો તે દરેક ટિકિટની બહાર રાખો. હેન્ડઑફ સ્ક્રિપ્ટે પણ કૂકી સાથે ક્લાયન્ટને મળેલી ચકાસાયેલ એન્ડપૉઇન્ટ માહિતી સાચવવી જોઈએ; તે ગુમાવો તો પછીની રન એવા હોસ્ટ સાથે જોડાઈ શકે જેને તમે ક્યારેય પ્રમાણિત કર્યું નથી, જે ફક્ત નિષ્ફળ થતા કનેક્શન કરતાં ખરાબ છે.
ટર્મિનલ બંધ કરતા પહેલાં યાદી પૂરી કરો
ચાર વસ્તુ સાચી હોવી જોઈએ: ઇન્ટરેક્ટિવ લૉગિન ફોરગ્રાઉન્ડમાં પૂરું થયું, PID ફાઇલ તમે ચકાસેલી પ્રક્રિયા દર્શાવે છે, સુપરવાઇઝરનો પ્રશ્ન એક કે બીજી બાજુ નક્કી થયો છે, અને કૂકી પાસે સાદી ટેક્સ્ટ ફાઇલ ન હોય તેવી સંગ્રહ યોજના છે. ચારેય સાચાં હોય ત્યારે ટર્મિનલથી દૂર જવું સુરક્ષિત છે અને ટનલ ચાલુ રહે છે.
જો તેમાંથી એક નિષ્ફળ જાય, તો બીજાને સ્પર્શ કરતા પહેલાં તે મુદ્દો સુધારો, કારણ કે બાકીની ચકાસણીઓ તેની ભરપાઈ કરી શકતી નથી. પ્રથમ રનની ફોરગ્રાઉન્ડ ટ્રાન્સક્રિપ્ટ પણ રાખો: આગલી વાર ટનલ ચેતવણી વગર પડે ત્યારે એ જ આધારરેખા ગેટવે-બાજુના ફેરફારને ક્લાયન્ટ-બાજુના ફેરફારથી અલગ પાડે છે.