നെസ്റ്റഡ് WireGuard: മധ്യ ഹോപ്പിന് സ്വന്തം പോർട്ടിൽ ഉത്തരം നൽകാനാകില്ല
മധ്യ ഹോപ്പ് എല്ലാം ഒരു ടണലിലേക്ക് അയയ്ക്കുമ്പോൾ, അതിന്റെ ഇൻബൗണ്ട് സേവനത്തിനുള്ള മറുപടികൾ തെറ്റായ വഴിയിലൂടെ പുറത്തുപോകുന്നു. ഇന്റർഫേസിലെ സോഴ്സ്-പോർട്ട് നിയമം അത് ശരിയാക്കുന്നു.
മൂന്ന് WireGuard ഹോപ്പുകൾ പൊതു വിലാസമില്ലാത്ത ഒരു നെറ്റ്വർക്കിൽ എത്തുന്നു, പിന്നീട് മധ്യ യന്ത്രം കേൾക്കേണ്ടിയിരുന്ന പോർട്ടിൽ മറുപടി നൽകുന്നത് നിർത്തുന്നു. മുന്നോട്ടുള്ള ടണൽ ഇപ്പോഴും പ്രവർത്തിക്കുന്നു, ദൂരെയുള്ള ഹോസ്റ്റ് ഇപ്പോഴും പ്രതികരിക്കുന്നു, പുറത്തുനിന്ന് നിശബ്ദമായത് മധ്യ സർവറിന്റെ സ്വന്തം മാത്രം. ഈ സംയോജനം ആശയക്കുഴപ്പമുണ്ടാക്കുന്നത് അത് സ്വയം സൃഷ്ടിച്ചത് കൊണ്ടു തന്നെയാണ്: മധ്യ ഹോപ്പ് സ്വന്തം റൗട്ടിംഗ് പട്ടിക അനുസരിക്കുന്നു, ആ പട്ടിക അതിന്റെ മറുപടികൾ തെറ്റായ ദിശയിലേക്ക് അയയ്ക്കുന്നു.
മധ്യ പെട്ടിയോട് സംസാരിക്കുന്നതുവരെ പ്രവർത്തിക്കുന്ന ശൃംഖല
ഒരു ഉദാഹരണ ശൃംഖല എടുക്കാം: ക്ലയന്റ് A UDP 500-ൽ സെർവർ B-യിൽ എത്തുന്നു, B UDP 500-ൽ സെർവർ C-യിലേക്ക് മുന്നോട്ടുപോകുന്നു. C തന്റെ ഏക പിയറിന്റെ വിലാസത്തിൽ നിന്ന് മാത്രം ട്രാഫിക് സ്വീകരിക്കുന്നു, ഇത് അതിനെ ഒരു ഇലയാക്കി അതിന്റെ സ്വഭാവം ലളിതമായി നിലനിർത്തുന്നു. B ഇലയല്ല, ഈ പരാജയത്തിലെ എല്ലാ രസകരമായ കാര്യങ്ങളും അവിടെ സംഭവിക്കുന്നു.
ഈ വ്യത്യാസം പ്രധാനമാണ്, കാരണം ഇലയുടെയും മധ്യത്തിന്റെയും റോളുകൾ വിപരീത ദിശകളിലേക്ക് വലിക്കുന്നു. ഇലയ്ക്ക് പരിണാമമില്ലാതെ എല്ലാം ഒരു ടണലിലേക്ക് അയയ്ക്കാം, കാരണം മറ്റൊന്നും അതിനെ ആശ്രയിക്കുന്നില്ല. മധ്യ ഹോപ്പ് ഒരേസമയം ക്ലയന്റുകൾക്കുള്ള അന്തിമ പോയിന്റും ദൂരെയുള്ള വശത്തേക്കുള്ള ക്ലയന്റുമാണ്, ആ രണ്ട് ജോലികൾക്ക് വ്യത്യസ്ത റൗട്ടിംഗ് വേണം.
മറുപടി ടണലിലൂടെ പുറത്തുപോകുന്നത് എന്തുകൊണ്ട്
B-യിൽ, C-യിലേക്കുള്ള ഇന്റർഫേസ് അനുബന്ധ ഡിഫോൾട്ട് റൂട്ടിനൊപ്പം AllowedIPs = 0.0.0.0/0 വഹിക്കുന്നു. അതിനാൽ B സൃഷ്ടിക്കുന്ന ഓരോ പാക്കറ്റും ആ ടണലിലേക്ക് പോകുന്നു, കൂടുതൽ നിർദ്ദിഷ്ടമായ എന്തെങ്കിലും മുൻഗണന നേടിയില്ലെങ്കിൽ.
A-യിൽ നിന്ന് B-യിലേക്ക് അഡ്രസ് ചെയ്ത പാക്കറ്റ് എത്തി സ്വീകരിക്കപ്പെടുന്നു, കാരണം B ലക്ഷ്യസ്ഥാനമാണ്, പ്രാദേശിക ഡെലിവറി ആദ്യം നടക്കുന്നു. മറുപടി A-യുടെ പൊതു വിലാസത്തിലേക്ക് ലക്ഷ്യമിട്ട, പ്രാദേശികമായി സൃഷ്ടിച്ച തികച്ചും പുതിയ പാക്കറ്റാണ്, ആ ലക്ഷ്യസ്ഥാനം ടണലിലേക്കുള്ള ഡിഫോൾട്ട് റൂട്ടുമായി യോജിക്കുന്നു. C അത് സ്വീകരിക്കുന്നു, ആ വിലാസത്തിന്റെ ഉടമയല്ല, അത് ഉപേക്ഷിക്കുന്നു.
ലക്ഷണം ഫയർവാൾ പ്രശ്നമായോ കീ പൊരുത്തക്കേടായോ വായിക്കപ്പെടുന്നു, ഇവിടെ രണ്ടും ശരിയല്ല. C-യിലേക്കുള്ള ടണലിലെ ക്യാപ്ചർ മറുപടികൾ തെറ്റായ ദിശയിലേക്ക് പോകുന്നത് കാണിക്കുന്നു. ആ ഒരു നിരീക്ഷണം എത്ര കോൺഫിഗറേഷൻ വായിക്കുന്നതിനേക്കാളും സമയം ലാഭിക്കുന്നു, അതിനാൽ കീകൾ മാറ്റിത്തുടങ്ങുന്നതിന് മുൻപ് അത് എഴുതിവയ്ക്കുക. ക്യാപ്ചർ കാണാത്തവർ ടണൽ തന്നെ തകർന്നതാണെന്ന് കരുതും.
ഇടുങ്ങിയ പരിഹാരം: സോഴ്സ് പോർട്ടുമായി യോജിക്കുന്ന നയ നിയമങ്ങൾ
B-യുടെ കേൾക്കുന്ന സോക്കറ്റിൽ നിന്നുള്ള മറുപടികൾ സോഴ്സ് പോർട്ട് 500-നോടെ പുറത്തുപോകുന്നു. ഒരു നയ നിയമത്തിന് അതുമായി യോജിച്ച് ആ പാക്കറ്റുകൾ സാധാരണ പട്ടികയിലേക്ക് തിരികെ അയയ്ക്കാം:
ip rule add sport 500 table main priority 100
ip rule add sport 8080 table main priority 101നയ നിയമങ്ങൾ മുൻഗണനാ ക്രമത്തിൽ പരിശോധിക്കപ്പെടുന്നു, പ്രധാന പട്ടിക 32766-ൽ ആണ്, അതിനാൽ 100-ലെ ഒരു നിയമം ടണലിന്റെ ഡിഫോൾട്ട് റൂട്ട് സംസാരിക്കുന്നതിന് മുൻപ് ചോദിക്കപ്പെടുന്നു. പുറത്തുനിന്ന് എത്തിച്ചേരാവുന്നതായി തുടരേണ്ട ഓരോ പോർട്ടിനും ഒരു എൻട്രി ചേർക്കുക, അതിൽ കൂടുതലൊന്നുമില്ല, അങ്ങനെ ഫോർവേഡ് ചെയ്യുന്ന ട്രാഫിക് അതിനായി നിർമ്മിച്ച ടണൽ തുടർന്നും ഉപയോഗിക്കും.
ഈ തന്ത്രത്തിന്റെ പരിധി അറിയുക. sport സെലക്ടർ പ്രാദേശികമായി സൃഷ്ടിച്ച പാക്കറ്റുകളുമായി യോജിക്കുന്നു, അത് മറുപടിയുടെ കാര്യം കൃത്യമായി ഉൾക്കൊള്ളുന്നു, B മറ്റൊരാൾക്കുവേണ്ടി വെറുതെ ഫോർവേഡ് ചെയ്യുന്ന ട്രാഫിക് ബോധപൂർവം ഉൾക്കൊള്ളുന്നില്ല. B-യുടെ പിന്നിൽ ഹോസ്റ്റ് ചെയ്യുന്ന ഒരു സേവനത്തിന് ഇപ്പോഴും സ്വന്തം മറുപടി വേണം, വിപരീതം നടിക്കുന്നത് ആദ്യ സേവനത്തിന് പ്രവർത്തിക്കുകയും രണ്ടാമത്തേതിന് പരാജയപ്പെടുകയും ചെയ്യുന്ന ഒരു പരിഹാരം നൽകുന്നു.
നിയമത്തിന് ഒരു ഉടമയെ നൽകുക
പ്രോംപ്റ്റിൽ ടൈപ്പ് ചെയ്ത ഒരു നിയമം അടുത്ത തവണ ഇന്റർഫേസ് പുനർനിർമ്മിക്കുമ്പോൾ അപ്രത്യക്ഷമാകുന്നു. WireGuard സെറ്റപ്പിൽ, ഇന്റർഫേസ് സൃഷ്ടിക്കുകയും നീക്കം ചെയ്യുകയും ചെയ്യുന്നിടത്ത് അത് വയ്ക്കുക:
PostUp = ip rule add sport 500 table main priority 100
PostDown = ip rule del sport 500 table main priority 100ഇന്റർഫേസിന്റെ ഉടമ NetworkManager, ഒരു ഡിസ്ട്രിബ്യൂഷൻ ഹുക്ക് അല്ലെങ്കിൽ ഒരു കണ്ടെയ്നർ എൻട്രിപോയിന്റ് ആണെങ്കിൽ, ആ ജോടി കൈകൊണ്ട് തിരുത്തിയ ഫയലിനല്ല, ആ ഉടമയ്ക്കാണ്. വീണ്ടും കണക്ട് ചെയ്തതിന് ശേഷം ഫലപ്രദമായ നിയമങ്ങൾ പരിശോധിക്കുക, ആദ്യ സ്റ്റാർട്ടിന് ശേഷം മാത്രമല്ല, കാരണം ആദ്യ സ്റ്റാർട്ട് എപ്പോഴും പ്രവർത്തിക്കുന്ന കേസാണ്.
ബദലുകൾ സത്യസന്ധമായി താരതമ്യം ചെയ്യുക
സോഴ്സ്-പോർട്ട് നിയമം നാല് പുറത്തുകടക്കൽ വഴികളിൽ ഒന്നാണ്, അവയിൽ ഏറ്റവും ഇടുങ്ങിയത്. ടണൽ നയത്തെ ഒട്ടും സ്പർശിക്കുന്നില്ല എന്നതാണ് അതിന്റെ നേട്ടം, അതുകൊണ്ടാണ് പിന്നീടുള്ള മാറ്റങ്ങളെ അത് സാധാരണയായി അതിജീവിക്കുന്നത്. ഇടുങ്ങിയ പരിഹാരങ്ങൾ ബാധകമാകാതെ വരുമ്പോൾ ഉച്ചത്തിൽ പരാജയപ്പെടുന്നു, അതേസമയം വിശാലമായ ഒഴിവ് അതിന്റെ കാരണം അപ്രത്യക്ഷമായി വളരെക്കാലം കഴിഞ്ഞും നിശബ്ദമായി പ്രവർത്തിച്ചുകൊണ്ടിരിക്കുന്നു. രണ്ട് വർഷത്തിന് ശേഷം പെട്ടിയുടെ ഉടമ മറ്റൊരാളാകുമ്പോൾ ആ വ്യത്യാസം അലങ്കാരത്തേക്കാൾ പ്രധാനമാണ്.
| Approach | What it costs | Where it breaks |
|---|---|---|
| Source-port policy rule | One rule per exposed port | Anything B forwards rather than originates |
| Destination exception route | A route pinned to specific client addresses | Clients whose address changes |
| Stop full-tunnelling on B | Loses the catch-all path toward C | Designs that depend on it |
| Split into two tunnels | More interfaces and more policy | Nothing, at the cost of complexity |
തിരഞ്ഞെടുത്തതിന് ശേഷം ഇരു അറ്റങ്ങളിൽ നിന്നും പരിശോധിക്കുക. A-യിൽ നിന്ന്, B-യുടെ പോർട്ടിലേക്ക് ഒരു കണക്ഷൻ തുടങ്ങി അൽപ്പസമയം തിരക്കിലാക്കി നിർത്തുക. B-യിൽ, ip route get <address-of-A> sport 500 പോലുള്ള ഒന്നുകൊണ്ട് കെർണലിനോട് മറുപടി പാത ന്യായീകരിക്കാൻ പറയുക, ടണലല്ല WAN ഇന്റർഫേസ് എന്ന് പറയുന്നുവെന്ന് സ്ഥിരീകരിക്കുക. അതിന് ശേഷം, C-യുടെ പിന്നിലുള്ള എന്തെങ്കിലും ഇപ്പോഴും ശൃംഖലയിലൂടെ മറുപടി നൽകുന്നുവെന്ന് പരിശോധിക്കുക, ഇത് ഒഴിവ് ബൈപാസായി മാറാതെ ഇടുങ്ങിയതായി തുടർന്നുവെന്ന് തെളിയിക്കുന്നു. അവസാനം, പോർട്ടുകൾ ഡിസൈൻ കുറിപ്പുകളിൽ രേഖപ്പെടുത്തുക, അല്ലെങ്കിൽ അടുത്ത ഓപ്പറേറ്റർ ഇത് മറ്റൊരു സേവനത്തിൽ വീണ്ടും കണ്ടെത്തും.