துண்டிக்கப்பட்ட VPN-ஐ OpenConnect எவ்வளவு நேரம் மீண்டும் முயற்சிக்க வேண்டும்?

--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 அணுக முடியாததாகவே இருக்க வேண்டும், செயல்முறை கீழேயே இருக்க வேண்டும். பின்னர் பயன்பாட்டின் பக்கத்திலிருந்து சுழற்சியை மூடுங்கள்: அதே கோரிக்கை சுரங்கம் இல்லாதபோது தோல்வியடைய வேண்டும், திரும்பிய பிறகு உங்கள் கொள்கை எதிர்பார்க்கும் மூல முகவரியிலிருந்து வெற்றிபெற வேண்டும். பச்சை சுரங்கச் சின்னம் சான்று அல்ல, ஆனால் நிறைவேற்றப்பட்ட கோரிக்கை சான்று.