OpenVPN കണക്ട് ചെയ്യുന്നു പക്ഷേ ഒന്നും ഒഴുകുന്നില്ല: പാക്കറ്റ് വീഴുന്ന പാളി കണ്ടെത്തുക

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

സോക്കറ്റ് ബന്ധിച്ചിരിക്കുന്നു അല്ലെങ്കിൽ ഇല്ല

സജീവമാണെന്ന് റിപ്പോർട്ട് ചെയ്യുന്ന സേവനത്തിന് ഇപ്പോഴും നിങ്ങൾ ഉദ്ദേശിക്കാത്ത ഒരു വിലാസത്തിലോ ഗതാഗതത്തിലോ ബന്ധിതമായിരിക്കാം. സോക്കറ്റിനോട് തന്നെ ചോദിക്കുക: ss -lunp UDP ലിസണർമാരെയും ss -ltnp TCP ലിസണർമാരെയും പട്ടികപ്പെടുത്തുന്നു, വായിക്കാൻ യോഗ്യമായ കോളം ലോക്കൽ വിലാസമാണ്, അവസ്ഥയല്ല.

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

ss -lunp | grep 1194
ss -ltnp | grep 1194

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

പുറം പാക്കറ്റ് ക്യാപ്ചർ ചെയ്യുക, ടണൽ അല്ല

ഭൗതിക ഇന്റർഫേസിലും യഥാർത്ഥ പോർട്ടിലും ഫിൽട്ടർ ചെയ്യുക, നിങ്ങളുടെ ഇന്റർഫേസ് മാറ്റിവെച്ച്: tcpdump -ni eth0 udp port 1194. തിരികെ ഒന്നും വരാത്ത പുറത്തേക്കുള്ള പാക്കറ്റുകൾ മുകളിലുള്ളതിനെ സൂചിപ്പിക്കുന്നു: പ്രൊവൈഡർ ഫിൽട്ടറിംഗ്, ഒരു NAT ഉപകരണം, അല്ലെങ്കിൽ നിങ്ങൾ കരുതുന്നതിൽ നിന്ന് വ്യത്യസ്തമായ ഒരു ദൂര വിലാസം. രണ്ട് ദിശകളിലുമുള്ള നിശ്ശബ്ദത ക്ലയന്റ് റൂട്ടിംഗിനെയോ ലോക്കൽ ഫയർവാളിനെയോ സൂചിപ്പിക്കുന്നു. ടണൽ പുരോഗതിയില്ലാതെ വരുന്ന മറുപടികൾ നിയന്ത്രണ ചാനലിനെ സൂചിപ്പിക്കുന്നു, അതായത് കീ അല്ലെങ്കിൽ സൈഫർ പൊരുത്തക്കേട്, ഫിൽട്ടറിംഗിനെ അല്ല.

രണ്ട് ദിശകളും ക്യാപ്ചർ ചെയ്യുക, ഫയൽ ചെറുതായി സൂക്ഷിക്കുക. നീണ്ട ക്യാപ്ചർ താൽപ്പര്യമുള്ള മൂന്ന് സെക്കൻഡുകൾ കുഴിച്ചിടുന്നു, ഉത്തരം മിക്കവാറും എപ്പോഴും ആദ്യ കൈമാറ്റത്തിലാണ്.

ആദ്യം കൗണ്ടറുകൾ, ട്രെയ്സ് അവ കള്ളം പറയുമ്പോൾ മാത്രം

കൗണ്ടറുകളിൽ നിന്ന് തുടങ്ങുക, കാരണം അവ ഒന്നും ചെലവാക്കുന്നില്ല. nft list ruleset അല്ലെങ്കിൽ iptables -L -n -v ഇവിടെ പ്രധാനമായ ഏക ചോദ്യത്തിന് ഉത്തരം നൽകുന്നു: നിയമം പൊരുത്തപ്പെട്ടോ? ക്രമം ഫലം നിർണ്ണയിക്കുന്നു, ആദ്യ പൊരുത്തം വിജയിക്കുന്നു, അതിനാൽ പിന്നീടുള്ള ACCEPT-ന് മുൻപ് വിശാലമായ DROP ആ ACCEPT-നെ മരിച്ചതായി വിടുന്നു, അതിനാൽ ഒരു നിയമം ചേർക്കുന്നത് അത്ര അപൂർവമായി മാത്രം എന്തെങ്കിലും ശരിയാക്കുന്നു.

ഉടമസ്ഥതയും ആളുകളെ വീഴ്ത്തുന്നു. കെർണൽ പ്രാദേശികമായി സൃഷ്ടിച്ച പാക്കറ്റുകളെ സോക്കറ്റ് തുറന്ന പ്രക്രിയയ്ക്ക് ആരോപിക്കുന്നു, OpenVPN സാധാരണയായി root ആയി പ്രവർത്തിക്കുന്നു, അതിനാൽ സാധാരണ ഉപയോക്തൃ ID-യിൽ ബന്ധിച്ച ഒരു നിയമം ടണലിന്റെ സ്വന്തം ട്രാഫിക് ഒരിക്കലും കാണുന്നില്ല. നിയമം തെറ്റാണെന്ന് തീരുമാനിക്കുന്നതിന് മുൻപ് ഉടമയുടെ UID പരിശോധിക്കുക.

കൗണ്ടറുകൾ അവ്യക്തമായി തുടരുമ്പോൾ മാത്രമേ ലോഗ് ബഹളത്തിന് അർഹമാകൂ, അപ്പോഴും ഇടുങ്ങിയ ഒരു ഭാഗത്തിന് മാത്രം: നിരക്ക് പരിമിതപ്പെടുത്തി സ്വന്തം ലോഗ് വരികൾക്ക് പ്രിഫിക്സ് ചേർക്കുന്ന iptables നിയമം, അല്ലെങ്കിൽ nft monitor trace പ്രവർത്തിക്കുമ്പോൾ meta nftrace set 1 വഹിക്കുന്ന nftables നിയമം. ട്രെയ്സ് പാക്കറ്റ് സ്വീകരിച്ചതോ ഉപേക്ഷിച്ചതോ ആയ ചെയിനിനെയും നിയമത്തെയും പേരിടുന്നു. പിന്നീട് രണ്ടും നീക്കം ചെയ്യുക, പേലോഡ് ലോഗിംഗ് പുറത്ത് നിർത്തുക.

ഗതാഗതവും പരിശോധിക്കുക. TCP-യിൽ പരിമിതപ്പെടുത്തിയ ഫയർവാൾ സേവനം ആ നമ്പറിലെ UDP ലിസണറിനെക്കുറിച്ച് ഒന്നും പറയുന്നില്ല, അതിനാൽ ശരിയായി വായിക്കുന്ന ഒരു നിയമവും ഓരോ പാക്കറ്റും ഉപേക്ഷിച്ചേക്കാം.

റൂട്ടിംഗും തിരിച്ചുള്ള വഴിയും

സ്വീകരിച്ചിട്ടും അപ്രത്യക്ഷമാകുന്ന പാക്കറ്റിന്റെ ലക്ഷ്യവഴി പരിശോധിക്കണം. ip route get ഒരു വിലാസത്തിനായി തിരഞ്ഞെടുത്ത റൂട്ട് റിപ്പോർട്ട് ചെയ്യുന്നു, വിപരീത വഴി ഫിൽട്ടറിംഗ് പ്രധാന പട്ടിക ഒരിക്കലും തിരഞ്ഞെടുക്കാത്ത ഒരു ഇന്റർഫേസിലൂടെ വരുന്ന മറുപടി ഉപേക്ഷിച്ചേക്കാം. ലക്ഷണം കൃത്യമായി ഫയർവാൾ ഉപേക്ഷിച്ചതുപോലെ തോന്നുന്നു, അതിനാൽ ഈ പരിശോധന മറ്റൊരു NAT നിയമത്തിന് മുൻപ് വരുന്നു.

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

രേഖ എന്ത് പറയണം

ഓരോ മാറ്റത്തിനും, പരിശോധിച്ച ഘട്ടം, വായിച്ച തെളിവ്, അതിന്റെ ഇരുവശത്തുമുള്ള കൗണ്ടർ മൂല്യം എന്നിവ എഴുതുക. ആ കുറിപ്പാണ് "ഇപ്പോൾ അത് പ്രവർത്തിക്കുന്നു" എന്നതിനെ അടുത്ത അവലോകനത്തിൽ നിലനിർത്തുന്നത്.

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