VPN അവസ്ഥയുമായി ബന്ധിപ്പിച്ച ഫയർവാൾ ഗേറ്റ് ടണലിലൂടെ മാത്രം ping എന്ന നിയമം ആകാത്തത് എന്തുകൊണ്ട്

പേരിട്ട VPN പ്രൊഫൈൽ ബന്ധിപ്പിക്കുമ്പോഴെല്ലാം സെർവറിന്റെ പൊതു വിലാസത്തിന് ICMP echo ഓണാക്കുന്ന ഒരു ഫയർവാൾ നിയമം സങ്കൽപ്പിക്കുക. അത് «ടണലിലൂടെ മാത്രം ping» എന്ന് വായിക്കപ്പെടുന്നു, ആ വായന പ്രധാനമായ ഒരു രീതിയിൽ തെറ്റാണ്. നിയമം ആർക്ക് ഹോസ്റ്റിലേക്ക് എത്താമെന്ന് പരിമിതപ്പെടുത്തുന്നില്ല; മറ്റൊരു കണക്ഷൻ യാദൃശ്ചികമായി സജീവമായിരിക്കുമ്പോൾ പൊതു ഇന്റർഫേസ് എന്തിനോട് പ്രതികരിക്കുന്നു എന്നതിനെ അത് മാറ്റുന്നു. ഇവ രണ്ട് വ്യത്യസ്ത നയങ്ങളാണ്, അവയിലൊന്ന് നിശബ്ദമായി വിധേയത്വം വിപുലീകരിക്കുന്നു.

നിങ്ങൾ എഴുതിയതായി കരുതുന്ന നിയമം

ഉദ്ദേശിച്ച ആവശ്യകത സാധാരണയായി ഇടുങ്ങിയതാണ്: നിരീക്ഷണ സംവിധാനത്തിനോ VPN-ലെ ഏക അഡ്മിനിസ്ട്രേറ്റർക്കോ സെർവർ ജീവിച്ചിരിക്കുന്നുവെന്ന് സ്ഥിരീകരിക്കാൻ കഴിയണം. വാക്യമായി എഴുതുമ്പോൾ അത് ടണലിലെ പ്രവേശന നിയന്ത്രണം പോലെ തോന്നുന്നു. ഫയർവാൾ ഒബ്ജക്ടായി എഴുതുമ്പോൾ അത് പൊതു പ്രൊഫൈലിലെ വ്യവസ്ഥ ആകുന്നു, കാരണം echo അഭ്യർത്ഥന അവിടെയാണ് എത്തുന്നത്.

വ്യവസ്ഥ ഉറവിട വിലാസത്തിന് പകരം കണക്ഷൻ അവസ്ഥയാകുമ്പോൾ, അനുവദിക്കപ്പെട്ട അയയ്ക്കുന്നവരുടെ ഗണം ഇനി VPN സഹപ്രവർത്തകരുടെ ഗണമല്ല. പൊതു വിലാസത്തിൽ എത്താൻ കഴിയുന്ന ആർക്കും ഗേറ്റ് തുറന്നിരിക്കുമ്പോൾ echo അഭ്യർത്ഥന അയയ്ക്കാം. ടണൽ വഴിയായില്ല; ടണൽ സ്വിച്ചായി.

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

ഗേറ്റ് യഥാർത്ഥത്തിൽ നിയന്ത്രിക്കുന്നത്

ഈ രൂപകൽപ്പന രണ്ട് സ്വതന്ത്ര കാര്യങ്ങൾ കൂട്ടിച്ചേർക്കുന്നു, അവ വേർതിരിക്കുന്നതാണ് തിരുത്തലിന്റെ ഭൂരിഭാഗം. ആദ്യത്തേത് വ്യാപ്തിയാണ്: ഏത് പ്രാദേശിക വിലാസം, ഏത് ദൂര വിലാസങ്ങൾ, ഏത് പ്രോട്ടോക്കോൾ, ഏത് ICMP തരം. രണ്ടാമത്തേത് വ്യവസ്ഥയാണ്: നിയമത്തിന്റെ ഒബ്ജക്ട് ഈ നിമിഷം സജീവമാണോ എന്നത്. വ്യാപ്തി ഫയർവാൾ ഓരോ പാക്കറ്റിനും വിലയിരുത്തുന്നതാണ്; വ്യവസ്ഥ സ്ക്രിപ്റ്റ് നയ സംഭരണിയിൽ എഴുതുന്നതാണ്, രണ്ടും തികച്ചും വ്യത്യസ്ത ഘടികാരങ്ങളിൽ ഒത്തുതീർക്കുന്നു.

ആവശ്യകത യഥാർത്ഥത്തിൽ VPN സഹപ്രവർത്തകർ മാത്രമാണെങ്കിൽ, വ്യാപ്തി തന്നെ കണക്ഷൻ അവസ്ഥയുടെ ഒരു യുക്തിയുമില്ലാതെ അതിന് ഉത്തരം നൽകുന്നു: നിയമം ടണൽ ഇന്റർഫേസിലേക്കോ ടണൽ വിലാസ ശ്രേണിയിലേക്കോ ബന്ധിപ്പിക്കുക, ദൂര വിലാസങ്ങൾ ക്ലയന്റ് പൂളിൽ പരിമിതപ്പെടുത്തുക, «ICMP»-ക്ക് പകരം echo തരം വ്യക്തമാക്കുക. ഒരു VPN-ഉം ഓണല്ലാത്തപ്പോഴും ആ നിയമം ശരിയായി നിലനിൽക്കുന്നു, ബന്ധമില്ലാത്ത പ്രൊഫൈലിന് അത് തുറക്കാൻ കഴിയില്ല.

ആവശ്യകത യഥാർത്ഥത്തിൽ പൊതു ഗേറ്റ് ആണെങ്കിൽ, സ്വീകാര്യതാ മാനദണ്ഡങ്ങൾ മാറുന്നതിനാൽ അത് നയത്തിന്റെ പാഠത്തിൽ പറയുക. പൊതു ഗേറ്റ് കൃത്യമായ പ്രൊഫൈൽ പേരെടുത്ത് പറയണം, «ബന്ധിപ്പിച്ചിരിക്കുന്നു» എന്നതിന്റെ അർത്ഥം നിർവചിക്കണം, പൊതു അയയ്ക്കുന്നവർ രൂപകൽപ്പന പ്രകാരം വ്യാപ്തിയിലാണെന്ന് പ്രഖ്യാപിക്കണം. ആരെയെങ്കിലും ആ വാക്യം എഴുതാൻ നിർബന്ധിക്കുന്ന നിമിഷത്തിൽ ഭൂരിഭാഗം ആശയക്കുഴപ്പവും അപ്രത്യക്ഷമാകുന്നു.

ഒബ്ജക്ട് ഒരിക്കൽ നിർമ്മിക്കുക, പിന്നെ ടോഗിൾ ചെയ്യുക

സ്ഥിരമായ ഐഡന്റിറ്റിയുള്ള ഒരു നിയമം മുൻകൂട്ടി, നിഷ്ക്രിയമായി ഒരുക്കുക, നിയന്ത്രകൻ അതിന്റെ സജീവ അവസ്ഥ മാത്രം മാറ്റട്ടെ. ഓരോ പ്രവർത്തനത്തിലും പ്രദർശന നാമം ഉപയോഗിച്ച് നിയമങ്ങൾ സൃഷ്ടിക്കുന്നതാണ് നയ സംഭരണി അഞ്ച് ഏതാണ്ട് സമാന ഒബ്ജക്ടുകളുമായി, അവ നീക്കം ചെയ്യാനുള്ള വിശ്വസനീയ വഴിയില്ലാതെ അവസാനിക്കുന്ന പാത.

New-NetFirewallRule -Name "VpnGateEchoV4" -DisplayName "Public echo gated on VPN state" -Direction Inbound -Action Allow -Protocol ICMPv4 -IcmpType 8 -LocalAddress 203.0.113.10 -RemoteAddress Any -Enabled False
Set-NetFirewallRule -Name "VpnGateEchoV4" -Enabled True

പേര് ശാശ്വത ഐഡന്റിഫയറാണ്; പ്രദർശന നാമം മനുഷ്യന് തിരുത്താവുന്ന രേഖയാണ്. -Name-ൽ ഒത്തുതീർക്കുക, സ്ക്രിപ്റ്റ് പകർപ്പുകൾ ഉണ്ടാക്കുന്നത് നിർത്തും. അതേ കമാൻഡ് രൂപം IPv6 കേസ് -Protocol ICMPv6 -IcmpType 128 ഉപയോഗിച്ച് ഉൾക്കൊള്ളുന്നു, പക്ഷേ അത് വേറിട്ട നിയമമാണ്, കാരണം echo തരത്തിന്റെ സംഖ്യകൾ രണ്ട് കുടുംബങ്ങൾക്കിടയിൽ വ്യത്യസ്തമാണ്.

വിലാസ കുടുംബവും ICMP തരവും വ്യക്തമായി സൂക്ഷിക്കുക, രണ്ടാമത്തെ കാരണവുമുണ്ട്: -Protocol ICMPv4 തരമില്ലാതെ പ്രൊഫൈൽ അനുവദിക്കുന്ന എല്ലാ ICMPv4 സന്ദേശവും അനുവദിക്കുന്നു, നിങ്ങൾ ഒരിക്കലും സ്വീകരിക്കാൻ ഉദ്ദേശിക്കാത്തവ ഉൾപ്പെടെ. തരം 8 പേരെടുത്ത് പറയുന്നത് നിയമം echo അഭ്യർത്ഥനയിലേക്ക് ചുരുക്കുന്നു, എത്തിച്ചേരാനുള്ള പരിശോധന അയയ്ക്കുന്നത് അത് മാത്രമാണ്.

യാന്ത്രീകരണം ഉദ്ദേശ്യത്തിന് വിരുദ്ധമാകുന്നിടത്ത്

ഏതാനും മിനിറ്റുകളിലൊരിക്കൽ ക്ലയന്റ് പ്രൊഫൈൽ ചോദിച്ചറിയുന്നതിന് തൽക്ഷണമായ ഒരു അതിർത്തി സൃഷ്ടിക്കാനാവില്ല. കണക്ഷൻ വീഴുന്നതിനും അടുത്ത ചോദ്യത്തിനും ഇടയിൽ നിയമം പൊതു വിലാസത്തിൽ ഇപ്പോഴും ഉത്തരം നൽകുന്നു; കണക്ഷൻ ഉയരുന്നതിനും അടുത്ത ചോദ്യത്തിനും ഇടയിൽ നൽകുന്നില്ല. ആ കാലതാമസം സമ്മതിക്കുന്നത് സത്യസന്ധമാണ്, രൂപകൽപ്പന കർശനമായ ഇൻവേരിയന്റ് അടിച്ചേൽപ്പിക്കുന്നു എന്ന് അവകാശപ്പെടുന്നത് സത്യസന്ധമല്ല.

അവസ്ഥാ പരിശോധനയിൽ തന്നെ ഒരു വ്യാപ്തി കെണിയുണ്ട്. Get-VpnConnection യന്ത്രത്തിൽ ക്രമീകരിച്ച ക്ലയന്റ് പ്രൊഫൈലുകൾ റിപ്പോർട്ട് ചെയ്യുന്നു, സ്വതവേ നിലവിലെ ഉപയോക്താവിനും -AllUserConnection സഹിതം എല്ലാ ഉപയോക്താക്കൾക്കും. ഇപ്പോൾ RRAS സെർവറിലേക്ക് ഡയൽ-ഇൻ ചെയ്തിരിക്കുന്ന ദൂര ഉപയോക്താക്കളെ അത് റിപ്പോർട്ട് ചെയ്യുന്നില്ല; അത് മറ്റൊരു കമാൻഡുമായുള്ള മറ്റൊരു നിരീക്ഷണമാണ്. തെറ്റായതിന്മേൽ നിർമ്മിച്ച ഗേറ്റ് ഒന്നുമായും ബന്ധിപ്പിച്ചിട്ടില്ല.

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

അവസാനം, പൊതു അഭ്യർത്ഥന രണ്ടുതവണ പരിശോധിക്കുക, ഒരിക്കൽ തിരഞ്ഞെടുത്ത കണക്ഷൻ ഓണായിരിക്കെ, ഒരിക്കൽ അത് ഓഫായിരിക്കെ, VPN-ൽ ഇല്ലാത്ത ഒരു ഹോസ്റ്റിൽ നിന്ന്. ടണലിനുള്ളിൽ നിന്നുള്ള വിജയകരമായ ping ഈ നയത്തെക്കുറിച്ച് ഒന്നും തെളിയിക്കുന്നില്ല, അതാണ് ഭൂരിഭാഗം വിന്യാസങ്ങളും ഒഴിവാക്കുന്ന അളവ്.