ഫയർവാൾ പ്രൊഫൈലുകളും VPN ഇഗ്രസും: പൊതുവായത് എന്തുകൊണ്ട് പാതയല്ല
ഫയർവാൾ പ്രൊഫൈൽ ഏത് നിയമ കൂട്ടം ബാധകമാകുമെന്ന് തിരഞ്ഞെടുക്കുന്നു. പാക്കറ്റ് ഏത് ഇന്റർഫേസിലൂടെ പോയി എന്ന് അത് പറയുന്നില്ല, കൂടാതെ വ്യക്തമായ ബ്ലോക്ക് ഇടുങ്ങിയ അനുമതിയെ മറികടക്കുന്നു.
നിയമം കൃത്യമായി തോന്നുന്നു: സ്വകാര്യ പ്രൊഫൈലിൽ പ്രാദേശിക ട്രാഫിക്കിനും പൊതു പ്രൊഫൈലിൽ VPN ട്രാഫിക്കിനും മാത്രം അനുമതി നൽകുക. എന്നാൽ അങ്ങനെയല്ല, കാരണം നെറ്റ്‌വർക്ക് പ്രൊഫൈൽ ഏത് ഫയർവാൾ നിയമ കൂട്ടം ബാധകമാകുമെന്ന് തിരഞ്ഞെടുക്കുന്നു, പാക്കറ്റ് ഏത് അഡാപ്റ്റർ കൊണ്ടുപോയി എന്ന് പറയുന്നുമില്ല. പ്രൊഫൈലിന്റെ പേരിനെ പാതയുടെ ആവശ്യകതയായി കാണുന്നതാണ്, പരിമിതമായ ഇഗ്രസ് രൂപകൽപ്പനയെ യഥാർത്ഥത്തിൽ പൂർത്തിയാകാത്തപ്പോഴും പൂർത്തിയായതായി കാണിക്കുന്ന തെറ്റ്.
ആദ്യം പ്രവാഹങ്ങൾ എഴുതിവയ്ക്കുക, പിന്നീട് ഓരോന്നിനെയും യഥാർത്ഥത്തിൽ നടപ്പാക്കാൻ കഴിയുന്ന സംവിധാനം ഏതെന്ന് തീരുമാനിക്കുക. ആ പ്രവാഹ പട്ടിക മാത്രമാണ് അടുത്ത നിയമ മാറ്റത്തെ അതിജീവിക്കുന്ന ഏക കലാസൃഷ്ടി.
വിഭാഗം നിയമങ്ങൾ തിരഞ്ഞെടുക്കുന്നു, പാതകളല്ല
Windows ഒരു നെറ്റ്‌വർക്കിനെ പൊതുവായതോ സ്വകാര്യമോ ആയി തരംതിരിക്കുമ്പോൾ, ഫയർവാൾ ആ പ്രൊഫൈലിനായി ക്രമീകരിച്ച നിയമ കൂട്ടം പ്രയോഗിക്കുന്നു. തരംതിരിക്കൽ അഡാപ്റ്റർ ചേർന്ന നെറ്റ്‌വർക്കിനെ പിന്തുടരുന്നു, നിയമ കൂട്ടം അതിൽ എന്താണ് അനുവദനീയമെന്ന് തീരുമാനിക്കുന്നു. ഈ വസ്തുതകളൊന്നും ഒരു ആപ്ലിക്കേഷന്റെ ട്രാഫിക് ടണൽ ഉപയോഗിച്ചോ എന്നതിനെ ആശ്രയിക്കുന്നില്ല. ആ സ്വാതന്ത്ര്യമാണ് മുഴുവൻ ബുദ്ധിമുട്ട്.
പാതയുടെ തിരഞ്ഞെടുപ്പ് റൂട്ടിംഗ് ചെയ്യുന്നു, ഇന്റർഫേസ് മെട്രിക്, ടണൽ ഇൻസ്റ്റാൾ ചെയ്യുന്ന പ്രിഫിക്സ് എന്നിവയിലൂടെ. അതിനാൽ ഒരു പ്രൊഫൈൽ പൊതുവായതെന്ന് ലേബൽ ചെയ്യപ്പെടാം, അതേസമയം ഒരു ആപ്ലിക്കേഷന്റെ കണക്ഷൻ ഭൗതിക പാത സ്വീകരിക്കുന്നു, ഫയർവാൾ എന്നിട്ടും പൊതു നിയമ കൂട്ടം പ്രയോഗിച്ചതായി റിപ്പോർട്ട് ചെയ്യും.
അതുകൊണ്ടാണ് പ്രൊഫൈലിൽ പരിമിതപ്പെടുത്തിയ ഒരു നിയമത്തിന് ടണൽ മാത്രം എന്നർത്ഥം വരാൻ കഴിയാത്തത്. ഈ രണ്ട് സവിശേഷതകളും വ്യത്യസ്ത ഘടകങ്ങൾ തീരുമാനിക്കുന്നു, ഒന്നിന് മറ്റൊന്നിനെ പകരം വയ്ക്കാനാവില്ല.
| Flow | What decides it | What a rule can enforce |
|---|---|---|
| VPN client to its endpoint | Routing plus the outer transport | Allow the client process before the tunnel exists |
| Application to an internet host | Interface metric and prefix length | Block the process unless the tunnel interface is up |
| Application to a LAN host | Local subnet route | Allow one destination, not the whole category |
വ്യക്തമായ ബ്ലോക്ക് ഇടുങ്ങിയ അനുമതിയെ മറികടക്കുന്നു
Microsoft-ന്റെ ഫയർവാൾ നിയമ മാർഗ്ഗനിർദ്ദേശം, സ്ഥിരസ്ഥിതി ബ്ലോക്ക് പ്രവർത്തനത്തിനുള്ള അനുമതി ഒഴിവിനെ, അനുമതിയുമായി വൈരുദ്ധ്യത്തിലുള്ള വ്യക്തമായ ബ്ലോക്കിൽ നിന്ന് വേർതിരിക്കുന്നു. വ്യക്തമായ ബ്ലോക്കുകൾ ആ വൈരുദ്ധ്യത്തിൽ വിജയിക്കുന്നു, ഔട്ട്ബൗണ്ട് നിയമങ്ങളും അതേ മുൻഗണന പാലിക്കുന്നു.
അതിനാൽ എല്ലാം ബ്ലോക്ക് ചെയ്യുന്ന ഒരു നിയമം ചേർത്ത്, അതിന് മുകളിൽ വയ്ക്കുന്ന ഇടുങ്ങിയ അനുമതിയെ ആശ്രയിക്കുന്ന ജനപ്രിയ പാചകം അതിന്റെ രചയിതാവ് പ്രതീക്ഷിക്കുന്നത് ചെയ്യുന്നില്ല. Windows Firewall വൈരുദ്ധ്യം അഡ്മിനിസ്ട്രേറ്റർ നൽകിയ നിയമ ക്രമം കൊണ്ട് പരിഹരിക്കുന്നില്ല. ബ്ലോക്ക് വെറുതെ ബാധകമാകുന്നു, കണക്റ്റ് ചെയ്യുന്ന ആപ്ലിക്കേഷൻ സമയപരിധി കഴിഞ്ഞതായി റിപ്പോർട്ട് ചെയ്യുന്നു. ഒഴിവായി തോന്നിയ നിയമം ഒരിക്കലും കളിയിൽ ഉണ്ടായിരുന്നില്ല.
പിന്തുണയ്ക്കുന്ന രൂപം അംഗീകൃത അനുമതി നിയമങ്ങളോടുകൂടിയ സ്ഥിരസ്ഥിതി നിരാകരണ നയമാണ്, ഇവിടെ ഓരോ അനുമതിയും ഒരു പ്രോഗ്രാം, സേവനം അല്ലെങ്കിൽ ലക്ഷ്യം അവലോകനം ചെയ്യാൻ മതിയായ കൃത്യതയോടെ പേരിടുന്നു. ആ രൂപകൽപ്പന ഒരു ഓഡിറ്റിനെ അതിജീവിക്കുന്നു, കാരണം ഓരോ ഒഴിവും ദൃശ്യമാണ്, അവയൊന്നും സൃഷ്ടിച്ച ക്രമത്തെ ആശ്രയിക്കുന്നില്ല.
പരസ്പരം വൈരുദ്ധ്യമുള്ള രണ്ട് നിയമങ്ങൾ ഒരു നിയമത്തെക്കാൾ മോശമാണ്, കാരണം ഫലമായ സ്വഭാവം ഒരേസമയം ശരിയും വിശദീകരിക്കാനാവാത്തതുമാണ്.
ഔട്ട്ബൗണ്ട് നയത്തിന് ഒരു ഉടമയെ നൽകുക
പിന്തുണയ്ക്കുന്ന VPN ക്ലയന്റ് ഇതിനകം സ്വന്തം ബ്ലോക്കിംഗ് സ്വഭാവവും സ്വന്തം എൻഡ്പോയിന്റ് ഒഴിവുകളും പരിപാലിക്കുന്നു. ഏകോപിപ്പിക്കാത്ത കൈയക്ഷര നിയമങ്ങൾ ചേർക്കുന്നത് ആ ക്ലയന്റിനെ ക്രമീകരണത്തിന് ആവശ്യമായ ടണലിന് പുറത്ത് ഉപേക്ഷിക്കാം, അല്ലെങ്കിൽ ആരും ശ്രദ്ധിക്കാത്ത രണ്ടാമത്തെ പാത തുറന്നിടാം.
നിയമങ്ങൾ എഴുതുന്നതിന് മുമ്പ് ഔട്ട്ബൗണ്ട് നയം ആർക്കുള്ളതെന്ന് തീരുമാനിക്കുക: ക്ലയന്റിന്റെ സ്വന്തം കോൺഫിഗറേഷൻ, കൈകാര്യം ചെയ്യുന്ന ഫയർവാൾ നയം, അല്ലെങ്കിൽ ഉടമയുള്ള രേഖപ്പെടുത്തിയ പ്രാദേശിക ഒഴിവ് പട്ടിക. തുടർന്ന് എന്തെങ്കിലും കണക്റ്റ് ചെയ്യുന്നതുവരെ പരീക്ഷണങ്ങൾ കൂട്ടിവയ്ക്കുന്നതിനുപകരം പാളികൾ യോജിപ്പിക്കുക. പേരുള്ള ഉടമ തന്നെയാണ് രണ്ട് പാളികൾ യോജിക്കാത്തപ്പോൾ ചോദിക്കുന്ന വ്യക്തിയും.
എന്തെങ്കിലും മാറ്റുന്നതിന് മുമ്പ് ഒരു വീണ്ടെടുപ്പ് ചാനൽ സംരക്ഷിക്കുക. സ്വന്തം മാനേജ്മെന്റ് പാതയിൽ നിന്ന് പുറത്താക്കപ്പെട്ട ഒരു വിദൂര യന്ത്രം, നിങ്ങൾ അടച്ചുകൊണ്ടിരുന്ന നയ വിടവിനെക്കാൾ മോശം ഫലമാണ്. വീണ്ടെടുപ്പ് നിയമം മുൻകൂട്ടി എഴുതിയാൽ ന്യായീകരിക്കാൻ എളുപ്പവും, ആർക്കും ഇഷ്ടമില്ലാത്ത സമയത്ത് മാറ്റം പിഴച്ചാൽ കണ്ടെത്താൻ എളുപ്പവുമാണ്.
ലേബൽ വായിക്കുന്നതിനുപകരം നാല് ഫലങ്ങൾ പരിശോധിക്കുക
ഒരു നയം വേർതിരിക്കുന്ന കേസുകളോളം മാത്രമേ മികച്ചതാകൂ, അതിനാൽ പ്രൊഫൈൽ ലേബൽ ഫലമല്ല, തുടക്കമാണെന്ന് കരുതുക. നാല് ഫലങ്ങൾ അത് പ്രവർത്തിക്കുന്നുണ്ടോ എന്ന് പറയുന്നു: ഉദ്ദേശിച്ച LAN അഭ്യർത്ഥന വിജയിക്കുന്നു, ഉൾപ്പെടുത്തിയ ഇന്റർനെറ്റ് അഭ്യർത്ഥന വിജയിക്കുന്നു, വിലക്കപ്പെട്ട നേരിട്ടുള്ള അഭ്യർത്ഥന പരാജയപ്പെടുന്നു, ടണൽ പരാജയ കേസ് സൈലന്റായി പിൻവാങ്ങുന്നതിനുപകരം രൂപകൽപ്പന അനുസരിച്ച് പ്രവർത്തിക്കുന്നു. നാല് ഫലങ്ങളും നിയമ മാറ്റത്തിന് സമീപം എഴുതിവയ്ക്കുക. നാല് പേരിട്ട കേസുകളുള്ള ഒരു പരീക്ഷണ പദ്ധതി ഓരോ തവണയും പ്രവർത്തിപ്പിക്കാൻ മതിയായ ചെറുതും ഉച്ചത്തിൽ പരാജയപ്പെടാൻ മതിയായ വ്യക്തവുമാണ്.
Get-NetConnectionProfile | Select-Object Name,NetworkCategory,InterfaceAlias Get-NetFirewallProfile | Select-Object Name,DefaultOutboundAction Get-NetFirewallRule -Direction Outbound -Enabled True | Where-Object Action -eq Block | Select-Object DisplayName,Profile
ആദ്യ കമാൻഡ് ഓരോ കണക്റ്റ് ചെയ്ത നെറ്റ്‌വർക്കും എങ്ങനെ തരംതിരിക്കപ്പെട്ടു എന്ന് കാണിക്കുന്നു, ഇത് പലപ്പോഴും നിയമം എഴുതിയ വ്യക്തി അനുമാനിച്ചതല്ല. രണ്ടാമത്തേത് ഓരോ പ്രൊഫൈലിന്റെയും സ്ഥിരസ്ഥിതി പ്രവർത്തനം കാണിക്കുന്നു, മൂന്നാമത്തേത് പ്രവർത്തനക്ഷമമായ ഔട്ട്ബൗണ്ട് ബ്ലോക്കുകൾ പട്ടികപ്പെടുത്തുന്നു, ഇടുങ്ങിയ അനുമതിയെ സൈലന്റായി അസാധുവാക്കുന്നവ ഉൾപ്പെടെ.
നെറ്റ്‌വർക്ക് മാറ്റത്തിന് ശേഷം നാല് കേസുകളും വീണ്ടും പ്രവർത്തിപ്പിക്കുക, കാരണം യന്ത്രം മറ്റൊരു നെറ്റ്‌വർക്കിൽ ചേരുമ്പോൾ പ്രൊഫൈൽ വീണ്ടും തരംതിരിക്കപ്പെടാം. പൊരുത്തപ്പെടുന്ന പ്രൊഫൈൽ ലേബൽ പാത നിങ്ങൾ ഉദ്ദേശിച്ചതായിരുന്നു എന്നതിന് തെളിവല്ല.