പിംഗ് ഒരു ദിശയിൽ മാത്രം പ്രവർത്തിക്കുന്നു: Windows സർവറിന്റെ എക്കോ എന്തുകൊണ്ട് ഉപേക്ഷിക്കുന്നു

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

രണ്ട് ദിശകൾ, രണ്ട് വ്യത്യസ്ത തീരുമാനങ്ങൾ

ക്ലയന്റ് എക്കോ അഭ്യർത്ഥന അയക്കുമ്പോൾ, Windows ഫയർവാൾ അനുവദിക്കാൻ തീരുമാനിച്ച ഒരു ഔട്ട്ബൗണ്ട് കണക്ഷൻ കാണുന്നു. പ്രതികരണം ആ സ്ഥാപിത ഒഴുക്കിനുള്ളിലൂടെ തിരികെ വരുന്നു, അതിനാൽ അവസ്ഥ പിന്തുടരുന്ന എൻജിൻ ICMP-യ്ക്കുള്ള ഒരു ഇൻബൗണ്ട് നിയമവും ചോദിക്കാതെ അത് അനുവദിക്കുന്നു. പ്രായോഗികമായി അവസ്ഥാധിഷ്ഠിത ഫിൽട്ടറിംഗ് എന്നത് ഇതാണ്, ആരും എഴുതാത്ത നിയമം ഇവിടെ ഉൾപ്പെടുന്നില്ല. അതിനാൽ ക്ലയന്റിന്റെ വിജയം ഇൻബൗണ്ട് നയത്തെക്കുറിച്ച് ഒന്നും പറയുന്നില്ല.

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

അതായത് ക്ലയന്റിന്റെ വിജയം ഔട്ട്ബൗണ്ട് ICMP-യും തിരിച്ചുവരവ് പാതയും പ്രവർത്തിക്കുന്നു എന്ന് തെളിയിച്ചു. അത് ഇൻബൗണ്ട് തീരുമാനം ഒരിക്കലും പരിശോധിച്ചില്ല, ഫയർവാൾ കുഴപ്പമില്ല എന്ന സ്വാഭാവിക നിഗമനം ന്യായവും തെറ്റുമാണ്. അതുകൊണ്ടാണ് തെളിവ് ഇതിനകം ഉള്ള ടിക്കറ്റുകളിലും ഈ തെറ്റ് ആവർത്തിക്കുന്നത്.

പാക്കറ്റ് അപ്രത്യക്ഷമാകുന്നതുവരെ പിന്തുടരുക

എന്തെങ്കിലും മാറ്റുന്നതിന് മുൻപ് വിലാസങ്ങൾ സ്ഥിരീകരിക്കുക: ക്ലയന്റിന് യഥാർത്ഥത്തിൽ ഉള്ള ടണൽ വിലാസം ഉപയോഗിക്കുക, സർവർ ക്ലയന്റിന് പിന്നിലെ LAN വിലാസത്തിലേക്കല്ല, അതിലേക്കാണ് റൂട്ട് ചെയ്യുന്നതെന്ന് പരിശോധിക്കുക. രണ്ട് പരാജയങ്ങളും സർവറിന്റെ പ്രോംപ്റ്റിൽ നിന്ന് ഒരുപോലെ കാണാം, കാരണം രണ്ടും സമയപരിധി കഴിഞ്ഞ് അവസാനിക്കുന്നു. പാക്കറ്റ് എവിടെ മരിക്കുന്നു എന്നതാണ് എന്ത് മാറ്റണം എന്ന് തീരുമാനിക്കുന്ന ഏക വസ്തുത.

അഭ്യർത്ഥന ടണൽ ഇന്റർഫേസിൽ എത്തിയിട്ടും പുറത്തേക്ക് ഒന്നും പോകുന്നില്ലെങ്കിൽ, പ്രാദേശിക ഫയർവാളാണ് സാധ്യമായ കാരണം. അത് ഇന്റർഫേസിൽ ഒരിക്കലും എത്തുന്നില്ലെങ്കിൽ, ഉത്തരം മുകളിലാണ്: സർവറിലെ ഒരു റൂട്ട്, ഔട്ട്ബൗണ്ട് നയം, അല്ലെങ്കിൽ VPN-ന്റെ സ്വന്തം പിയർ വിതരണം.

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

ICMP തുറക്കുന്നതിനുപകരം ഒരു നിയമം പരിമിതപ്പെടുത്തുക

എന്തെങ്കിലും എഴുതുന്നതിന് മുൻപ് അഡാപ്റ്ററും അതിന്റെ നിലവിലെ വിഭാഗവും തിരിച്ചറിയുക, കാരണം രണ്ടും നിങ്ങൾ സജ്ജീകരിക്കാൻ പോകുന്ന പരിധിയിൽ വരും. ആ അലിയാസ് Windows ഇന്റർഫേസിന്റെ പേരാണ്, അത് നിങ്ങൾ ഇറക്കുമതി ചെയ്ത VPN പ്രൊഫൈലിന്റെ പേരായിരിക്കണമെന്നില്ല. താഴെയുള്ള കമാൻഡുകൾ എന്തുണ്ടെന്ന് ലിസ്റ്റ് ചെയ്ത്, പിന്നീട് പ്രയോഗിക്കാതെ പരിമിതപ്പെടുത്തിയ നിയമത്തിന്റെ പ്രിവ്യൂ കാണിക്കുന്നു.

Get-NetConnectionProfile
Get-NetAdapter | Where-Object Status -eq 'Up'
New-NetFirewallRule -DisplayName "VPN server echo" -Direction Inbound -Protocol ICMPv4 -IcmpType 8 -RemoteAddress 10.63.0.1 -InterfaceAlias "Office VPN" -Profile Private -Action Allow -WhatIf

ICMPv4 ടൈപ്പ് 8 ആണ് എക്കോ അഭ്യർത്ഥന, സർവറിന് മറുപടി ലഭിക്കേണ്ട ഏക സന്ദേശം. അതിനെ സർവറിന്റെ ടണൽ വിലാസത്തിലും ടണൽ ഇന്റർഫേസിലും പരിമിതപ്പെടുത്തുക, പ്രൊഫൈൽ അഡാപ്റ്റർ യഥാർത്ഥത്തിൽ ഉള്ളതുപോലെ വിടുക. ഒരു ഉദാഹരണത്തിന് യോജിക്കാൻ നെറ്റ്വർക്കിന്റെ പേര് മാറ്റുന്നത് സ്വന്തം പ്രത്യാഘാതങ്ങളുള്ള വേറിട്ട മാറ്റമാണ്.

നിയമം ഉൾക്കൊള്ളാത്തത്

IPv6 എക്കോ വേറിട്ട സന്ദേശ തരമുള്ള വേറിട്ട പ്രോട്ടോക്കോളാണ്, അതിനാൽ ICMPv4 നിയമം അതിനെക്കുറിച്ച് ഒന്നും പറയുന്നില്ല, രണ്ട് കുടുംബങ്ങളും കടത്തുന്ന ടണലിന് മറ്റേതിന് സ്വന്തം നിയമം വേണം. ഈ നിയമം മറ്റൊന്നും തുറക്കുന്നുമില്ല: RDP, ഫയൽ പങ്കിടൽ, മറ്റെല്ലാ സേവനങ്ങളും ഇപ്പോഴും അവയുടെ സ്വന്തം നയത്തെ ആശ്രയിക്കുന്നു. വിശാല ICMP അനുമതി പ്രവർത്തനക്ഷമമാക്കുന്നതിനുപകരം ഒരു ഇടുങ്ങിയ നിയമം പരിമിതപ്പെടുത്തുന്നതിന്റെ പൂർണ്ണ അർത്ഥം ഇതാണ്. വിശാല അനുമതിയാണ് എളുപ്പപരിഹാരം, ഏറ്റവും കൂടുതൽ കാലം നിലനിൽക്കുന്നതും, കാരണം പിന്നീട് ആരും അത് ശ്രദ്ധിക്കുന്നില്ല.

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

ഫലം ശരിയായ ദിശയിൽ വായിക്കുക

നിയമം പ്രാബല്യത്തിൽ വന്നശേഷം സർവറിൽ നിന്ന് പിംഗ് ചെയ്ത് പ്രതികരണം ക്ലയന്റിൽ എത്തുന്നുവെന്ന് സ്ഥിരീകരിക്കുക, പിന്നീട് ഇനിയും ഒഴിവാക്കപ്പെടേണ്ട ഉറവിടത്തിൽ നിന്ന് പിംഗ് ചെയ്ത് എത്തുന്നില്ലെന്ന് സ്ഥിരീകരിക്കുക. ടണൽ മറ്റേ വിലാസ കുടുംബം കടത്തുന്നുണ്ടെങ്കിൽ ആ വശത്തും എത്തിച്ചേരൽ പരിശോധന ആവർത്തിക്കുക.

Get-NetFirewallRule -DisplayName "VPN server echo" | Get-NetFirewallAddressFilter
ping 10.63.4.17
ping -6 fd00:63::17

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