VPN கில் சுவிட்ச் மறுதொடக்கத்திற்குப் பிறகு நீடிக்குமா? அதை எவ்வாறு சரிபார்ப்பது

மறுதொடக்கம் செய்வது மக்கள் கில் சுவிட்சைச் சோதிக்கும் மிகவும் பொதுவான வழி, அதுவே அதிகம் பொய் சொல்லும் சோதனை. கிளையண்டில் உள்ள தேர்வுப்பெட்டி ஒரு விருப்பம் மட்டுமே; நெட்வொர்க் ஸ்டாக் மேலெழும் தருணத்திற்கும் சுரங்கப்பாதை உண்மையில் நிறுவப்படும் தருணத்திற்கும் இடையே ஏதேனும் தடையை வலியுறுத்துகிறதா என்பதே முக்கியம். Windows இல் அந்த ஏதோ பொதுவாக Windows Filtering Platform இல் ஒரு வடிகட்டி, Linux இல் ஒரு யூனிட் ஏற்றும் விதித்தொகுப்பு, macOS இல் pf நங்கூரம், Android இல் கணினியின் சொந்த எப்போதும்-இயக்கத்தில் மற்றும் பூட்டுதல் கொடிகள். இந்த ஏற்பாடுகள் மறுதொடக்கம் முழுவதும் மிகவும் வேறுபட்டு நடந்துகொள்கின்றன, மேலும் தள்மட்ட ஏற்பாடுகள் மட்டுமே யாரும் உள்நுழைவதற்கு முன் அவற்றின் இடத்தில் இருக்கும்.

மறுதொடக்கம் மூன்று தனித்தனி கேள்விகளை முன்வைக்கிறது

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

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

தடையை மீட்டெடுக்கும் பொருளைக் கண்டறியுங்கள்

Linux இல் netfilter விதிகள் கர்னலில் வாழ்கின்றன. நீங்கள் ஏற்பாடு செய்யாவிட்டால் பூட்டின் போது எதுவும் அவற்றை மீண்டும் எழுதுவதில்லை: iptables-save உடன் netfilter-persistent, nftables.service ஏற்றுகிறது /etc/nftables.conf, அல்லது உங்கள் சொந்த ஸ்கிரிப்ட்டை இயக்கும் systemd யூனிட். எது இயக்கப்பட்டுள்ளது என்பதைப் பாருங்கள், நீங்கள் உள்ளமைத்ததாக நினைவிருப்பதை அல்ல.

systemctl is-enabled nftables netfilter-persistent 2>/dev/null
sudo nft list ruleset
sudo iptables -S OUTPUT

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

Get-Service | Where-Object { $_.Name -match 'vpn' } | Select-Object Name, Status, StartType
netsh wfp show state

இரண்டாவது கட்டளை wfpstate.xml ஐ தற்போதைய அடைவில் எழுதுகிறது. கிளையண்ட் இணைவதற்கு முன்பே இருக்கும் தடுப்பு செயலுடன் கூடிய வடிகட்டிகளைத் தேடுங்கள். Base Filtering Engine பூட்டின் தொடக்கத்திலேயே தொடங்கி நிலையான கொடியுடன் சேர்க்கப்பட்ட வடிகட்டிகளை மீட்டெடுக்கிறது, அதனால்தான் சில கில் சுவிட்சுகள் கிளையண்ட் சாளரம் ஏதும் இல்லாமலேயே போக்குவரத்தைத் தடுக்கின்றன, மற்றவை தடுப்பதில்லை. macOS இல் sudo pfctl -s info pf இயக்கப்பட்டுள்ளதா எனத் தெரிவிக்கிறது, sudo pfctl -s rules எது ஏற்றப்பட்டுள்ளது எனக் காட்டுகிறது, VPN கிளையண்டுகள் பொதுவாக தங்கள் விதிகளை பிரதான தொகுப்புக்கு அல்ல, நங்கூரத்தில் இணைக்கின்றன. utun3 எனப் பெயரிடும் விதி அடுத்த பூட்டிற்குப் பின் வேறு இடைமுகத்தைச் சுட்டலாம், ஏனெனில் அந்த எண் இயக்க நேரத்தில் வழங்கப்படுகிறது.

நெட்வொர்க் மேலெழுவதற்கும் சுரங்கப்பாதை மேலெழுவதற்கும் இடையிலான இடைவெளியைக் கவனியுங்கள்

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

systemd புரவலர்களில் ஊகிக்காமல் வரிசையைப் படியுங்கள். VPN மற்றும் ஃபயர்வால் யூனிட்களில் systemctl cat ஐ இயக்கி After= மற்றும் Before= உடன் network-pre.target அல்லது network-online.target இருக்கிறதா எனப் பாருங்கள். network-online.target க்குப் பின் வரிசைப்படுத்தப்பட்ட ஃபயர்வால் யூனிட் இடைமுகத்திடம் தோற்கிறது; network-pre.target கோரி அதற்கு முன் வரிசைப்படுத்தப்பட்ட யூனிட் வெல்கிறது. Windows இல் சமமான கேள்விகள் சேவையின் தொடக்க வகை மற்றும் அதன் சார்புகள், ஏனெனில் Manual இல் அமைக்கப்பட்ட சேவை பூட்டு நேர செயல்முறையைத் தடுக்க முடியாது. உங்கள் தேவையில் உள்நுழைவுக்கு முந்தைய போக்குவரத்தும் அடங்கினால், சாதன மட்ட ஏற்பாடு மட்டுமே அதை நிறைவேற்றும்: Always On VPN சாதன சுரங்கப்பாதை இயந்திரச் சான்றிதழுடன் அங்கீகரித்து பயனர் உள்நுழைவதற்கு முன் இணைகிறது, மேலும் Microsoft சாதன சுரங்கப்பாதையின் உள்ளமைவை ஆவணப்படுத்துகிறது பயனர் சுரங்கப்பாதையிலிருந்து தனியாக. Android வேறு வழியை எடுக்கிறது, எப்போதும்-இயக்கத்தில் VPN ஐ வலியுறுத்தி அது இல்லாத இணைப்புகளை பயன்பாட்டு செயல்முறையிலிருந்து அல்ல, கணினியிலிருந்து தடுக்கிறது.

சோதனையை இயக்கி, பின்னர் இரண்டு நேரக் கோடுகளை ஒப்பிடுங்கள்

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

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

திரும்பும் வழியை முறிக்காமல் இடைவெளியை மூடுங்கள்

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

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

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