iPhone இல் Always On VPN vs VPN On Demand: எதைப் பயன்படுத்த வேண்டும்

இரண்டு iPhone-களும் VPN என்று சொல்லலாம், ஆனால் முற்றிலும் வேறுபட்டு நடந்துகொள்ளலாம். ஒரு விதி பொருந்தும்போது On Demand சுரங்கப்பாதையைத் திறக்கிறது, பயனர் இன்னும் அமைப்புகளில் அதை அணைக்க முடியும். நிர்வகிக்கப்படும் Always On, சுரங்கப்பாதை எழ முடியாத தருணங்கள் உட்பட, கண்காணிக்கப்பட்ட சாதனத்தில் பாதுகாப்பை நிலைநிறுத்துகிறது. பயனர் எதுவும் செய்யாதபோது எது உண்மையாக இருக்க வேண்டும் என்று கேட்டுத் தேர்ந்தெடுக்கவும், பின்னர் நிலையான நிலையை அல்ல, மாற்றங்களைச் சோதிக்கவும். கீழே உள்ள படிகள் ஒரு பயன்பாடு உண்மையில் தோல்வியடையும் வரிசையில் செல்கின்றன.

படி 1: சாதனம் எதை நிலைநிறுத்த முடியும் என்பதை உறுதிப்படுத்துங்கள்

Always On என்பது கண்காணிக்கப்பட்ட சாதனத்தின் அம்சம். குழு கண்காணிக்கப்படவில்லை என்றால், விவாதம் தொடங்குவதற்கு முன்பே முடிந்துவிடும், எந்த payload விசையும் கண்காணிக்கப்படாத தொலைபேசியை கட்டாயமானதாக மாற்றாது. நிர்வாகப் பக்கத்திலிருந்தும் சாதனத்திலிருந்தும் கண்காணிப்பை உறுதிப்படுத்தி, பின்னர் சுயவிவரத்தை யார் கையொப்பமிட்டார் என்பதை உறுதிப்படுத்துங்கள்.

தொலைபேசியில் அமைப்புகள், பின்னர் பொது, பின்னர் VPN மற்றும் சாதன நிர்வாகம் திறக்கவும். சுயவிவரப் பதிவு அதன் உரிமையாளரைக் குறிப்பிடுகிறது, கைமுறையாக நிறுவப்பட்ட தனிப்பட்ட சுயவிவரம் நிர்வாகச் சேவையால் வழங்கப்பட்ட ஒன்றிலிருந்து வேறுபட்டு தெரிகிறது. சுயவிவரத்தின் பெயரிலிருந்தோ வழங்குநரின் சந்தைப்படுத்தல் லேபிளிலிருந்தோ கட்டாயத்தை ஊகிக்க வேண்டாம்; லேபிள் தளத்தின் கொள்கை அல்ல.

கட்டமைப்பைத் தொடுவதற்கு முன் மூன்று உண்மைகளை எழுதுங்கள்: கண்காணிக்கப்படுகிறதா இல்லையா, நிர்வகிக்கப்பட்ட சுயவிவரமா தனிப்பட்டதா, எந்த கிளையண்ட் செயலாக்கம் சுரங்கப்பாதையைச் சுமக்கிறது. அடுத்த ஒவ்வொரு படியும் அந்த மூன்றைச் சார்ந்தது, தனிப்பட்ட தொலைபேசியின் நடத்தையை நிர்வகிக்கப்பட்ட சுயவிவரத்திற்கு மாற்றுவதே தவறான அடிப்படையில் பயன்பாட்டை ஒப்புதல் செய்யும் வழி.

படி 2: அம்சத்தின் பெயரை அல்ல, on-demand விதிகளைப் படியுங்கள்

On Demand என்பது வரிசையாக மதிப்பிடப்படும் விதிகளின் பட்டியல். ஒவ்வொரு விதியும் ஒரு செயலையும் அதைத் தேர்ந்தெடுக்கும் நிபந்தனைகளையும் குறிப்பிடுகிறது, நிபந்தனைகளே சுவாரஸ்யமான பகுதி: இடைமுக வகை, Wi-Fi SSID, DNS டொமைன் பின்னொட்டு, அல்லது சோதனை URL. ஒருபோதும் பொருந்தாத விதித் தொகுப்பு ஒருபோதும் இணைக்காத அம்சமாகும்.

<key>OnDemandRules</key>
<array>
  <dict>
    <key>Action</key><string>EvaluateConnection</string>
    <key>InterfaceTypeMatch</key><string>WiFi</string>
    <key>SSIDMatch</key><array><string>Office-WiFi</string></array>
  </dict>
</array>

முழு வரிசையையும் படித்து ஒவ்வொரு விதிக்கும் இரண்டு கேள்விகளைக் கேளுங்கள்: இந்த நிபந்தனை இந்தக் குழுவில் எப்போதாவது உண்மையாக இருக்க முடியுமா, எந்த விதியும் பொருந்தாதபோது என்ன நடக்கிறது? நிறுவன வலைப்பிண்ணைகள் அணுகல் புள்ளிகளை மறுபெயரிடுகின்றன, SSID-களை இணைக்கின்றன, DNS பின்னொட்டுகளை மாற்றுகின்றன, அந்த மாற்றங்கள் ஒவ்வொன்றும் விதியை யதார்த்தத்திலிருந்து அமைதியாகப் பிரிக்கிறது.

DNS பின்னொட்டு நிபந்தனையே களத்தில் அடிக்கடி தவறாகும், ஏனெனில் விருந்தினர் வலைப்பிண்ணையில் தொலைபேசி தெரிவிக்கும் பின்னொட்டு நிறுவனத் தீர்வி வழங்கும் பின்னொட்டு அல்ல. விதியை நம்புவதற்கு முன் சாதனம் உண்மையில் தீர்க்கும் பெயரைச் சரிபார்க்கவும்.

படி 3: நிலையான இணைப்பை அல்ல, மாற்றங்களைச் சோதிக்கவும்

நீங்கள் பார்க்கும்போது இயங்கும் சுரங்கப்பாதை மிகக் குறைவையே நிரூபிக்கிறது. ஒவ்வொரு மாற்றத்தையும் வேண்டுமென்றே செய்யுங்கள் மற்றும் சாதனம் என்ன செய்கிறது என்பதைப் பதிவு செய்யுங்கள், முடிவுகள் ஒப்பிடக்கூடியதாக இருக்க ஒவ்வொரு முறையும் அதே தனிப்பட்ட வளத்தைப் பயன்படுத்துங்கள்:

• ஒரு விதி பொருந்த வேண்டிய வலைப்பிண்ணையில் இணைந்து, தனிப்பட்ட வளத்தைக் கோரி அது ஏற்றப்படுவதை உறுதிப்படுத்துங்கள்.
• செயலி பின்னணியில் இருக்கும்போது மொபைல் வலைப்பிண்ணைக்கு மாறி, பின்னர் முன்னணிக்குக் கொண்டு வந்து கோரிக்கையை மீண்டும் செய்யுங்கள்.
• captive portal உள்ள Wi-Fi-யில் இணைந்து, நுழைவாயிலை அணுக முடிகிறதா அல்லது அங்கீகரிக்கும் முன் நிலைநிறுத்தம் அனைத்தையும் தடுக்கிறதா எனப் பாருங்கள்.
• கண்காணிக்கப்பட்ட சாதனத்தில் சுரங்கப்பாதையை கைமுறையாக அணைத்து, அது தானாகத் திரும்புகிறதா, எவ்வளவு விரைவாக என்பதைச் சரிபார்க்கவும்.

கண்காணிக்கப்படாத சாதனம் இருந்தால் அதே பட்டியலை அதில் இயக்கவும். இரண்டு முடிவுகளுக்கு இடையிலான வேறுபாடே பயன்பாட்டின் உண்மையான நடத்தை, இணைக்கப்பட்ட சுரங்கப்பாதையின் திரைப்பிடிப்பு ஒருபோதும் காட்டாத பகுதி அதுவே.

படி 4: தோல்வியின் இரு வடிவங்களை அறியுங்கள்

கட்டாயப்படுத்தப்பட்ட பாதுகாப்பு தடுப்பதன் மூலம் தோல்வியடைகிறது. சுரங்கப்பாதையை நிறுவ முடியாதபோது, சாதனம் தனிப்பட்ட வளங்களுடன் சாதாரண இணைய அணுகலையும் இழக்கிறது, பயனர் ஆன்லைனில் இருக்கும் ஆனால் உலாவ முடியாத தொலைபேசியை அனுபவிக்கிறார். மீண்டும் இணைதலும் தடுப்பதும் தனித்தனி அவதானிப்புகள், எனவே இணையம் இல்லை என்பதை ஒரு அறிகுறியாகக் கருதாமல் இரண்டையும் பதிவு செய்யுங்கள்.

On Demand இயங்காமல் தோல்வியடைகிறது. விதி பொருந்தாது, சுரங்கப்பாதை தோன்றாது, தனிப்பட்ட வளம் வெறுமனே காலாவதியாகிறது. கிளையண்ட் கட்டமைக்கப்பட்டபடியே நடந்துகொள்வதால் இதை சேவையகப் பிரச்சினை என்று தவறாகக் கண்டறிவது எளிது.

captive portal இரண்டிற்கும் இடையில் உள்ளது: சுரங்கப்பாதை இருக்கும் முன் இணைப்பு தேவை, எனவே சுரங்கப்பாதை எழும் வரை அனைத்தையும் தடுக்கும் கொள்கைக்கு நுழைவாயில் வழியாக ஆவணப்படுத்தப்பட்ட பாதை தேவை. அதை வடிவமைப்பில் தீர்மானியுங்கள், உதவி மேசையில் அல்ல.

படி 5: சரிபார்த்து, பின்னர் பின்னோக்கிச் செல்வதைப் பயிற்சி செய்யுங்கள்

சரிபார்ப்பு பாதிப்பில்லாத போக்குவரத்துடன் உண்மையான பாதையில் இருக்க வேண்டும்: பொதுவானதாக இருக்கக் கூடாத தனிப்பட்ட வளத்தைக் கோருங்கள், சாதனம் வெளியே எந்த முகவரியைக் காட்டுகிறது என்பதை உறுதிப்படுத்துங்கள், மறுதொடக்கத்திற்குப் பிறகு மீண்டும் செய்யுங்கள்.

பின்னர் உற்பத்தியில் தேவைப்படுவதற்கு முன் சோதனைச் சாதனத்தில் அகற்றலைப் பயிற்சி செய்யுங்கள். சுயவிவரத்தை அகற்றுவது சாதனத்தை முந்தைய நிலைக்குத் திருப்புகிறது, எவ்வளவு நேரம் எடுக்கும், பயனர் என்ன பார்ப்பார் என்பதை அறிவது கையேட்டின் பகுதி. Apple-இன் VPN பாதுகாப்பு வழிகாட்டி இந்தக் கொள்கைகள் பற்றி தளம் ஆவணப்படுத்துவதற்கான குறிப்பு, தளம் சொல்வதை விட அதிகம் கூறும் கட்டமைப்பை எழுதுவதற்கு முன் அதைப் படிப்பது மதிப்புடையது.

முதல் படியின் மூன்று உண்மைகளையும் விதித் தொகுப்பு மற்றும் சோதனை முடிவுகளுடன் வைத்திருங்கள். ஒரு வலைப்பிண்ணையில் தொலைபேசி இணைகிறது, மற்றொன்றில் இல்லை ஏன் என்று அடுத்த நபர் கேட்கும்போது, அந்தக் குறிப்புகள் மீண்டும் கட்டுவதற்குப் பதிலாக ஒரு நிமிடத்தில் பதிலளிக்கும்.