ഫയർവാൾ VPN തടയുകയാണോ? ഘട്ടം ഘട്ടമായുള്ള പരിശോധന

ഒരു VPN ടൈംഔട്ട് ഉപയോഗ്യമായ ഒരു മറുപടിയും എത്തിയില്ല എന്ന് തെളിയിക്കുന്നു, കാരണത്തെക്കുറിച്ച് ഒന്നും തെളിയിക്കുന്നില്ല. പ്രൊഫൈൽ തെറ്റായ പോർട്ട് പറയാം, സെർവർ ഓഫ് ആകാം, അല്ലെങ്കിൽ പ്രവർത്തിക്കുന്ന ഒരു തിരിച്ചുവരവ് പാതയില്ലാതെ അഭ്യർത്ഥന എത്താം. ഇവയോരോന്നും വ്യത്യസ്തമായ ഒരു അടയാളം അവശേഷിപ്പിക്കുന്നു, ഏത് നിയമം തൊടണം എന്ന് ആ അടയാളമാണ് പറയുന്നത്. താഴെയുള്ള നാല് ഘട്ടങ്ങൾ ക്രമത്തിൽ ചെയ്യുക. അവയിലൊന്ന് ലക്ഷണം വിശദീകരിച്ച ഉടൻ നിർത്തുക.

ഘട്ടം 1: സെർവറും ഗതാഗതവും സ്ഥിരീകരിക്കുക

സെർവർ പേര്, ഗതാഗതം, പോർട്ട് എന്നിവ പ്രാദേശിക മാറ്റത്തിൽ നിന്നല്ല, ഓപ്പറേറ്ററുടെ നിലവിലെ പ്രൊഫൈലിൽ നിന്ന് വായിക്കുക. നിങ്ങളുടെ ലാപ്ടോപ്പിൽ മാറ്റിയ പോർട്ടിന് പൊതു സെർവറിൽ ശ്രോതാവിനെ സൃഷ്ടിക്കാനാവില്ല, ആ പൊരുത്തക്കേട് തടയലിന് തുല്യമായ ടൈംഔട്ട് നൽകുന്നു. പ്രൊഫൈൽ പിന്തുണയുള്ള ബദൽ ഗതാഗതം വാഗ്ദാനം ചെയ്താൽ, അത് പരിഹാരമല്ലാതെ ബദൽ മാർഗമായി രേഖപ്പെടുത്തുക. പേര് നിർണ്ണയിച്ച് ഉത്തരം ഓപ്പറേറ്റർ പ്രസിദ്ധീകരിച്ച വിലാസവുമായി താരതമ്യം ചെയ്യുക.

പഴയ DNS റെക്കോർഡ് ഒരിക്കലും മറുപടി നൽകാത്ത ഹോസ്റ്റിലേക്ക് ക്ലയന്റിനെ അയക്കുന്നു. ഇതും ഫിൽട്ടറിനെ അനുകരിക്കുന്ന മറ്റൊരു തകരാറാണ്, അത് ഒഴിവാക്കാൻ ഒരു ചോദ്യം മതി.

രണ്ട് മൂല്യങ്ങളും ടിക്കറ്റിൽ എഴുതുക. തുടർന്നുള്ള ഓരോ താരതമ്യവും അവ ഉപയോഗിക്കുന്നു, അവയില്ലാത്ത ടിക്കറ്റ് അന്വേഷണം വീണ്ടും തുടങ്ങുന്നു.

ഘട്ടം 2: ഒരു നിയന്ത്രിത താരതമ്യത്തിലൂടെ പാത തെളിയിക്കുക

ഉപകരണവും പ്രൊഫൈലും മാറ്റാതെ മറ്റൊരു വിശ്വസ്ത ആക്സസ് നെറ്റ്വർക്ക് പരീക്ഷിക്കുക. അവിടെ ടണൽ ഉയർന്നാൽ വ്യത്യാസം യഥാർത്ഥ പാതയോ അതിന്റെ നയമോ ആണ്. യഥാർത്ഥ നെറ്റ്വർക്കിൽ രണ്ടാമത്തെ അനുവദിച്ച ഉപകരണം പ്രവർത്തിച്ചാൽ വ്യത്യാസം ആദ്യ ഉപകരണമാണ്. ആ രണ്ട് താരതമ്യങ്ങളിൽ ഒന്ന് ഏതാണ്ട് എപ്പോഴും നിർണ്ണായകമാണ്.

ആദ്യം ഏതെങ്കിലും നിയമാനുസൃത നെറ്റ്വർക്ക് സൈൻ-ഇൻ പൂർത്തിയാക്കുക, കാരണം ക്യാപ്റ്റീവ് പോർട്ടൽ പൂർത്തിയാകുന്നതുവരെ തടയലിനെപ്പോലെ തോന്നും.

യഥാർത്ഥത്തിൽ ഉപയോഗിക്കുന്ന പോർട്ട് പരിശോധിക്കുക, TCP ഫലത്തെ TCP-യെക്കുറിച്ചുള്ള വിവരമായി മാത്രം കാണുക.

Resolve-DnsName vpn.corp.example
tracert -h 8 -w 500 vpn.corp.example
Test-NetConnection vpn.corp.example -Port 443 -InformationLevel Detailed

443 പോർട്ടിൽ വിജയകരമായ TCP ഹാൻഡ്ഷേക്ക് അവിടെ ഒരു ശ്രോതാവ് മറുപടി നൽകി എന്നർത്ഥം. 51820-ലെ UDP ശ്രോതാവിനെക്കുറിച്ചും ചർച്ചകൾ പൂർത്തിയായോ എന്നതിനെക്കുറിച്ചും അത് ഒന്നും പറയുന്നില്ല.

ഘട്ടം 3: പരാജയത്തിന്റെ നിമിഷത്തിലെ സുരക്ഷാ ഇവന്റുകൾ വായിക്കുക

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

പ്രൊഫൈൽ അവസ്ഥയും സമീപകാല ഇവന്റുകളും പരാജയപ്പെട്ട മെഷീനിൽ നിന്ന് തന്നെ ശേഖരിക്കുക, അടുത്തുള്ള ഹോസ്റ്റിൽ നിന്നല്ല.

ഇവന്റിന്റെ സമയം നിങ്ങളുടെ പരീക്ഷണ ശ്രമത്തിന്റെ സമയവുമായി താരതമ്യം ചെയ്യുക, കാരണം വ്യത്യസ്ത ടൈംസ്റ്റാമ്പുള്ള ഒരേ നിയമ നാമം യാദൃച്ഛികമാണ്.

Get-NetFirewallProfile | Select-Object Name, Enabled, DefaultInboundAction, LogBlocked
Get-NetFirewallRule -Enabled True -Direction Outbound | Where-Object DisplayName -match 'VPN'
Get-WinEvent -LogName 'Microsoft-Windows-Windows Firewall With Advanced Security/Firewall' -MaxEvents 20

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

ഘട്ടം 4: ടണൽ ഉയർന്നതിന് ശേഷം ഫോർവേഡിംഗ് പരിശോധിക്കുക

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

ക്ലയന്റ് കണക്റ്റ് ചെയ്ത് പരാജയപ്പെടുന്ന അഭ്യർത്ഥന ശ്രമിക്കുന്ന സമയത്ത് സെർവറിൽ താഴെയുള്ള മൂന്ന് പരിശോധനകൾ നടത്തുക.

ടണൽ ഇന്റർഫേസിലെ കൗണ്ടറുകളാണ് പ്രധാനം, കാരണം പാക്കറ്റുകൾ അകത്ത് വന്നോ എന്തെങ്കിലും പുറത്ത് പോയോ എന്ന് അവ കാണിക്കുന്നു.

sysctl net.ipv4.ip_forward
nft list ruleset | grep -n -E 'forward|masquerade'
tcpdump -ni tun0 -c 10

ടണലിലേക്ക് പാക്കറ്റുകൾ വന്ന് ലക്ഷ്യത്തിലേക്ക് ഒന്നും പോകുന്നില്ലെങ്കിൽ സംശയം ഫോർവേഡിംഗ് അല്ലെങ്കിൽ NAT ആണ്. ഒന്നും വരുന്നില്ലെങ്കിൽ സെഷൻ ഉയർന്നിട്ടുണ്ട്, പക്ഷേ ക്ലയന്റ് അയക്കുന്നില്ല, നോക്കേണ്ട സ്ഥലം ക്ലയന്റിന്റെ റൂട്ട് ടേബിളാണ്.

തിരുത്തൽ പരിശോധിച്ച് സഹായിക്കാത്തത് നീക്കം ചെയ്യുക

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

അതേ മൂന്ന് കമാൻഡുകൾ വീണ്ടും പ്രവർത്തിപ്പിച്ച് മാറ്റത്തിന് മുൻപ് സംരക്ഷിച്ച ഔട്ട്പുട്ടുകളുമായി താരതമ്യം ചെയ്യുക.

Test-NetConnection vpn.corp.example -Port 443 -InformationLevel Detailed
tracert -h 8 -w 500 vpn.corp.example
Get-NetFirewallRule -Enabled True | Where-Object DisplayName -match 'VPN' | Select-Object DisplayName, Action

താരതമ്യ നെറ്റ്വർക്ക് പ്രവർത്തിച്ച്, യഥാർത്ഥ നെറ്റ്വർക്ക് ഇപ്പോഴും പരാജയപ്പെട്ട്, ഇവന്റുകൾ ശൂന്യമായി തുടർന്നാൽ, ബാക്കിയുള്ള സംശയം ഹോസ്റ്റല്ല, പാതയാണ്. രണ്ട് താരതമ്യ ഫലങ്ങളും ചേർത്ത് അത് നെറ്റ്വർക്ക് ഉടമയ്ക്ക് കൃത്യമായ പ്രസ്താവനയായി നൽകുക. നിഷ്ക്രിയമാക്കിയ ഫയർവാൾ പ്രൊഫൈലിനേക്കാൾ ഇവിടെ നിർത്തുന്നതാണ് നല്ലത്.