nftables OpenVPN ക്ലയന്റുകൾക്കിടയിലെ ട്രാഫിക് എന്തുകൊണ്ട് കാണാൻ കഴിയുന്നില്ല
പിയറുകൾക്കിടയിലെ ട്രാഫിക് VPN പ്രക്രിയയ്ക്കുള്ളിൽ തന്നെ എത്തിക്കുന്നു, അതിനാൽ ഫോർവേഡ് കൗണ്ടറുകൾ ഒരിക്കലും നീങ്ങുന്നില്ല. അത് എണ്ണാൻ കേർണൽ പാതയും പ്രക്രിയ പാതയും തമ്മിൽ തിരഞ്ഞെടുക്കണം.
ഒരേ സർവറിലെ രണ്ട് ക്ലയന്റുകൾ ഫയലുകൾ കൈമാറുന്നു, കൈമാറ്റം വിജയിക്കുന്നു, എന്നാൽ ടണലിനു നേരെ ചൂണ്ടുന്ന ഓരോ ഫോർവേഡ് നിയമവും പൂജ്യം പാക്കറ്റ് റിപ്പോർട്ട് ചെയ്യുന്നു. നിയമങ്ങൾ തകർന്നിട്ടില്ല, ചെയിൻ തെറ്റായ സ്ഥലത്തുമല്ല. പിയർ-ടു-പിയർ ഫോർവേഡിംഗ് സജീവമാകുമ്പോൾ പാക്കറ്റ് സർവർ പ്രക്രിയയ്ക്കുള്ളിൽ തന്നെ എത്തിക്കുന്നു, ഹോസ്റ്റ് സ്റ്റാക്ക് ഒരിക്കലും റൗട്ടർ ആകുന്നുമില്ല, അതിനാൽ കേർണൽ ഫയർവാളിന് എണ്ണാൻ ഒന്നുമില്ല. ഈ വിഭജനം മനസ്സിലാക്കുന്നതാണ് ഷോർട്ട്കട്ട് നിലനിർത്തണോ കേർണൽ വഴി പാത പുനർനിർമ്മിക്കണോ എന്ന് തീരുമാനിക്കുന്നത്.
സർവറിലൂടെ ഒരു പാക്കറ്റ് പിന്തുടരുക
റൗട്ട് ചെയ്ത ടണലിൽ ഡീമൺ ഓരോ ക്ലയന്റിന്റെയും ഡീക്രിപ്റ്റ് ചെയ്ത പാക്കറ്റ് ടണൽ ഉപകരണത്തിന് നൽകുന്നു. അവിടെ നിന്ന് ഹോസ്റ്റ് അത് റൗട്ട് ചെയ്യുന്നു, ഫോർവേഡ് ഹുക്ക് പ്രവർത്തിക്കുന്നു, ടണൽ ഉപകരണവുമായി പൊരുത്തപ്പെടുന്ന ഒരു നിയമത്തിന് ട്രാഫിക് എണ്ണാനോ ഉപേക്ഷിക്കാനോ കഴിയും. മിക്ക ഫയർവാൾ ഉദാഹരണങ്ങളും അനുമാനിക്കുന്ന പാതയാണിത്.
| Forwarding path | Who decides | What the host firewall sees |
|---|---|---|
| Kernel routing between clients | Host routing table and forward rules | Every inner packet, with interface names |
| Peer forwarding inside the server process | The VPN daemon's own peer table | Only the outer encrypted transport |
ഷോർട്ട്കട്ട് ഹോസ്റ്റിനെ നടുവിൽ നിന്ന് നീക്കുന്നു. ഒരു സെഷന്റെ ഡീക്രിപ്റ്റ് ചെയ്ത പാക്കറ്റ് ഡീമണിനുള്ളിൽ മറ്റൊരു സെഷന് നൽകുന്നു, ആന്തരിക പാക്കറ്റ് ഒരിക്കലും ടണൽ ഉപകരണത്തിൽ പുറപ്പെടുന്നില്ല, ഹോസ്റ്റ് അത് റൗട്ട് ചെയ്യുന്നുമില്ല. എൻകാപ്സുലേറ്റ് ചെയ്ത ട്രാഫിക് ഇപ്പോഴും ഭൗതിക ഇന്റർഫേസ് കടക്കുന്നു, അതിനാൽ പുറത്തുള്ള ക്യാപ്ചർ തിരക്കിലാണെന്ന് തോന്നുന്നു, എന്നാൽ ആന്തരിക നിയമങ്ങൾ നിശബ്ദമാണ്. ടണൽ ഉപകരണത്തിൽ എടുത്ത ക്യാപ്ചർ ഒന്നും കാണിക്കുന്നില്ല, അവിടെ കൈമാറ്റം കാണാൻ പ്രതീക്ഷിക്കുന്നവരെ ഇത് അത്ഭുതപ്പെടുത്തുന്നു. ഡീമണിന് പുറത്തുനിന്ന് ഷോർട്ട്കട്ട് തിരിച്ചറിയാനുള്ള ഏറ്റവും വേഗതയേറിയ മാർഗം ഈ അസമത്വമാണ്.
ഏത് പാത പോയി എന്ന് തീരുമാനിക്കുന്ന കൗണ്ടർ പരിശോധന
ബാധകമാകേണ്ട നിയമത്തിൽ ഒരു കൗണ്ടർ ഘടിപ്പിക്കുക, ആ നിയമം തടയേണ്ട രണ്ട് ക്ലയന്റുകൾക്കിടയിൽ കൈമാറ്റം നടത്തുക, എന്നിട്ട് കൗണ്ടർ വായിക്കുക.
sudo nft list ruleset
sudo nft add rule inet filter forward iifname "tun0" oifname "tun0" counter accept
sudo nft list chain inet filter forwardകൈമാറ്റം വിജയിക്കുകയും കൗണ്ടർ പൂജ്യത്തിൽ തുടരുകയും ചെയ്താൽ, കേർണൽ ആ പാക്കറ്റുകൾ ഒരിക്കലും കൈകാര്യം ചെയ്തിട്ടില്ല, എത്ര നിയമം തിരുത്തിയാലും അത് മാറില്ല. അതേ പരിശോധന സർവറിലെ ഒരു സേവനത്തിനെതിരെ ആവർത്തിക്കുക, കാരണം ആ ഫ്ലോ ഹോസ്റ്റ് സ്റ്റാക്ക് കടക്കുന്നു, അതിന്റെ കൗണ്ടർ നീങ്ങുന്നു. രണ്ട് ഫലങ്ങൾ താരതമ്യം ചെയ്യുന്നതാണ് ഉത്തരം നൽകുന്നത്.
രണ്ട് വിശദാംശങ്ങൾ തെറ്റായ വായന തടയുന്നു. ചെയിൻ ലേബലിൽ എഴുതിയ ഇന്റർഫേസ് പേര് സ്വയം ഒന്നും ഫിൽട്ടർ ചെയ്യുന്നില്ല, കാരണം പൊരുത്തം നിയമങ്ങൾക്കുള്ളിലെ ഇന്റർഫേസ് ഫീൽഡുകളിലാണ് നടക്കുന്നത്. ബ്രിഡ്ജ് ചെയ്ത ലെയർ-2 രൂപകൽപ്പന വീണ്ടും വ്യത്യസ്തമായി പ്രവർത്തിക്കുന്നു: അവിടെ ക്ലയന്റുകൾ ഒരു ബ്രോഡ്കാസ്റ്റ് ഡൊമെയ്ൻ പങ്കിടുന്നു, അതിനാൽ പിയർ കണ്ടെത്തൽ പ്രതീക്ഷിക്കുന്നതാണ്, റൗട്ടിംഗ് തകരാറല്ല.
സ്വിച്ച് ഒരു ആക്സസ് ലിസ്റ്റല്ല
ഒരു ഉച്ചയ്ക്ക് ചെലവാക്കുന്ന ഭാഗമാണിത്. പിയർ ഫോർവേഡിംഗ് ഒരു ഓൺ-ഓഫ് ക്രമീകരണമാണ്, അത് ഓണായിരിക്കുമ്പോൾ ഡീമൺ മാത്രമാണ് ഫോർവേഡിംഗ് പോയിന്റ്. ഹോസ്റ്റ് ഫയർവാളിന് ആർക്ക് ആരെ എത്താം എന്ന് പറയാൻ കഴിയില്ല, ഓരോ ക്ലയന്റിന്റെയും ഫയലുകൾ സ്വിച്ചിനെ ഒരു നയ മാട്രിക്സാക്കി മാറ്റുന്നുമില്ല.
ഓരോ പിയറിനും നിയമങ്ങൾ വേണമെങ്കിൽ, തിരഞ്ഞെടുപ്പ് ഷോർട്ട്കട്ട് ഉപേക്ഷിക്കുന്നതും നിയന്ത്രണമെന്ന നിലയിൽ ഹോസ്റ്റ് ഫയർവാൾ ഉപേക്ഷിക്കുന്നതും തമ്മിലാണ്. അത് ഓഫ് ചെയ്യുന്നത് കേർണൽ ഫോർവേഡിംഗ് പുനഃസ്ഥാപിക്കുന്നു, അതിന് സർവറിൽ IP ഫോർവേഡിംഗ് സജീവമാക്കണം, ആവശ്യമുള്ള ഫ്ലോകൾക്ക് വ്യക്തമായ നിയമങ്ങളും വേണം. ഓണായി വെക്കുന്നത് നയം ഡീമണിന്റെ കോൺഫിഗറേഷനിൽ ജീവിക്കുന്നു എന്നാണ് അർത്ഥമാക്കുന്നത്, അത് പ്രായോഗികമായി എല്ലാ പിയറുകളും അല്ലെങ്കിൽ ഒരു പിയറുമില്ല എന്നതാണ്.
സ്വന്തം വിലാസ പൂളുകളും പോർട്ടുകളുമുള്ള വേറിട്ട സർവർ പ്രക്രിയകളാണ് പ്രായോഗികമായ മധ്യമാർഗം. ഓരോ പ്രക്രിയയും കൃത്യം ഒരു ആക്സസ് തീരുമാനം വഹിക്കുന്നു, അതിനാൽ രണ്ട് ഗ്രൂപ്പുകൾക്ക് നയ മാട്രിക്സ് ഇല്ലാതെ വ്യത്യസ്ത നിയമങ്ങൾ ഉണ്ടാകാം. ഉദ്ദേശിക്കുമ്പോൾ ഹോസ്റ്റിന് പൂളുകൾക്കിടയിൽ റൗട്ട് ചെയ്യാം, അപ്പോൾ ഫയർവാൾ ആ ഫ്ലോകൾ കാണുന്നു, കാരണം അവ ഹോസ്റ്റ് കടക്കുന്നു. വില അധിക പോർട്ടുകൾ, അധിക സർട്ടിഫിക്കറ്റുകൾ, ഓരോ ഗ്രൂപ്പിനും ഒരു പ്രൊഫൈൽ എന്നിവയാണ്.
ഫോർവേഡിംഗ് പോയിന്റ് തിരഞ്ഞെടുക്കൽ
ഫയർവാൾ നയ എഞ്ചിൻ ആയിരിക്കുമ്പോൾ, ഓരോ ഫ്ലോയ്ക്കും ലോഗിംഗ് വേണമ്പോൾ, അല്ലെങ്കിൽ അക്കൗണ്ടിംഗ് പ്രധാനമാകുമ്പോൾ കേർണൽ ഫോർവേഡിംഗ് തിരഞ്ഞെടുക്കുക. വില ഹോസ്റ്റ് സ്റ്റാക്കിലൂടെയുള്ള ത്രൂപുട്ടും പരിപാലിക്കാനുള്ള കൂടുതൽ നിയമങ്ങളുമാണ്. നേട്ടം, കൗണ്ടറുകൾ മുതൽ ഫ്ലോ എക്സ്പോർട്ടർമാർ വരെയുള്ള ഓരോ നിലവിലുള്ള ഉപകരണവും ട്രാഫിക്കിനെ വീണ്ടും വിവരിക്കുന്നു എന്നതാണ്. ചെറിയ സർവറിൽ ഈ വില അദൃശ്യമാണ്; തിരക്കുള്ള റിലേയിൽ അല്ല.
പിയർ ട്രാഫിക് പൂർണ്ണമായി അനുവദനീയമോ പൂർണ്ണമായി നിരോധിതമോ ആയിരിക്കുകയും സർവർ അതിന് അളക്കപ്പെട്ടതുമാകുമ്പോൾ പ്രക്രിയയ്ക്കുള്ളിലെ ഫോർവേഡിംഗ് തിരഞ്ഞെടുക്കുക. വില, കൗണ്ടറുകളും ക്യൂ അനുശാസനങ്ങളും കണക്ഷൻ ട്രാക്കിംഗും ഇനി ആന്തരിക ഫ്ലോകളെ വിവരിക്കുന്നില്ല എന്നതാണ്; പിന്നീട് ആരും അവയെ ആശ്രയിക്കുന്നില്ലെങ്കിൽ മാത്രമേ ഇത് സ്വീകാര്യമാകൂ.
ഏത് തിരഞ്ഞെടുത്താലും അത് ഫയർവാൾ നിയമങ്ങൾക്കൊപ്പം എഴുതിവെക്കുക. പിയർ ട്രാഫിക് അനുവദിക്കുന്നതായി തോന്നുന്നതും എന്നാൽ യഥാർത്ഥത്തിൽ ഡീമൺ തീരുമാനിക്കുന്നതുമായ നിയമക്കൂട്ടം, പരാജയപ്പെട്ട കൈമാറ്റം ഡീബഗ് ചെയ്യുന്ന അടുത്ത വ്യക്തിയെ തെറ്റായി നയിക്കുന്നു. നിയമങ്ങൾ മാത്രം വായിക്കുന്ന ആരും കേർണൽ ആണ് കവാടം എന്ന് കരുതും.
നിയമങ്ങൾ മാറ്റുന്നതിന് മുൻപ് എന്ത് പരിശോധിക്കണം
സർവർ യഥാർത്ഥത്തിൽ ലോഡ് ചെയ്ത കോൺഫിഗറേഷൻ വായിക്കുക, നിങ്ങൾ തിരുത്തിയതായി ഓർക്കുന്ന ഫയലല്ല, പിയർ ഓപ്ഷൻ ഉണ്ടോ എന്ന് ഉറപ്പാക്കുക. നിങ്ങൾ അത് മാറ്റിയെങ്കിൽ, സേവനം ഡിസ്കിലെ ഫയൽ വീണ്ടും എഴുതിയതല്ല, പുനഃലോഡ് ചെയ്തതാണ് എന്ന് ഉറപ്പാക്കുക.
തുടർന്ന് നിയമം എങ്ങനെയെങ്കിലും പൊരുത്തപ്പെടുന്നു എന്ന് തെളിയിക്കാൻ ക്ലയന്റിൽ നിന്ന് സർവറിലേക്കുള്ള ഫ്ലോയോടെ പരിശോധന ആവർത്തിക്കുക, തള്ളിവിട്ട റൂട്ടുകളും പരിശോധിക്കുക, കാരണം ഇല്ലാത്ത റൂട്ട് ക്ലയന്റിന്റെ ഭാഗത്തുനിന്ന് കൃത്യമായി ഫയർവാൾ തടയലിനെപ്പോലെ തോന്നുന്നു. ഏത് ഫോർവേഡിംഗ് പോയിന്റിനാണ് തീരുമാനം എന്ന് അറിഞ്ഞതിന് ശേഷം മാത്രം നിയമങ്ങളുടെ ക്രമം മാറ്റുക.