ஒரு தூக்க hook மட்டும் VPN-ஐ திரும்பக் கொண்டுவராது

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

பூஜ்ஜியத்துடன் வெளியேறும் ஸ்கிரிப்ட் ஒரு சுரங்கப்பாதை திரும்பியதா என்பது பற்றி உங்களுக்கு எதுவும் சொல்லவில்லை.

hook இயங்குகிறது, பிறகு என்ன?

#!/bin/sh
case "$1" in
  pre)
    vpn-client disconnect
    ;;
  post)
    vpn-client connect
    ;;
esac

ஒவ்வொரு நிகழ்வும் hook-ஐ இரண்டு முறை அழைக்கிறது — மாற்றத்திற்கு முன்னும் பின்னும் — மற்றும் அதற்கு கட்டத்தையும் நிகழ்வின் பெயரையும் தருகிறது. இது root ஆக குறைந்தபட்ச சூழலில் இயங்குகிறது, எனவே முழுமையான பாதைகள் தேவை, டெஸ்க்டாப் அமர்வு மாறி எதிர்பார்க்கப்படக்கூடாது. இரண்டு அழைப்புகளும் விரைவாகத் திரும்புவது ஸ்கிரிப்ட் இயங்கியது என்று மட்டுமே சொல்கிறது. பிறகு சுயவிவரம் மேலே வந்ததா என்பது தனி கவனிப்பு, log-இல் அதற்கான சொந்த ஆதாரம் தேவை.

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

Root, குறைந்தபட்ச சூழல், தவறான பயனர்

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

hook-ஐ முழுமையான பாதைகளுடன் எழுதுங்கள், அதை root உரிமையிலும் இயக்கக்கூடியதாகவும் வைத்திருங்கள், அது என்ன செய்தது என்பதை log செய்யுங்கள். அந்த log இல்லாமல் அடுத்த விசாரணை பூஜ்ஜியத்திலிருந்து தொடங்குகிறது.

தானியங்கி இணைப்பு VPN பாதை அல்ல

NetworkManager இரண்டு செயல்படுத்தும் வழிமுறைகளை வழங்குகிறது: சுயவிவரத்தில் தானியங்கி இணைப்புக் கொடி, மற்றும் முதன்மை சுயவிவரம் செயல்படுத்தப்படும்போது தொடங்கும் இரண்டாம் நிலை இணைப்புகள். உள்ளூர் சாதன வகைகள் முதலாவதைச் செயல்படுத்துகின்றன; VPN செருகுநிரல்கள் வரலாற்று ரீதியாக இரண்டாவதை மட்டுமே செயல்படுத்தியுள்ளன, எனவே OpenVPN சுயவிவரத்தில் தானியங்கி இணைப்பைத் தேர்ந்தெடுப்பது எந்த விளைவையும் ஏற்படுத்தாமல் இருக்கலாம். இரண்டு பண்புகளையும் பரிசோதித்து, பிறகு VPN-ஐ Wi-Fi அல்லது Ethernet சுயவிவரத்தின் இரண்டாம் நிலையாக இணைக்கவும்.

[Unit]
PartOf=NetworkManager.service
Requires=NetworkManager-wait-online.service
After=NetworkManager-wait-online.service

systemd அலகால் நிர்வகிக்கப்படும் WireGuard இடைமுகத்திற்கு hook-க்கு பதிலாக அந்த drop-in தேவை, நெட்வொர்க் ஆன்லைனுக்கு வந்த பிறகு வரிசைப்படுத்தப்பட்டது.

நெட்வொர்க்கிற்காகக் காத்திருங்கள், ஒரு வரம்புடன்

timer=1
while ! ping -c1 -n -w1 203.0.113.1 >/dev/null; do
  sleep 1; timer=$((timer+1))
  [ $timer -ge 300 ] && exit 0
done
nmcli connection up "work-vpn"

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

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

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