VPN കണക്ട് ചെയ്തു, പക്ഷേ ഫയർവാൾ ഇപ്പോഴും തടയുന്നു: ഏതാണെന്ന് എങ്ങനെ അറിയാം

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

പാതയെ നയത്തിൽ നിന്ന് വേർതിരിക്കുക

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

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

പാത ഒറ്റ വായനയിൽ വായിക്കുക

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

ip route get 10.20.4.15
ip -brief address show
wg show
sudo ipsec statusall

പാതയുടെ ഔട്ട്പുട്ട് പാക്കറ്റ് ഏത് ഇന്റർഫേസിലൂടെ പുറത്തുപോകും, ഏത് സ്രോതസ്സ് വിലാസം വഹിക്കും എന്ന് പറയുന്നു. ആ ഇന്റർഫേസ് ടണലല്ല, നിങ്ങളുടെ ഭൗതിക നെറ്റ്വർക്ക് കാർഡാണെങ്കിൽ, പ്രശ്നം റൂട്ടിംഗിലോ ടണലിന്റെ അനുവദിച്ച ശ്രേണികളിലോ ആണ്, അത് ഫയർവാളിനല്ല, VPN കോൺഫിഗറേഷനിൽ പെടുന്നു.

VPN-ന് സവിശേഷമായ ഒരു കെണി പ്രത്യേക പരിശോധന അർഹിക്കുന്നു. WireGuard-ൽ പീയറിന്റെ AllowedIPs ഒരേ സമയം പാതയും ക്രിപ്റ്റോഗ്രാഫിക് ഫിൽട്ടറുമാണ്: സ്രോതസ്സ് വിലാസം പീയറിന്റെ അനുവദിച്ച ഗണവുമായി പൊരുത്തപ്പെടാത്ത പാക്കറ്റ്, ഏതെങ്കിലും ഫയർവാൾ നിയമം നോക്കുന്നതിന് മുൻപേ ഉപേക്ഷിക്കപ്പെടുന്നു. അതിനാൽ പൂർണ്ണമായി ശരിയായ ഹോസ്റ്റ് ഫയർവാൾ, നയം പോലെ തോന്നുന്ന നിശബ്ദ ഉപേക്ഷയുടെ പിന്നിൽ ആകാം, പരിഹാരം നിയമമല്ല, കീ കോൺഫിഗറേഷന്റെ ഒരു വരിയാണ്.

ഉത്തരം നൽകുന്ന പാളിയിൽ നയം വായിക്കുക

പാത ശരിയായാൽ, ഹോസ്റ്റിൽ നിന്ന് പുറത്തേക്ക് നയം സഞ്ചരിച്ച്, കൗണ്ടറുകൾ ചലിക്കുന്ന ഒരേയൊരു പാളി ശ്രദ്ധിക്കുക:

ss -ltn | grep ':443'
sudo nft list ruleset
sudo iptables -S INPUT
sudo ufw status verbose

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

പുറത്തുനിന്ന് ഊഹിക്കുന്നതിനു പകരം സംശയിക്കുന്ന പ്രൊഫൈലിനോ ചെയിനിനോ ലോഗിംഗ് ഓണാക്കുക. സ്രോതസ്സ്, ലക്ഷ്യം, പോർട്ട് എന്നിവ പേരിടുന്ന ഒരു രേഖപ്പെടുത്തിയ ഉപേക്ഷ പാളിയും നിയമവും തിരിച്ചറിയുന്നു, പാക്കറ്റ് എത്തിയെന്നും തെളിയിക്കുന്നു, ഇത് ക്ലയന്റ് ഭാഗത്തെ ഏതൊരു പരീക്ഷണവും സ്ഥാപിക്കാനാവില്ല.

ടണൽ അവിടെ അവസാനിക്കുമ്പോൾ ഗേറ്റ്വേയുടെ തീരുമാനം വായിക്കുക

സൈറ്റ്-ടു-സൈറ്റ് അല്ലെങ്കിൽ റിമോട്ട് ആക്സസ് ഗേറ്റ്വേയിൽ, VPN ഉപയോക്താവിനെ പ്രാമാണീകരിക്കുന്നു, നയം റിസോഴ്സ് അധികാരപ്പെടുത്തുന്നു, ഇവ വെവ്വേറെ അനുമതികളാണ്. ടണലിൽ പ്രവേശനം ലഭിച്ച ഉപയോക്താവിന് ഓരോ ആന്തരിക ഹോസ്റ്റിലും സ്വയമേവ പ്രവേശനമില്ല, നിരസിക്കൽ പലപ്പോഴും ടണൽ തന്നെ ആരോഗ്യകരമായിരിക്കെ ഫോർവേഡിംഗ് നിയമത്തിൽ നിന്ന് വരുന്നു. അതേ വേർതിരിവ് IPsec-ലും കാണുന്നു, അവിടെ ട്രാഫിക് തിരഞ്ഞെടുക്കുന്ന സുരക്ഷാ നയം അത് അനുവദിക്കുന്ന ഫിൽട്ടറിൽ നിന്ന് വ്യത്യസ്തമാണ്, അതുകൊണ്ടാണ് രണ്ടും വ്യത്യസ്ത സംവിധാനങ്ങളായി RFC 4301.

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

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

ഏറ്റവും ഇടുങ്ങിയ പാളി മാറ്റുക, പിന്നെ പരിശോധിക്കുക

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

പരാജയപ്പെട്ട അതേ പരീക്ഷണത്തിൽ, അതേ ക്ലയന്റിൽ നിന്ന് പരിശോധിക്കുക, പിന്നെ വീണ്ടും കണക്ട് ചെയ്ത ശേഷം ഒരിക്കൽ കൂടി, കാരണം ടണൽ വീണ്ടും ചർച്ച ചെയ്യുന്നതിന് മുൻപ് പൊരുത്തപ്പെട്ട നിയമം അതിന് ശേഷം പൊരുത്തപ്പെടാതെ ആകാം:

nc -vz 10.20.4.15 443
curl -v --max-time 5 https://10.20.4.15/

അത് അടയ്ക്കുന്നതിന് മുൻപ്:

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