சுரங்கப்பாதை போய்விட்டது, பிணையச் சின்னம் சாதாரணமாகத் தெரிகிறது, எதுவும் ஏற்றப்படவில்லை. நீங்கள் VPN ஐத் துண்டித்தீர்கள், நீக்கினீர்கள் அல்லது மறுதொடக்கம் செய்தீர்கள், இணைப்பு அறுபடும்போது உங்களைப் பாதுகாக்க வேண்டிய தடை இன்னும் நிற்கிறது. வாடிக்கையாளர் சாளரம் இதை விளக்க முடியாது, ஏனெனில் உங்களைத் தடுப்பது வாடிக்கையாளர் அல்ல: முடிவு உங்கள் பெயரில் கர்னலில் எழுதப்பட்டது, அதை அகற்ற எதுவும் மீதமில்லை. Windows இல் அந்த நிலை Windows Filtering Platform இல் உள்ளது; Linux இல் அது iptables அல்லது nftables இல் உள்ள விதிகளின் தொகுப்பு, பெரும்பாலும் துவக்கத்தில் மீண்டும் பயன்படுத்தப்படும் ஸ்னாப்ஷாட்டுடன். பின்வருபவை நான் பயன்படுத்தும் வரிசை: நிலையைப் படி, தோல்வியை விளக்கும் மிகக் குறுகிய பொருளை நீக்கு, பின்னர் அதைத் தொடர்ந்து திரும்ப வைப்பதைக் கண்டறி.

பாதுகாப்பு சுவிட்ச் என்பது ஒரு அமைப்பு அல்ல, கர்னல் நிலை

டெஸ்க்டாப் வாடிக்கையாளர்கள் சுரங்கப்பாதைக்கு வெளியேயான இயக்கத்தை மறுக்கும் வடிகட்டிகளைச் சேர்ப்பதன் மூலம் தடுப்பைச் செயல்படுத்துகின்றனர். Windows இல் அவை connect-redirect மற்றும் transport அடுக்குகளில் உள்ள WFP வடிகட்டிகள், சில நிரந்தரமானவை: அவை Base Filtering Engine கொள்கைக் கிடங்கில் பதிவாகி, எந்த VPN மென்பொருளும் இயங்குவதற்கு முன் இயந்திரம் துவங்கும்போது மீட்டமைக்கப்படுகின்றன. வாடிக்கையாளர்கள் எப்போது சுத்தம் செய்கிறார்கள் என்பதில் வேறுபடுகிறார்கள். சில இணைப்புத் துண்டிப்பில் வடிகட்டிகளை அகற்றும், சில தூய வெளியேற்றத்தில் மட்டும், மேலும் சில முதலில் சுவிட்சை அணைத்தால் மட்டும். தடை செயலில் இருக்கும்போது நீக்கவும், அல்லது செயல்முறையைக் கொல்லுங்கள், வடிகட்டிகள் இருக்கும்.

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

எதையும் நீக்கும் முன் WFP நிலையைப் படியுங்கள்

Windows தேவையான கருவிகளுடன் வருகிறது. நிர்வாகி ப்ராம்ப்ட்டை இயக்கி தளத்தின் நிலையை டம்ப் செய்யுங்கள்; டம்ப் வேலை அடைவில் wfpstate.xml ஆக வரும்.

netsh wfp show state
netsh wfp show filters
Get-Service bfe

XML இல் வெளியேறிய விற்பனையாளரின் பெயர், Block செயல் மற்றும் அடுக்கைத் தேடுங்கள். சாதாரண இயக்கத்தை உடைப்பவை connect-redirect மற்றும் transport வடிகட்டிகள்; receive-accept அடுக்கின் வடிகட்டி பொதுவாக உங்கள் காரணம் அல்ல. Base Filtering Engine இயங்கவே இல்லை என்றால் வேறு இடத்தில் பாருங்கள், ஏனெனில் அந்த வடிகட்டிகளை வேறு எதுவும் செயல்படுத்த முடியாது.

சாதாரண ஃபயர்வால் பார்வையையும் சரிபார்க்கவும், ஏனெனில் பெரும்பாலோர் இரண்டில் ஒன்றை மட்டுமே பார்க்கிறார்கள்:

netsh advfirewall show allprofiles
Get-NetFirewallProfile | Select-Object Name,Enabled,DefaultInboundAction

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

நீக்கப் போகும் தொடரியலில் Linux விதிகளைப் படியுங்கள்

iptables -S விதிகளைச் சேர்த்த அதே வடிவத்தில் அச்சிடுகிறது, எனவே வெளியீட்டை நீக்குதலுக்கு நேரடியாக மீண்டும் பயன்படுத்தலாம். iptables -L -v -n பொதி எண்ணிகளைச் சேர்க்கிறது, அந்த எண்ணிகள் விதி உங்கள் தோல்வியடைந்த கோரிக்கைகளுடன் உண்மையில் பொருந்துகிறதா அல்லது chain இல் சும்மா அமர்ந்திருக்கிறதா என்பதைச் சொல்கின்றன.

sudo iptables -S
sudo ip6tables -S
sudo iptables -t nat -S

விதிகளை மட்டுமல்ல, chain கொள்கைகளையும் படியுங்கள்: -P OUTPUT DROP எந்த விதியும் பொருந்தாவிட்டாலும் இயக்கத்தைத் தடுக்கிறது. IPv6 ஐத் தனியாகப் பாருங்கள், ஏனெனில் இரண்டு குடும்பங்களையும் நிறுவும் வாடிக்கையாளர் IPv4 விதிகள் போன பிறகும் IPv6 தடையை வைத்திருக்கலாம், அப்போது அறிகுறி எந்தக் குடும்பத்திற்கு பயன்பாடு முன்னுரிமை தருகிறது என்பதைப் பொறுத்தது. nftables பயன்படுத்தப்படும் இடத்தில் nft list ruleset ஐயும் இயக்குங்கள்; இரண்டு கருவிகளும் இணக்க அடுக்கு வழியாக ஒன்றாக வாழ்கின்றன, ஒரு பட்டியல் பொதியை வீழ்த்தக்கூடிய ஒவ்வொரு விதியையும் காட்ட வேண்டியதில்லை.

தோல்வியை விளக்கும் மிகக் குறுகிய பொருளை நீக்குங்கள்

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

Get-ScheduledTask | Where-Object TaskName -like '*vpn*'
Get-Service | Where-Object DisplayName -like '*vpn*'

நிரந்தர வடிகட்டிகள் கடைசி வழி. அவை HKLM\SYSTEM\CurrentControlSet\Services\BFE\Parameters\Policy\Persistent\Filter கீழ் உள்ளன, ஒவ்வொரு வடிகட்டிக்கும் GUID மூலம் விசையிடப்பட்ட ஒரு மதிப்பு. முதலில் விசையை ஏற்றுமதி செய்யுங்கள், நீக்கும் GUID களைப் பதிவு செய்யுங்கள், போன வாடிக்கையாளருக்குச் சொந்தமான மதிப்புகளை மட்டும் நீக்குங்கள், பின்னர் என்ஜின் அதன் நிலையை மீண்டும் கட்டமைக்க மறுதொடக்கம் செய்யுங்கள். முழு விசையையும் நீக்க வேண்டாம், Base Filtering Engine ஐ முடக்க வேண்டாம்: Windows Firewall மற்றும் Defender அதைச் சார்ந்துள்ளன, ஒரு இடையூறை இன்னும் மோசமான ஒன்றுடன் மாற்றுவீர்கள்.

reg export "HKLM\SYSTEM\CurrentControlSet\Services\BFE\Parameters\Policy\Persistent" C:\temp\bfe-backup.reg

Linux இல் iptables -S அச்சிட்ட வரியை எடுத்து -A க்கு பதிலாக -D இடுங்கள். நீங்கள் அடையாளம் கண்ட ஒரே விதியை நீக்குவது chain ஐ காலி செய்வதை விட மேலானது, ஏனெனில் உங்கள் சொந்தக் கொள்கை அப்படியே இருக்கும்.

sudo iptables -D OUTPUT -p udp -j REJECT

drop பயனர் வரையறுத்த chain இல் இருந்தால், முதலில் அந்த chain க்கான தாவலை நீக்கி, பின்னர் -X மூலம் chain ஐ அகற்றுங்கள். drop விதிகள் இன்னும் இருக்கும்போது chain கொள்கையை ACCEPT ஆக்குவது கொள்கை முடிவை அடையும் பொதிகளுக்கு மட்டுமே உதவும். ஒவ்வொரு அட்டவணையையும் காலி செய்வது கடைசி வழி: வேறு காரணங்களுக்காகச் சேர்த்த விதிகளையும் அகற்றும், ufw இயக்கத்தில் இருந்தால் சேவை இனி இல்லாத chain களைத் தனக்குச் சொந்தமென நினைக்க வைக்கும்.

அதைத் திரும்ப வைக்கும் உரிமையாளரைக் கண்டறியுங்கள்

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

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

ஒரு ping அல்ல, உண்மையான இயக்கத்தால் சரிபார்க்கவும்

பெயர் தீர்வு, TCP இணைப்பு மற்றும் புதிய உலாவி அமர்வைச் சோதித்து, பின்னர் மறுதொடக்கம் செய்து அதே மூன்று சோதனைகளை மீண்டும் செய்யுங்கள். HTTPS தோல்வியடையும்போது ping வேலை செய்தால் அது பிணையத்திற்கு அல்ல, transport அடுக்கின் வடிகட்டிக்கு சுட்டுகிறது; மறுதொடக்கத்திற்குப் பிறகு மட்டும் மீண்டும் தோன்றும் தடை நீங்கள் இன்னும் கண்டறியாத உரிமையாளரைச் சுட்டுகிறது.

ஆதாரங்களை வைத்திருங்கள்: ஏற்றுமதி செய்த BFE விசை, அல்லது மாற்றத்திற்கு முன் பிடிக்கப்பட்ட iptables -S வெளியீடு. சரிசெய்யப்பட்டது என்று சொல்வதற்கு முன், பொருளை எந்த அடுக்கிலிருந்து நீக்கினீர்கள், அதை மீண்டும் நிறுவக்கூடிய உரிமையாளர் யார், ஒரு தூய மறுதொடக்கத்திற்குப் பிறகு நிலை, மற்றும் VPN செயல்முறை இயங்காமல் சாதாரண உலாவல் வேலை செய்கிறது என்பதை உறுதிப்படுத்துங்கள். iptables(8) கையேட்டுப் பக்கத்தில் சுத்தம் செய்வதை ஸ்கிரிப்ட் செய்தால் சரியான நீக்குதல் மற்றும் கொள்கை தொடரியல் உள்ளது.

தொடர்புடைய கட்டுரைகள்