திரை இருட்டும்போது VPN துண்டிக்கப்படுகிறது: பூட்டு, வெற்றுத் திரை அல்லது உறக்கம்?
பூட்டப்பட்ட அமர்வு, இருட்டிய திரை மற்றும் உறக்கத்தில் உள்ள இயந்திரம் ஆகியவை மூன்று வெவ்வேறு நிகழ்வுகள். VPN இன் இணைப்பு தக்கவைப்பு முறையைக் குறை கூறுவதற்கு முன் அவற்றை journalctl உடன் இணைத்துப் பாருங்கள்.
திரை இருட்டியபோது VPN இறந்தது என்று யாராவது சொன்னால், முதல் பயனுள்ள கேள்வி மூன்று நிகழ்வுகளில் எது உண்மையில் நடந்தது என்பதாகும்: அமர்வு பூட்டப்பட்டதா, பேனல் அணைக்கப்பட்டதா, அல்லது முழு இயந்திரமும் உறங்கியதா. இவை வெவ்வேறு நிறுத்தக் கடிகாரங்களில் இயங்கும் வெவ்வேறு வழிமுறைகள், அவற்றில் ஒன்று மட்டுமே ஒரு செயல்முறை திட்டமிடப்படுவதை முழுமையாகத் தடுக்க முடியும். கீழே உள்ள சரிபார்ப்புகளை வரிசையாகச் செல்லுங்கள். கேள்விக்குப் பதிலளிக்கும் முதல் சரிபார்ப்பில் நில்லுங்கள், ஏனெனில் அதற்குப் பின் வரும் ஒவ்வொரு சரிபார்ப்பும் வேறு ஒன்றுக்குப் பதிலளிக்கிறது.
சரிபார்ப்பு ஒன்று: பூட்டை வெற்றுத் திரையிலிருந்தும் உறக்கத்திலிருந்தும் பிரிக்கவும்
பூட்டு அமர்வை யார் பயன்படுத்தலாம் என்பதை மாற்றுகிறது; தொகுப்பான் தொடர்ந்து வரைகிறது, வலைய மேடை தொடர்ந்து இயங்குகிறது, VPN வாடிக்கையாளருக்கு எதுவும் தெரியவில்லை. திரை வெற்றாவது செயலற்ற இடைவேளைக்குப் பிறகு பேனலை அணைத்து இயந்திரத்தை முழுமையாக விழித்திருக்க வைக்கிறது. உறக்கம் செயலிகளை நிறுத்துகிறது, அதாவது பயனர் வெளியில் எந்தச் செயல்முறையும் திட்டமிடப்படுவதில்லை, எனவே இடைவெளியை எவ்வளவு குறுகியதாக இருந்தாலும் எந்த இணைப்பு தக்கவைப்பு சமிக்ஞையும் இயங்க முடியாது.
| Event | What it stops | Can it kill the tunnel? |
|---|---|---|
| Session lock | Input to your session | No |
| Display blank | The panel | No |
| Suspend to RAM | CPU scheduling, hence every process | Yes, and silently |
| Hibernate | Everything, with state written to disk | Yes |
இந்த அட்டவணையே «திரை இருட்டியது» ஒரு நோயறிதல் அல்ல என்பதற்குக் காரணம். ஐந்து நிமிடத்தில் வெற்றாகவும் முப்பதில் உறங்கவும் அமைக்கப்பட்ட கணினி ஆறாவது நிமிடத்தில் முழுமையாக ஆரோக்கியமான சுரங்கப்பாதையுடன் இருண்ட திரையைக் காட்டும். முப்பதாவது நிமிடத்தில் ஏற்படும் தோல்வி வேறு நிகழ்வு, வேறு தீர்வு, இரண்டும் அறையின் மறுமுனையிலிருந்து ஒரே மாதிரியாகவே தெரியும்.
சரிபார்ப்பு இரண்டு: மின் மற்றும் வலைய நிகழ்வுகளை ஒரே நேரக்கோட்டில் வையுங்கள்
முழு துவக்கத்திற்குப் பதிலாக வரையறுக்கப்பட்ட ஒரு சாளரத்திற்கான பதிவைப் படியுங்கள், உள்நுழைவு மேலாளர் மற்றும் இணைப்பின் உரிமையாளர் இரண்டையும் சேர்க்கவும்:
journalctl -b -u systemd-logind -u NetworkManager --since "45 minutes ago"
systemd-inhibit --listமுதல் கட்டளை உறக்கக் கோரிக்கைகள், விழித்தெழுதல் மற்றும் அவற்றைத் தொடர்ந்த வலைய மாற்றங்களைக் காட்டுகிறது. இரண்டாவது தற்போது எது ஒரு தடுப்புப் பூட்டைப் பிடித்திருக்கிறது என்பதைக் காட்டுகிறது, இது ஏதாவது வேண்டுமென்றே உறக்கத்தைத் தடுக்கிறதா, எந்த நிரல் அது என்று உங்களுக்குச் சொல்கிறது. உங்கள் இணைப்பின் உரிமையாளர் NetworkManager இல்லையென்றால் அலகுப் பெயர்களைச் சரிசெய்யுங்கள், மற்றொரு பயனரின் அலகு அல்லது கணினிப் பதிவைப் படிப்பது உள்ளூர் கொள்கையைப் பொறுத்தது என்பதை நினைவில் வையுங்கள்.
காணாத வரி எதிர்மறை முடிவு அல்ல. தேர்ந்தெடுத்த அலகின் பதிவு உங்கள் கணக்கிற்குத் தெரியவில்லை என்றால், உறக்கப் பதிவு இல்லாதது எதையும் நிரூபிக்காது, காலி வடிகட்டியிலிருந்து «அது ஒருபோதும் உறங்கவில்லை» என்று முடிவெடுப்பதே மக்கள் ஒரு வாரம் இணைப்பு தக்கவைப்பைச் சரிசெய்து கழிக்கும் வழி.
சரிபார்ப்பு மூன்று: அது உறங்கியிருந்தால், அது வேண்டுமென்றே நடந்ததா என முடிவு செய்யுங்கள்
நேரக்கோட்டில் உறக்க மாற்றம் தோன்றியதும், கேள்வி «VPN ஏன் உடைந்தது» என்பதிலிருந்து «இயந்திரம் உண்மையில் உறங்க வேண்டியிருந்ததா» என்பதற்கு மாறுகிறது. மடிக்கணினியில் பதில் பெரும்பாலும் ஆம், சுரங்கப்பாதை துண்டிப்பு என்பது வாடிக்கையாளர் விழிக்கும்போது மீள வேண்டிய எதிர்பார்க்கப்பட்ட நடத்தை. அணுகக்கூடியதாக இருக்க வேண்டிய பணிநிலையத்தில் மாற்ற வேண்டியது உறக்கக் கொள்கையே. இந்த இரண்டு இயந்திரங்களில் எதைப் பார்க்கிறீர்கள் என்பதை முடிவு செய்ய ஒரு கேள்வி தேவை, அது பதிவு உங்கள் சார்பாகப் பதிலளிக்கக்கூடிய கேள்வி அல்ல.
உள்நுழைந்த அமர்வுக்குச் சொந்தமான கட்டுப்பாடுகள் வழியாகவோ, தேவை முழு இயந்திரத்திற்கும் என்றால் நிர்வாகி ஆதரிக்கும் முறை வழியாகவோ அதை மாற்றுங்கள். வேறு கணக்கில் உள்நுழைந்திருக்கும்போது காட்சி மேலாளரின் அமைப்பைத் திருத்துவது அதே செயல் அல்ல, அடுத்த அமர்வு தொடங்கும் வரை அது வேலை செய்ததுபோல் தெரியும். மின் மேலாண்மையை முழுமையாக முடக்குவது மின்கல ஆயுளைச் செலவழிக்கும், உண்மையான கொள்கைக் கேள்வியை மறைக்கும் பரந்த முதல் எதிர்வினை.
சரிபார்ப்பு நான்கு: அது விழித்திருந்தால், வலையையும் வாடிக்கையாளரையும் பாருங்கள்
தன் சுரங்கப்பாதையை இழந்த விழித்திருக்கும் இயந்திரத்திற்கு மூன்று கதைகளில் ஒன்று உண்டு: அணுகல் வலையம் வீழ்ந்தது, VPN வாடிக்கையாளர் நின்றது அல்லது மீண்டும் தொடங்கியது, அல்லது சேவையகப் பக்கம் இணைப்பைக் காலாவதியாக அனுமதித்தது, வாடிக்கையாளர் இன்னும் இணைந்திருப்பதாக நம்பிக்கொண்டிருந்தது. அடிப்படை இணைப்பு நிகழ்வின் நேரமுத்திரைகளைச் சுரங்கப்பாதை நிகழ்வுடன் ஒப்பிடுங்கள், எது முதலில் வந்தது என்பதில் துல்லியமாக இருங்கள்.
பின்னர் அசல் அமர்விலிருந்து தனியாக மீட்புப் பாதையைச் சோதியுங்கள். மீட்கப்பட்ட சுரங்கப்பாதை வழியாகப் புதிய கோரிக்கை வெற்றியடையலாம், ஆனால் துண்டிப்புக்கு முன் திறக்கப்பட்ட நீண்டகாலப் பயன்பாட்டு அமர்வு உடைந்தே இருக்கும், ஏனெனில் பயன்பாடு பழைய சாக்கெட்டையோ தேக்ககப்படுத்தப்பட்ட முகவரியையோ வைத்திருக்கிறது. அது பயன்பாட்டின் சிக்கல், சுரங்கப்பாதை திரும்பி வரவில்லை என்பதற்கான சான்று அல்ல.
பயனுள்ள அறிக்கையில் என்ன இருக்கும்
நேரமுத்திரைகள் மற்றும் உரிமையாளர்களுடன் வரிசையை எழுதுங்கள்: அமர்வு எப்போது பூட்டப்பட்டது, திரை எப்போது இருட்டியது, உறக்கக் கோரிக்கை பதிவானதா, இணைப்பு எப்போது வீழ்ந்து திரும்பியது, சுரங்கப்பாதை எப்போது நிலையை மாற்றியது, பயன்பாடு உண்மையில் என்ன செய்தது. ஒவ்வொரு உருப்படிக்கும் ஒரு உரிமையாளர் உண்டு, எனவே ஒவ்வொரு உருப்படியையும் Linux பற்றிய பொதுவான புகாராக மாற்றுவதற்குப் பதிலாக சரியான நபரிடம் ஒப்படைக்கலாம்.
இந்த வரிகளில் ஏதேனும் இல்லை என்றால், அது அடுத்ததாக அளவிட வேண்டியது, அடுத்ததாக மாற்ற வேண்டியது அல்ல. இடைவெளி உள்ள நேரக்கோடு ஊகத்தின் அடிப்படையில் செய்யப்பட்ட அமைப்பு மாற்றத்தை விட அதிக தகவல் தருகிறது.