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

പങ്കിട്ട സേവനത്തിലേക്കുള്ള റൂട്ട് പിയറുകൾക്കിടയിലെ അനുമതിയല്ല

ക്ലയന്റ് സബ്നെറ്റ് പ്രഖ്യാപിക്കുന്നത് മറ്റൊരു ക്ലയന്റിന്റെ വിലാസത്തിലേക്ക് പാക്കറ്റ് എങ്ങനെ വയറിൽ വയ്ക്കണം എന്ന് പിയറിനോട് പറയുന്നു. ആ പാക്കറ്റ് എത്തുമോ എന്നത് പിന്നീട് അത് ഫോർവേഡ് ചെയ്യുന്നതിനാൽ തീരുമാനിക്കപ്പെടുന്നു. Linux ഗേറ്റ്വേയിൽ അത് FORWARD ശൃംഖലയാണ്; ഉപയോക്തൃ സ്ഥലത്തെ ഡീമണിനുള്ളിൽ അത് ടണലിന്റെ സ്വന്തം സെഷൻ പട്ടികയാണ്. റൂട്ട് എത്തിച്ചേരാനുള്ള കഴിവിന് ഉത്തരം നൽകുന്നു, അനുമതിയെ തൊടാതെ വിടുന്നു.

അതുകൊണ്ട് റൂട്ടുകൾ മാത്രം വായിക്കുന്ന ഐസൊലേഷൻ പരിശോധന ഒന്നും തെളിയിക്കുന്നില്ല. /24 ഓരോ ക്ലയന്റിനും അയക്കാം, അതേസമയം പിയറുകൾക്കിടയിലുള്ള ഓരോ പാക്കറ്റും ഫോർവേഡ് കൊളുത്തിൽ ഉപേക്ഷിക്കപ്പെടുന്നു. അപകടകരമായ സാഹചര്യം വിപരീതമാണ്: വ്യക്തമായ നിയമമില്ല, അനുവദിക്കുന്ന സ്ഥിരമൂല്യമുണ്ട്, ആരും പരിശോധിക്കാത്തതുകൊണ്ട് മാത്രം നിലനിൽക്കുന്ന ഐസൊലേഷനുമുണ്ട്.

ടെർമിനൽ തുറക്കുന്നതിന് മുൻപ് ആവശ്യകത ഒരു വരിയിൽ എഴുതുക. സേവന ബ്ലോക്കിലേക്കും ജമ്പ് ഹോസ്റ്റിലേക്കും എത്തുക, ക്ലയന്റ് ബ്ലോക്കിനുള്ളിൽ മറ്റൊന്നിലേക്കും എത്തരുത്.

പിയർ പാക്കറ്റ് യഥാർത്ഥത്തിൽ ആരാണ് ഫോർവേഡ് ചെയ്യുന്നതെന്ന് കണ്ടെത്തുക

സെർവറിന്റെ രണ്ട് സ്വഭാവങ്ങൾ ക്ലയന്റ് വശത്തുനിന്ന് ഒരുപോലെ കാണപ്പെടുന്നു, വ്യത്യസ്ത നിയമങ്ങൾ ആവശ്യപ്പെടുന്നു. ഒന്നുകിൽ കേർണൽ പാക്കറ്റ് വീണ്ടും ടണൽ ഇന്റർഫേസിൽ നിന്ന് ഫോർവേഡ് ചെയ്യുന്നു, അല്ലെങ്കിൽ ഡീമൺ അത് സെഷനുകൾക്കിടയിൽ പകർത്തുന്നു, കേർണൽ അത് ഒരിക്കലും കാണുന്നില്ല.

WireGuard ആദ്യ ഗ്രൂപ്പിലാണ്: അതിൽ പിയർ-ടു-പിയർ സ്വിച്ചില്ല, അതിനാൽ 10.8.0.4 മുതൽ 10.8.0.5 വരെയുള്ള പാക്കറ്റ് wg0-ൽ എത്തി, ഫോർവേഡ് കൊളുത്തിൽ തട്ടി, AllowedIPs രണ്ട് വിലാസങ്ങളും ഉൾക്കൊള്ളുമ്പോൾ വീണ്ടും wg0-ൽ നിന്ന് റൂട്ട് ചെയ്യപ്പെടുന്നു. OpenVPN രണ്ടാം ഗ്രൂപ്പാണ്, സെർവർ കോൺഫിഗിൽ client-to-client സജ്ജമാക്കുമ്പോൾ, ആ നിർദ്ദേശം പാക്കറ്റ് ഉപയോക്തൃ സ്ഥലത്ത് സെഷനുകൾക്കിടയിൽ കൈമാറുന്നതിനാൽ. എന്തെങ്കിലും എഴുതുന്നതിന് മുൻപ് ലോഡ് ചെയ്ത കോൺഫിഗിൽ ആ നിർദ്ദേശം പരിശോധിക്കുക. ട്രാഫിക് ഒരിക്കലും കാണാത്ത കേർണൽ നിയമത്തെ പ്രവർത്തിക്കുന്ന നിയമത്തിൽ നിന്ന് വേർതിരിക്കാനാവില്ല, അങ്ങനെയാണ് ഒരു വിന്യാസം ഒരു ഐസൊലേഷനും ഇല്ലാതെ അവസാനിക്കുന്നത്.

ലോഡ് ചെയ്തതെന്ന് കരുതുന്ന ഫയലിനുപകരം ഫലപ്രദമായ കോൺഫിഗ് വായിക്കുക, കാരണം ഡിസ്ട്രോ പാക്കേജുകൾ സ്വന്തം ഉൾപ്പെടുത്തലുകൾ കൊണ്ടുവരുന്നു. ഡീമൺ ഫോർവേഡ് ചെയ്യുന്നെങ്കിൽ, വിലക്ക് അതിന്റെ സ്വന്തം പ്രതി-ക്ലയന്റ് നിയന്ത്രണങ്ങളിലാണ്, ഹോസ്റ്റ് ഫയർവാൾ ഹോസ്റ്റിലേക്ക് അയച്ച ട്രാഫിക് മാത്രം ഫിൽട്ടർ ചെയ്യുന്നു. കേർണൽ ഫോർവേഡ് ചെയ്യുന്നെങ്കിൽ, ഫോർവേഡ് കൊളുത്ത് മാത്രമാണ് പ്രധാനം.

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

ഓരോ വിലാസത്തിനും സ്വതന്ത്രമായി റദ്ദാക്കാവുന്ന ഐഡന്റിറ്റി നൽകുക

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

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

പാക്കറ്റ് ടണൽ കടക്കുന്നിടത്ത് വിലക്ക് വയ്ക്കുക

WireGuard ട്രാഫിക് ഫോർവേഡ് ചെയ്യുന്ന ഗേറ്റ്വേയിൽ രണ്ട് നിയമങ്ങൾ കേസ് ഉൾക്കൊള്ളുന്നു: സേവന ബ്ലോക്ക് അനുവദിക്കുക, പിന്നെ ക്ലയന്റ് ബ്ലോക്കിന്റെ ബാക്കി ഉപേക്ഷിക്കുക. ഇന്റർഫേസ് ജോടി വിലാസങ്ങളോളം പ്രധാനമാണ്, കാരണം ലക്ഷ്യസ്ഥാനത്ത് മാത്രം പൊരുത്തപ്പെടുന്നത് LAN-ൽ നിന്ന് വരുന്ന ട്രാഫിക്കിനെയും പിടിക്കുന്നു. അനുമതി ആദ്യം വിലയിരുത്തപ്പെടാൻ അവ ആ ക്രമത്തിൽ ലോഡ് ചെയ്യുക.

nftables-ൽ ജോടി നിലവിലുള്ള inet filter പട്ടികയിലേക്ക് പോകുന്നു, ആദ്യം അനുമതി, പിന്നെ ഉപേക്ഷിക്കൽ. രണ്ട് പൊരുത്തങ്ങളും വിലാസങ്ങൾക്കൊപ്പം ഇന്റർഫേസ് ജോടിയും പിന്ന് ചെയ്യുന്നു.

nft add rule inet filter forward iifname "wg0" oifname "wg0" ip saddr 10.8.0.0/24 ip daddr 10.8.2.0/24 accept
nft add rule inet filter forward iifname "wg0" oifname "wg0" ip saddr 10.8.0.0/24 ip daddr 10.8.0.0/24 drop

ലോഡ് ചെയ്തതിന് ശേഷം എക്സിറ്റ് സ്ഥിതിയെ വിശ്വസിക്കുന്നതിനുപകരം ശൃംഖല വീണ്ടും വായിക്കുക, രണ്ട് നിയമങ്ങളും ഉദ്ദേശിച്ച ക്രമത്തിലാണെന്ന് ഉറപ്പാക്കുക. IPv6 പൂളിനായി പൊരുത്തപ്പെടുന്ന ip6 നിയമങ്ങൾ ചേർക്കുക, അല്ലെങ്കിൽ ഇരട്ട-സ്റ്റാക്ക് ടണലിൽ v4 ജോടി വെറും അലങ്കാരമാണ്. സെർവറിൽ ഇതിനകം അനുവദിക്കുന്ന ഫോർവേഡ് നയമുണ്ടെങ്കിൽ, ശൃംഖല മുഴുവനായി മാറ്റുന്നതിനുപകരം ഉപേക്ഷിക്കൽ ചേർക്കുക.

OpenVPN-ൽ client-to-client സജീവമാകുമ്പോൾ, ഈ ഫോർവേഡ് നിയമങ്ങൾ പിയർ ട്രാഫിക്കുമായി ഒരിക്കലും പൊരുത്തപ്പെടുന്നില്ല, വിലക്ക് ഡീമണിന്റെ സ്വന്തം നിയന്ത്രണങ്ങളിൽ ജീവിക്കണം. ഹോസ്റ്റിലേക്ക് അയച്ച ട്രാഫിക്കിനായി കേർണൽ നിയമങ്ങൾ നിലനിർത്തുക, പക്ഷേ അവയെ ഐസൊലേഷൻ നിയന്ത്രണമായി കണക്കാക്കരുത്.

വിലക്ക് സെർവറിൽ നിന്നല്ല, ക്ലയന്റിൽ നിന്ന് തെളിയിക്കുക

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

അനുമതി ലഭിച്ച ക്ലയന്റിൽ നിന്ന് സേവനം അതിന്റെ പോർട്ടിൽ ഉത്തരം നൽകുന്നുവെന്ന് ഉറപ്പാക്കുക. അതേ ക്ലയന്റിൽ നിന്ന് പിയറിന്റെ വിലാസം പരീക്ഷിക്കുക, നിരസിക്കലിനുപകരം നിശ്ശബ്ദ ഉപേക്ഷിക്കൽ പ്രതീക്ഷിക്കുക:

ping -c 3 -W 2 10.8.0.5
nc -z -w 2 10.8.0.5 22
nft list chain inet filter forward
iptables -vnL FORWARD
ping -6 -c 3 -W 2 fd00:8::5

ഉപേക്ഷിച്ച പാക്കറ്റും ഓഫ്ലൈൻ പിയറും രണ്ടും സമയപരിധി കഴിഞ്ഞതുപോലെ തോന്നുന്നു, അതിനാൽ എന്തെങ്കിലും തീരുമാനിക്കുന്നതിന് മുൻപ് കൗണ്ടറുകൾ പരിശോധിക്കുക. പിയർ വ്യക്തമായി പ്രവർത്തിക്കുമ്പോൾ ഉപേക്ഷിക്കൽ നിയമത്തിന്റെ കൗണ്ടർ കൂടുന്നുവെന്ന് ഉറപ്പാക്കുക. IPv6-ൽ ആവർത്തിക്കുക, അവിടെ ഇല്ലാത്ത ip6 നിയമം v4 വിലക്ക് ഫലപ്രദമായി കാണിക്കുന്നു. സ്വീകരിച്ചതും നിരസിച്ചതുമായ ഫലങ്ങൾ തീയതിയോടെ റൺബുക്കിൽ രേഖപ്പെടുത്തുക, കാരണം അടുത്ത മാറ്റം നിയമം വീണ്ടും കണ്ടെത്തും.

അനുബന്ധ ലേഖനങ്ങൾ