RDP-യ്ക്കുള്ള അനുമതി നിയമം ചേർക്കുന്നത് നിങ്ങളുടെ VPN ആക്സസ് ചുരുക്കുന്നില്ല

പദ്ധതി ന്യായയുക്തമായി തോന്നുന്നു: നിലവിലുള്ള റിമോട്ട് ഡെസ്ക്ടോപ്പ് അനുമതി ഉള്ളതുപോലെ വിട്ട്, ആക്സസ് ഉണ്ടായിരിക്കേണ്ട ഏക VPN ക്ലയന്റിനായി ഒരു ചെറിയ അനുമതി ചേർക്കുക. Windows Firewall അങ്ങനെ പ്രവർത്തിക്കുന്നില്ല. ഏറ്റവും നിർദ്ദിഷ്ട എൻട്രി വിജയിക്കുന്ന ക്രമീകരിച്ച പട്ടികയല്ല നിയമങ്ങൾ, കൂടാതെ വിശാലമായ അനുമതിക്കൊപ്പം ഇടുങ്ങിയ അനുമതി ചേർത്താലും ഒന്നും മാറുന്നില്ല, കാരണം വിശാലമായത് മുമ്പേ അനുവദിച്ച എല്ലാവരെയും ഇപ്പോഴും അനുവദിക്കുന്നു. സേവനം ചുരുക്കുക എന്നാൽ ഇതിനകം ജോലി ചെയ്യുന്ന അനുമതി തന്നെ തിരുത്തുക എന്നാണ്.

നിങ്ങൾ ചേർക്കുന്ന നിയമം പ്രധാനമായ നിയമമല്ല

Windows Firewall മെഷീനിൽ ബാധകമായ നയ സംഭരണികളിലെ എല്ലാ ബാധകമായ ഇൻബൗണ്ട് നിയമങ്ങളും വിലയിരുത്തുന്നു, തുടർന്ന് ഏതെങ്കിലും അനുമതി പൊരുത്തപ്പെടുന്നുണ്ടോ, ഏതെങ്കിലും തടയൽ അതിനെ മറികടക്കുന്നുണ്ടോ എന്ന് തീരുമാനിക്കുന്നു. ഒരു നിയമം ചേർക്കുന്നത് ഒരു അനുമതി ചേർക്കുന്നു; അത് ഇതിനകം ഉള്ള അനുമതികൾ നീക്കുന്നില്ല, വ്യക്തമാക്കുന്നുമില്ല.

അതിനാൽ ചോദ്യം ഒരിക്കലും നിങ്ങൾ എന്ത് ചേർത്തു എന്നതല്ല. ചോദ്യം പ്രാദേശിക നയം, ഡൊമെയ്ൻ നയം, പ്രൊഫൈൽ സ്ഥിരസ്ഥിതികൾ എന്നിവ ലയിപ്പിച്ചതിന് ശേഷം ഫലപ്രദമായ നയത്തിൽ എന്തുണ്ട് എന്നതാണ്. ഒരു പ്രാദേശിക നിയമമുള്ള വർക്ക്സ്റ്റേഷനെക്കുറിച്ച് ചിന്തിക്കാൻ എളുപ്പമാണ്; ഡൊമെയ്നിൽ ചേർന്ന സെർവറിനെക്കുറിച്ച് അല്ല.

അതുകൊണ്ടാണ് ഒരു അഡ്മിനിസ്ട്രേറ്റർക്ക് ശരിയെന്ന് തോന്നുന്ന മാറ്റം വരുത്താനും, അത് തെറ്റായ മെഷീനിൽ നിന്ന് പരിശോധിക്കാനും, അത് പ്രവർത്തിച്ചു എന്ന് അനുമാനിക്കാനും കഴിയുന്നത്. ഒഴിവാക്കപ്പെട്ട ഉറവിടം ഒരിക്കലും പരിശോധിക്കപ്പെട്ടിട്ടില്ല. വിജയം മാത്രം തെളിയിക്കുന്ന പരീക്ഷണം മാറ്റത്തിന്റെ ഉദ്ദേശ്യത്തിന്റെ പകുതിയിൽ കുറവ് മാത്രമേ തെളിയിക്കുന്നുള്ളൂ.

സെർവർ ഏത് വിലാസമാണ് കാണുന്നതെന്ന് കണ്ടെത്തുക

എന്തെങ്കിലും പരിധി നിർണ്ണയിക്കുന്നതിന് മുമ്പ് Windows ഹോസ്റ്റിൽ ഒരു അനുവദിച്ച സെഷൻ നിരീക്ഷിച്ച് സെർവർ റിപ്പോർട്ട് ചെയ്യുന്ന ഉറവിട വിലാസം രേഖപ്പെടുത്തുക. അത് ക്ലയന്റ് തനിക്കുണ്ടെന്ന് വിശ്വസിക്കുന്ന വിലാസമായിരിക്കണമെന്നില്ല.

VPN ഗേറ്റ്വേ ക്ലയന്റ് വിലാസങ്ങൾ സംരക്ഷിക്കുന്നുവെങ്കിൽ, സെർവർ ക്ലയന്റിന്റെ ടണൽ വിലാസം കാണുന്നു, വിലാസം കൊണ്ട് പരിമിതപ്പെടുത്തിയ നിയമം അർത്ഥവത്താണ്. ഗേറ്റ്വേ വിവർത്തനം ചെയ്യുന്നുവെങ്കിൽ, ഓരോ ക്ലയന്റും ഗേറ്റ്വേയുടെ വിലാസമായി എത്തുന്നു, ആ വിലാസത്തിലേക്ക് പരിമിതപ്പെടുത്തുന്നത് അതിന് പിന്നിലുള്ള എല്ലാ ക്ലയന്റിനും ആക്സസ് നൽകുന്നു. അപ്പോൾ നിയമം തെറ്റായ കാര്യത്തെക്കുറിച്ച് കൃത്യമാണ്.

ആ രണ്ട് രൂപകൽപ്പനകൾക്ക് വ്യത്യസ്ത ഉത്തരങ്ങൾ വേണം. ആദ്യത്തേത് ഒരു ഫയർവാൾ നിയമത്തിൽ പ്രകടിപ്പിക്കാം; രണ്ടാമത്തേത് ഐഡന്റിറ്റി ഇനിയും നിലനിൽക്കുന്നിടത്ത്, അതായത് VPN-ൽ തന്നെയോ സേവനത്തിന് മുന്നിലുള്ള പ്രാമാണീകരിച്ച ഗേറ്റ്വേയിലോ നടപ്പാക്കണം.

നെറ്റ്വർക്ക് വിവർത്തനം വലിച്ചെറിഞ്ഞ ഐഡന്റിറ്റി ഒരു ഫയർവാൾ ഫിൽട്ടറിന് തിരികെ കൊണ്ടുവരാനാവില്ല, വിലാസം എത്ര ശ്രദ്ധയോടെ ടൈപ്പ് ചെയ്താലും.

ഫലപ്രദമായ നിയമത്തിന്റെ ഉടമയെ മാറ്റുക

ഫലപ്രദമായ ഇൻബൗണ്ട് നയം പരിശോധിച്ച് ഇപ്പോൾ RDP ട്രാഫിക് അനുവദിക്കുന്ന ഓരോ നിയമവും കണ്ടെത്തുക, പ്രദർശിപ്പിക്കുന്ന പേരിൽ പോർട്ട് 3389 ഒരിക്കലും പരാമർശിക്കാത്ത നിയമങ്ങൾ ഉൾപ്പെടെ. സേവനത്താൽ പരിമിതപ്പെടുത്തിയതും ആപ്ലിക്കേഷനാൽ പരിമിതപ്പെടുത്തിയതുമായ നിയമങ്ങളും കണക്കിലെടുക്കുന്നു, ചില RDP വിന്യാസങ്ങൾ പ്രവർത്തനക്ഷമമാക്കുന്ന UDP ഗതാഗതവും.

തുടർന്ന് നിലവിലുള്ള നിയമങ്ങൾ അവയുടെ ഉടമസ്ഥതയിലുള്ള സംഭരണിയിലൂടെ തിരുത്തുക. ഡൊമെയ്ൻ നയവും നിർവചിക്കുന്ന ഒരു നിയമത്തിനുള്ള പ്രാദേശിക തിരുത്ത് ലയിപ്പിക്കുകയോ അവഗണിക്കുകയോ മേലെഴുതുകയോ ചെയ്യാം, അതിൽ ആശ്രയിക്കുന്നതിന് മുമ്പ് ഏതാണ് സംഭവിക്കുന്നതെന്ന് അറിയുന്നത് മൂല്യവത്താണ്.

ഈ കമാൻഡുകൾ സജീവ നിയമങ്ങൾ കണ്ടെത്തുന്നു, അവയിലൊന്നുമായി ബന്ധിപ്പിച്ച വിലാസ ഫിൽട്ടർ കാണിക്കുന്നു, പരിധി മാറ്റം പ്രിവ്യൂ ചെയ്യുന്നു:

Get-NetFirewallRule -PolicyStore ActiveStore -Direction Inbound | Where-Object DisplayName -match RDP
Get-NetFirewallAddressFilter -AssociatedNetFirewallRule (Get-NetFirewallRule -Name Reviewed-RDP-TCP)
Set-NetFirewallRule -Name Reviewed-RDP-TCP -RemoteAddress 10.63.4.17 -WhatIf

ഇവിടെയുള്ള നിയമനാമങ്ങൾ അവലോകനം കണ്ടെത്തിയതിന്റെ പ്ലേസ്ഹോൾഡറുകളാണ്, വിലാസത്തിലെ ഒരു അക്ഷരത്തെറ്റ് നിങ്ങൾ തിരുത്തുന്ന സെർവറിൽ നിന്ന് നിങ്ങളെ പുറത്താക്കാതിരിക്കാനാണ് പ്രിവ്യൂ ഫ്ലാഗ്.

ആദ്യം തടയുക പിന്നീട് അനുവദിക്കുക എന്നത് മറ്റൊരു മാതൃകയാണ്

മറ്റ് ഫയർവാളുകളുടെ ശീലം വിശാലമായ തടയൽ എഴുതി അതിന് മുകളിൽ ഇടുങ്ങിയ അനുമതി നൽകുക എന്നതാണ്. Windows-ൽ വ്യക്തമായ തടയൽ സാധാരണയായി അനുമതിയെ മറികടക്കുന്നു, അതിനാൽ ആ ക്രമം ഒരു ക്ലയന്റിനുള്ള ഒഴിവാക്കലിനുപകരം ആർക്കും എത്തിച്ചേരാനാകാത്ത സേവനം സൃഷ്ടിക്കുന്നു. ഫലം തകർന്ന RDP സേവനം പോലെ തോന്നുന്ന തടസ്സമാണ്. യഥാർത്ഥത്തിൽ അത് മുൻഗണനയുടെ പിഴവാണ്, പരിഹാരം മറ്റൊരു അനുമതി ചേർക്കുന്നതല്ല, തടയൽ നീക്കം ചെയ്യുകയാണ്.

സജീവ പ്രൊഫൈലുകളിൽ സ്ഥിരസ്ഥിതി ഇൻബൗണ്ട് തടയൽ സ്വഭാവം നിലനിർത്തി പകരം നിർദ്ദിഷ്ട അനുമതികൾ ചുരുക്കുക. അത് പരസ്പരവിരുദ്ധമായ രണ്ട് നിയമങ്ങൾക്കുപകരം ഒരു മനസ്സിലാക്കാവുന്ന അവസ്ഥയിൽ മെഷീനെ വിടുന്നു, അവയുടെ പരസ്പരപ്രവർത്തനം മുൻഗണനാ വിശദാംശങ്ങളെ ആശ്രയിച്ചിരിക്കുന്നു.

രണ്ടാമത്തെ ഉറവിടം കൊണ്ട് അത് തെളിയിക്കുക

അനുവദിച്ച ക്ലയന്റിൽ നിന്നും ഇപ്പോൾ പരാജയപ്പെടേണ്ട ഉറവിടത്തിൽ നിന്നും പരീക്ഷിക്കുക. ഒരു വിജയകരമായ കണക്ഷൻ അനുവദിച്ച പാത പ്രവർത്തിക്കുന്നു എന്ന് മാത്രമേ തെളിയിക്കുന്നുള്ളൂ; നിങ്ങൾ ഇപ്പോൾ ചെയ്ത ഒഴിവാക്കലിനെക്കുറിച്ച് അത് ഒന്നും പറയുന്നില്ല.

സെർവറിൽ പ്രവർത്തനക്ഷമമാണെങ്കിൽ IPv6-ൽ പരീക്ഷണം ആവർത്തിക്കുക, കാരണം IPv4 മാത്രം ലക്ഷ്യമിട്ട ഉദ്ദേശ്യം ആരും നോക്കാത്ത വിശാലമായ IPv6 അനുമതിയോടൊപ്പം നിലനിൽക്കാം.

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