VPN വിച്ഛേദിച്ചതിന് ശേഷവും സംരക്ഷണ സ്വിച്ച് ട്രാഫിക് തടയുന്നു

സംരക്ഷണ സ്വിച്ചിന്റെ ഫിൽട്ടറുകളും drop നിയമങ്ങളും ക്ലയന്റിനേക്കാൾ കാലം നിലനിൽക്കുന്നു. Windows-ലെ WFP അവസ്ഥയും Linux-ലെ iptables നിയമങ്ങളും വായിച്ച്, ഏറ്റവും ഇടുങ്ങിയ വസ്തു നീക്കം ചെയ്ത്, അത് വീണ്ടും ഇടുന്ന ഉടമയെ കണ്ടെത്തുക.

ടണൽ പോയി, നെറ്റ്വർക്ക് ഐക്കൺ സാധാരണമായി കാണുന്നു, പക്ഷേ ഒന്നും ലോഡ് ആകുന്നില്ല. നിങ്ങൾ VPN വിച്ഛേദിച്ചു, അൺഇൻസ്റ്റാൾ ചെയ്തു, അല്ലെങ്കിൽ റീബൂട്ട് ചെയ്തു, എന്നിട്ടും കണക്ഷൻ വീഴുമ്പോൾ നിങ്ങളെ സംരക്ഷിക്കേണ്ടിയിരുന്ന ബ്ലോക്ക് ഇപ്പോഴും നിൽക്കുന്നു. ക്ലയന്റ് വിൻഡോ ഇത് വിശദീകരിക്കാനാകില്ല, കാരണം തടയുന്നത് ക്ലയന്റ് അല്ല: തീരുമാനം നിങ്ങളുടെ പേരിൽ കർണലിൽ എഴുതപ്പെട്ടു, അത് നീക്കാൻ ഒന്നും ബാക്കിയില്ല. Windows-ൽ ആ അവസ്ഥ Windows Filtering Platform-ൽ ആണ്; Linux-ൽ അത് iptables അല്ലെങ്കിൽ nftables-ലെ നിയമക്കൂട്ടമാണ്, പലപ്പോഴും ബൂട്ടിൽ വീണ്ടും പ്രയോഗിക്കുന്ന സ്നാപ്ഷോട്ടിനൊപ്പം. താഴെ പറയുന്നത് ഞാൻ ഉപയോഗിക്കുന്ന ക്രമമാണ്: അവസ്ഥ വായിക്കുക, പരാജയം വിശദീകരിക്കുന്ന ഏറ്റവും ഇടുങ്ങിയ വസ്തു നീക്കുക, പിന്നീട് അത് വീണ്ടും വീണ്ടും ഇടുന്നത് കണ്ടെത്തുക.

സംരക്ഷണ സ്വിച്ച് ഒരു ക്രമീകരണമല്ല, കർണൽ അവസ്ഥയാണ്

ഡെസ്ക്ടോപ്പ് ക്ലയന്റുകൾ ടണലിന് പുറത്തുള്ള ട്രാഫിക് നിരസിക്കുന്ന ഫിൽട്ടറുകൾ ചേർത്താണ് തടയൽ നടപ്പാക്കുന്നത്. Windows-ൽ അവ connect-redirect, transport പാളികളിലെ WFP ഫിൽട്ടറുകളാണ്, ചിലത് സ്ഥിരമാണ്: അവ Base Filtering Engine നയ സംഭരണിയിൽ രേഖപ്പെടുത്തി, ഏതെങ്കിലും VPN സോഫ്റ്റ്വെയർ പ്രവർത്തിക്കുന്നതിന് മുമ്പ് യന്ത്രം ബൂട്ട് ചെയ്യുമ്പോൾ പുനഃസ്ഥാപിക്കുന്നു. എപ്പോൾ വൃത്തിയാക്കുന്നു എന്നതിൽ ക്ലയന്റുകൾ വ്യത്യസ്തമാണ്. ചിലത് വിച്ഛേദിക്കുമ്പോൾ ഫിൽട്ടറുകൾ നീക്കുന്നു, ചിലത് ശുദ്ധമായ പുറത്തുകടക്കലിൽ മാത്രം, ചിലത് ആദ്യം സ്വിച്ച് ഓഫ് ചെയ്താൽ മാത്രം. ബ്ലോക്ക് സജീവമായിരിക്കുമ്പോൾ അൺഇൻസ്റ്റാൾ ചെയ്യുക, അല്ലെങ്കിൽ പ്രോസസ് കൊല്ലുക, ഫിൽട്ടറുകൾ നിലനിൽക്കും.

Linux-ലെ തുല്യമായത് ഔട്ട്പുട്ട് പാതയിലെ drop അല്ലെങ്കിൽ reject നിയമമാണ്, ചിലപ്പോൾ forwarding നിയമം, ചിലപ്പോൾ മാറ്റിയ ചെയിൻ നയം. ആ നിയമങ്ങൾ ചേർത്ത പ്രോസസിനേക്കാൾ കാലം നിലനിൽക്കുന്നു, കാരണം അവ കർണൽ അവസ്ഥയാണ്: ക്ലയന്റ് കൊല്ലുകയോ ക്രാഷ് ചെയ്യിക്കുകയോ വൈദ്യുതി വിച്ഛേദിക്കുകയോ ചെയ്താലും കർണൽ പാക്കറ്റുകൾ ഉപേക്ഷിക്കുന്നത് തുടരും, അത് റദ്ദാക്കാൻ ഒന്നും ബാക്കിയില്ല. പെർസിസ്റ്റൻസ് പാക്കേജ് നിലവിലെ നിയമക്കൂട്ടത്തിന്റെ സ്നാപ്ഷോട്ട് എടുത്ത് ബൂട്ടിൽ പുനഃസ്ഥാപിച്ച് രണ്ടാമത്തെ സ്ഥിരതാ പാളി ചേർക്കുന്നു, അതിനാൽ അടുത്ത തുടക്കം ബ്ലോക്ക് ഇതിനകം ഇൻസ്റ്റാൾ ചെയ്ത അവസ്ഥയിൽ തുടങ്ങുന്നു.

എന്തെങ്കിലും നീക്കും മുമ്പ് 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 പാക്കറ്റ് കൗണ്ടറുകൾ ചേർക്കുന്നു, ആ കൗണ്ടറുകൾ നിയമം നിങ്ങളുടെ പരാജയപ്പെട്ട അഭ്യർത്ഥനകളുമായി യഥാർത്ഥത്തിൽ പൊരുത്തപ്പെടുന്നുണ്ടോ അതോ ചെയിനിൽ ഇരിക്കുകയാണോ എന്ന് പറയുന്നു.

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

നിയമങ്ങൾ മാത്രമല്ല, ചെയിൻ നയങ്ങളും വായിക്കുക: -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 ഇടുക. നിങ്ങൾ തിരിച്ചറിഞ്ഞ ഒരു നിയമം നീക്കുന്നത് ഒരു ചെയിൻ മുഴുവൻ ഒഴിവാക്കുന്നതിനേക്കാൾ നല്ലതാണ്, കാരണം നിങ്ങളുടെ സ്വന്തം നയം അതേപടി നിലനിൽക്കും.

sudo iptables -D OUTPUT -p udp -j REJECT

drop ഉപയോക്തൃ-നിർവചിത ചെയിനിലാണെങ്കിൽ, ആദ്യം ആ ചെയിനിലേക്കുള്ള ജംപ് നീക്കുക, പിന്നീട് -X ഉപയോഗിച്ച് ചെയിൻ നീക്കം ചെയ്യുക. drop നിയമങ്ങൾ ഇപ്പോഴും ഉള്ളപ്പോൾ ചെയിൻ നയം ACCEPT ആക്കുന്നത് നയ തീരുമാനത്തിൽ എത്തുന്ന പാക്കറ്റുകൾക്ക് മാത്രമേ സഹായിക്കൂ. എല്ലാ ടേബിളുകളും ഒഴിവാക്കുന്നത് അവസാന മാർഗമാണ്: അത് മറ്റ് കാരണങ്ങളാൽ ചേർത്ത നിയമങ്ങളും നീക്കും, ufw സജീവമാണെങ്കിൽ സേവനം ഇനി ഇല്ലാത്ത ചെയിനുകൾ തന്റേതാണെന്ന് കരുതാൻ ഇടയാക്കും.

അത് വീണ്ടും ഇടുന്ന ഉടമയെ കണ്ടെത്തുക

ഉടനടിയുള്ള നന്നാക്കലിന് ശേഷം അവസ്ഥ പുനഃസ്ഥാപിക്കുന്നത് തിരയുക. Linux-ൽ പെർസിസ്റ്റൻസ് യൂണിറ്റ് സജീവമാണോ, ക്ലയന്റിന് ലോഗിനിൽ ഫയർവാൾ പുനഃസ്ഥാപിക്കുന്ന ക്രമീകരണമുണ്ടോ, /etc-ന് കീഴിൽ സേവ് ചെയ്ത നിയമ ഫയൽ ഉണ്ടോ എന്ന് പരിശോധിക്കുക. Windows-ൽ സ്റ്റാർട്ടപ്പ് എൻട്രികൾ, സേവനങ്ങൾ, ഷെഡ്യൂൾ ചെയ്ത ജോലികൾ എന്നിവ വീണ്ടും പരിശോധിച്ച്, റീബൂട്ട് ചെയ്ത് മുമ്പത്തെ അതേ കമാൻഡുകളിൽ അവസ്ഥ വീണ്ടും വായിക്കുക.

ബ്ലോക്ക് തിരികെ വന്നാൽ, നീക്കം ചെയ്യലായിരുന്നില്ല പരിഹാരം; ഉടമയായിരുന്നു. ഏത് ക്ലയന്റോ സേവനമോ അത് ഇൻസ്റ്റാൾ ചെയ്യുന്നു എന്ന് രേഖപ്പെടുത്തി അവിടെ ഫീച്ചർ നിർജ്ജീവമാക്കുക, ഓരോ വിച്ഛേദനത്തിനും ശേഷം ഫയർവാൾ പാളിയിൽ പോരാടുന്നതിന് പകരം.

ഒരു ping അല്ല, യഥാർത്ഥ ട്രാഫിക് കൊണ്ട് പരിശോധിക്കുക

നാമം നിർണ്ണയം, TCP കണക്ഷൻ, പുതിയ ബ്രൗസർ സെഷൻ എന്നിവ പരീക്ഷിച്ച്, റീബൂട്ട് ചെയ്ത് അതേ മൂന്ന് പരിശോധനകൾ ആവർത്തിക്കുക. HTTPS പരാജയപ്പെടുമ്പോൾ ping പ്രവർത്തിക്കുന്നെങ്കിൽ അത് നെറ്റ്വർക്കിനെയല്ല, transport പാളിയിലെ ഫിൽട്ടറിനെ സൂചിപ്പിക്കുന്നു; റീബൂട്ടിന് ശേഷം മാത്രം വീണ്ടും പ്രത്യക്ഷപ്പെടുന്ന ബ്ലോക്ക് നിങ്ങൾ ഇതുവരെ കണ്ടെത്താത്ത ഉടമയെ സൂചിപ്പിക്കുന്നു.

തെളിവ് സൂക്ഷിക്കുക: എക്സ്പോർട്ട് ചെയ്ത BFE കീ, അല്ലെങ്കിൽ മാറ്റത്തിന് മുമ്പ് പിടിച്ചെടുത്ത iptables -S ഔട്ട്പുട്ട്. നന്നാക്കിയെന്ന് പറയുന്നതിന് മുമ്പ്, വസ്തു ഏത് പാളിയിൽ നിന്ന് നീക്കി, അത് വീണ്ടും ഇൻസ്റ്റാൾ ചെയ്യാനാകുന്ന ഉടമ ആര്, ഒരു ശുദ്ധ റീബൂട്ടിന് ശേഷമുള്ള അവസ്ഥ, VPN പ്രോസസ് പ്രവർത്തിക്കാതെ സാധാരണ ബ്രൗസിംഗ് പ്രവർത്തിക്കുന്നു എന്നിവ സ്ഥിരീകരിക്കുക. iptables(8) മാനുവൽ പേജിൽ ക്ലീനപ്പ് സ്ക്രിപ്റ്റ് ചെയ്യുകയാണെങ്കിൽ കൃത്യമായ നീക്കം ചെയ്യലും നയ വാക്യഘടനയും ഉണ്ട്.

അനുബന്ധ ലേഖനങ്ങൾ