કેટલા સમય સુધી OpenConnect તૂટેલા VPN સાથે ફરી જોડાવાનો પ્રયાસ કરવો જોઈએ?

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

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

ફરી-જોડાણ વિન્ડો ખરેખર શું મર્યાદિત કરે છે

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

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

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

સુપરવાઇઝર ફરી-શરૂઆત અને ક્લાઇન્ટ ફરી-પ્રયાસો બે સ્તર છે

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

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

sudo openconnect --background --pid-file=/run/openconnect/vpn.pid \
  --reconnect-timeout=180 \
  --user=<account> https://vpn.example.edu

એ લાઇનમાં બે વિગતો વજન ધરાવે છે. --background પ્રક્રિયાને અલગ કરે છે, તેથી pid ફાઇલ તેના પરનું એકમાત્ર ભરોસાપાત્ર હેન્ડલ બને છે, અને ટાઇમઆઉટ ત્યારે જ ખર્ચાય છે જ્યારે એ જ પ્રક્રિયા જીવંત હોય; તેને મારતું સુપરવાઇઝર આગળ ચાલવા માટે કોઈ બજેટ રાખતું નથી.

જાણીતા ડિસ્કનેક્ટને પોતાનું સંકેત જોઈએ. આયોજિત વિરામ અને સાચો વિક્ષેપ ભોળા નિરીક્ષકને એકસરખા લાગે છે, બંને «જોડાયેલું નથી» તરીકે વંચાય છે. વિરામને સુપરવાઇઝરની સ્ટોપ ક્રિયા દ્વારા, અથવા રેપર સમજે એવા માર્કર દ્વારા ચલાવો, જેથી જાણીતું અટકવું કોઈએ ન માંગેલી રીસ્ટાર્ટ ન કરે.

હેન્ડઓફને ફરી-પ્રયાસ લૂપ સાથે સ્પર્ધા કરતું અટકાવવું

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

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

ઇન્ટરફેસની હાજરી પણ આરોગ્યનું સંકેત નથી. ટનલ ઉપકરણ તેની પાછળ મૃત સત્ર સાથે પણ અસ્તિત્વમાં હોઈ શકે, અને લોન્ચર પ્રક્રિયા કોઈ ટનલ વિના પણ અસ્તિત્વમાં હોઈ શકે. એમાંથી કોઈ અવલોકન સાચી વિનંતી સામે ટકતું નથી. આરોગ્ય વપરાશકર્તાને જે જોઈએ તેમાંથી આવવું જોઈએ, જેમ કે ટનલમાંથી પસાર થઈ જાણીતી આંતરિક સેવા સુધી જતી વિનંતી.

વિક્ષેપ દરમિયાન અને પછી શું ચકાસવું

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

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

curl -sS --max-time 5 -o /dev/null -w '%{http_code}\n' https://intranet.example.internal/health
cat /run/openconnect/vpn.pid
ps -o pid,etime,cmd -p "$(cat /run/openconnect/vpn.pid)"

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

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