VPN കിൽ സ്വിച്ച് റീബൂട്ടിന് ശേഷം നിലനിൽക്കുമോ? അത് എങ്ങനെ പരിശോധിക്കാം

റീബൂട്ട് ചെയ്യുന്നത് ആളുകൾ കിൽ സ്വിച്ച് പരീക്ഷിക്കുന്ന ഏറ്റവും സാധാരണ മാർഗമാണ്, ഏറ്റവും കൂടുതൽ നുണ പറയുന്ന പരീക്ഷയും അതുതന്നെ. ക്ലയന്റിലെ ചെക്ക്ബോക്സ് ഒരു മുൻഗണന മാത്രമാണ്; നെറ്റ്വർക്ക് സ്റ്റാക്ക് മുകളിലേക്ക് വരുന്ന നിമിഷവും ടണൽ യഥാർത്ഥത്തിൽ സ്ഥാപിക്കുന്ന നിമിഷവും തമ്മിൽ എന്തെങ്കിലും ബ്ലോക്ക് അടിച്ചേൽപ്പിക്കുന്നുണ്ടോ എന്നതാണ് പ്രധാനം. Windows-ൽ അത് സാധാരണയായി Windows Filtering Platform-ലെ ഒരു ഫിൽട്ടർ, Linux-ൽ ഒരു യൂണിറ്റ് ലോഡ് ചെയ്യുന്ന നിയമക്കൂട്ടം, macOS-ൽ pf ആങ്കർ, Android-ൽ സിസ്റ്റത്തിന്റെ സ്വന്തം always-on ഉം ലോക്ക് ഡൗൺ ഫ്ലാഗുകളും ആണ്. ഈ ക്രമീകരണങ്ങൾ റീബൂട്ടിലുടനീളം വളരെ വ്യത്യസ്തമായി പെരുമാറുന്നു, പ്ലാറ്റ്ഫോം തലത്തിലുള്ളവ മാത്രമാണ് ആരെങ്കിലും സൈൻ ഇൻ ചെയ്യുന്നതിന് മുൻപ് സ്ഥാനത്തുള്ളത്.

റീബൂട്ട് മൂന്ന് വ്യത്യസ്ത ചോദ്യങ്ങൾ ഉന്നയിക്കുന്നു

ചോദ്യം വിഭജിക്കുക. ഒന്നാമതായി, ബൂട്ട് സമയത്ത് എന്തെങ്കിലും വായിക്കുന്ന രൂപത്തിൽ നയം ഡിസ്കിൽ ഉണ്ടോ? രണ്ടാമതായി, ഏതെങ്കിലും ട്രാഫിക് പുറത്തുപോകുന്നതിന് മുൻപ് ആ വായനക്കാരൻ പ്രവർത്തിക്കുന്നുണ്ടോ? മൂന്നാമതായി, നയം നിങ്ങൾക്ക് പ്രധാനമായ ട്രാഫിക് ഉൾക്കൊള്ളുന്നുണ്ടോ, അതായത് ഓരോ പ്രോസസും, രണ്ട് വിലാസ കുടുംബങ്ങളും 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 മറ്റൊരു വഴി സ്വീകരിക്കുന്നു, always-on VPN അടിച്ചേൽപ്പിച്ച് അതില്ലാത്ത കണക്ഷനുകൾ ആപ്പ് പ്രോസസിൽ നിന്നല്ല, സിസ്റ്റത്തിൽ നിന്ന് തടയുന്നു.

പരീക്ഷ പ്രവർത്തിപ്പിച്ച് രണ്ട് സമയരേഖകൾ താരതമ്യം ചെയ്യുക

ചോർന്നാലും ഒന്നും ചെലവാകാത്ത ഒരു ലക്ഷ്യസ്ഥാനത്തോടെ റീബൂട്ട് ചെയ്യുക, അവസ്ഥ വിടവിന് ശേഷമല്ല, വിടവിനിടയിൽ പകർത്തുക. ഏറ്റവും വ്യക്തമായ രീതി ബൂട്ട് സമയ പ്രോബ് ആണ്: പ്ലാറ്റ്ഫോം അനുവദിക്കുന്നത്ര നേരത്തെ തുടങ്ങുന്ന, ഡിഫോൾട്ട് റൂട്ടും ഫയർവാൾ അവസ്ഥയും രേഖപ്പെടുത്തുന്ന, ചെറിയ ടൈംഔട്ടോടെ ഒരു അഭ്യർത്ഥന ശ്രമിക്കുന്ന, പ്രാദേശിക ഫയലിൽ ഒരു വരി ചേർക്കുന്ന oneshot യൂണിറ്റ് അല്ലെങ്കിൽ ഷെഡ്യൂൾ ചെയ്ത ടാസ്ക്. ആ രേഖ journalctl -b -u അല്ലെങ്കിൽ സിസ്റ്റം ലോഗിൽ നിന്നുള്ള VPN സേവന തുടക്ക സമയവുമായി താരതമ്യം ചെയ്യുക.

പിന്നീട് സാധാരണ പരീക്ഷ നടത്തുക: ടണൽ മുകളിൽ, കണക്ഷൻ വിച്ഛേദിക്കുക, നേരിട്ടുള്ള ട്രാഫിക് തടയപ്പെടുന്നുണ്ടോ എന്ന് നോക്കുക, പുനഃസ്ഥാപിക്കുക. രണ്ടാമത്തേതിൽ വിജയിക്കുകയും ഒന്നാമത്തേതിൽ പരാജയപ്പെടുകയും ചെയ്യുന്നതാണ് സാധാരണ ഫലം, അതിന്റെ അർത്ഥം നിർവ്വഹണം ക്ലയന്റ് ഭാഗത്താണ്, ബൂട്ടിൽ അല്ല, ക്ലയന്റ് ബന്ധിപ്പിക്കുമ്പോൾ പ്രയോഗിക്കുന്നു. ഞാൻ അവസാനം ഓഡിറ്റ് ചെയ്ത മെഷീനിൽ, ബ്ലോക്ക് NetworkManager-ന്റെ ഡിസ്പാച്ചർ സ്ക്രിപ്റ്റിൽ നിന്നായിരുന്നു: നിലവിലുണ്ട്, ശരിയാണ്, എന്നാൽ ഇന്റർഫേസ് ഉയരുന്നതിന് മുൻപുള്ള സെക്കൻഡുകൾക്ക് ഉപയോഗശൂന്യം. രണ്ട് ഫലങ്ങളും എഴുതിവയ്ക്കുക, കാരണം റീബൂട്ട് അതിജീവിക്കുന്നു എന്നതിന് അർത്ഥമുണ്ടാകുന്നത് ഏത് പാളി ഏത് നിമിഷം മുതൽ അതിജീവിച്ചു എന്ന് നിങ്ങൾ പറയുമ്പോഴാണ്.

തിരിച്ചുവരവിന്റെ വഴി മുറിക്കാതെ വിടവ് അടയ്ക്കുക

ബൂട്ടിൽ ബ്ലോക്ക് ഇല്ലെങ്കിൽ, രണ്ടാമത്തെ ക്ലയന്റ് നിയമം ചേർക്കുന്നതിന് പകരം നിർവ്വഹണം ഒരു പാളി താഴേക്ക് മാറ്റുക. നിയമക്കൂട്ടം സംരക്ഷിച്ച് നെറ്റ്വർക്ക് ഉപയോഗയോഗ്യമാകുന്നതിന് മുൻപ് ക്രമീകരിച്ച ഒരു യൂണിറ്റിൽ നിന്ന് അത് ലോഡ് ചെയ്യുക, ആ യൂണിറ്റിന് അത് സംരക്ഷിക്കേണ്ട DNS അന്വേഷണമോ നെറ്റ്വർക്ക് മൗണ്ടോ ആവശ്യമില്ലെന്ന് ഉറപ്പാക്കുക. വ്യാപ്തി സമയത്തോളം തന്നെ പ്രധാനമാണ്: ഉപയോക്തൃ ഐഡിയോ cgroup-മോ പൊരുത്തപ്പെടുന്ന നിയമങ്ങൾ ഓരോ സിസ്റ്റം ഡീമണിനെയും ബ്ലോക്കിന് പുറത്ത് നിർത്തുന്നു, IPv4 മാത്രം കൈകാര്യം ചെയ്യുന്ന കൂട്ടം IPv6-ഉം DNS-ഉം എത്താവുന്നതായി നിർത്തുന്നു.

നിങ്ങൾക്കായി ഒരു തിരിച്ചുവരവ് വഴി വയ്ക്കുക. ബൂട്ടിൽ എല്ലാം തടഞ്ഞ് പിന്നീട് പ്രാമാണീകരിക്കാനാവാത്ത മെഷീന് നെറ്റ്വർക്കേയില്ല, പരിഹാരം ബ്ലോക്ക് മായ്ക്കലല്ല, ക്രെഡൻഷ്യലോ ക്രമമോ നന്നാക്കലാണ്. പ്രാദേശിക കൺസോളിനുള്ള രേഖപ്പെടുത്തിയ നടപടിക്രമവും ടണലിന് യഥാർത്ഥത്തിൽ വേണ്ടതിന് ഇടുങ്ങിയ, ബോധപൂർവമായ ഒരു ഒഴിവും സൂക്ഷിക്കുക, ഉദാഹരണത്തിന് സെർവർ വിലാസവും ടണൽ നിലവിലുകാകുന്നതിന് മുൻപ് ഉപയോഗിക്കുന്ന റിസോൾവറും.

ഈ ക്രമീകരണത്തിൽ വിശ്വസിക്കുന്നതിന് മുൻപ് നാല് കാര്യങ്ങൾ ക്രമത്തിൽ സ്ഥിരീകരിക്കുക. നയം ബൂട്ട് വായിക്കുന്നിടത്ത് സംഭരിച്ചിരിക്കുന്നു. ആ വായനക്കാരൻ ഇന്റർഫേസ് ഉപയോഗയോഗ്യമാകുന്നതിന് മുൻപ് പ്രവർത്തിക്കുന്നു. ബ്ലോക്ക് രണ്ട് വിലാസ കുടുംബങ്ങളെയും DNS-ഉം ഉൾക്കൊള്ളുന്നു. ബ്ലോക്ക് സജീവമായിരിക്കുമ്പോഴും VPN-ന് പ്രാമാണീകരിക്കാനാകും. നാലും ശരിയാകുമ്പോൾ, റീബൂട്ട് ഒന്നും മാറ്റുന്നില്ല.