WireGuard 5G ശാഖ: ശാഖ തന്നെ ഹബ്ബിനെ വിളിക്കട്ടെ

ശാഖയെ ഹബ്ബിലേക്ക് ചൂണ്ടിക്കാണിക്കുന്നത് ഈ രൂപകൽപ്പനയുടെ എളുപ്പമുള്ള പകുതിയാണ്, ശാഖ മാറുന്ന മൊബൈൽ വിലാസത്തിന് പിന്നിലായിരിക്കുകയും ഹബ്ബിന് സ്ഥിരമായ പേരുണ്ടാകുകയും ചെയ്യുമ്പോൾ. അപ്പോൾ ഹബ്ബ് ശാഖയെ അംഗീകൃത ട്രാഫിക്കിൽ നിന്ന് പഠിക്കുന്നു, നിങ്ങൾ കാലികമായി സൂക്ഷിക്കേണ്ട രേഖയിൽ നിന്നല്ല. കരാർ ലളിതമാണ്: ശാഖ എപ്പോഴും ആരംഭിക്കുന്നു.

ഇത് ബോധപൂർവ്വം കോൺഫിഗർ ചെയ്യുക, എന്നിട്ട് ആളുകൾ പ്രവർത്തിക്കുന്നു എന്ന് കരുതുന്ന ഭാഗം പരിശോധിക്കുക. രണ്ട് ഘട്ടങ്ങൾക്കും മിനിറ്റുകൾ എടുക്കും, ഈ രൂപകൽപ്പനകൾ സാധാരണയായി രണ്ടാമത്തേതിൽ പരാജയപ്പെടുന്നു.

സ്ഥിരമായ എൻഡ്പോയിന്റ് ഏത് വശത്താണ്

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

ശാഖ അംഗീകൃത പാക്കറ്റ് അയയ്ക്കുമ്പോൾ, ഹബ്ബ് അത് വന്ന ഉറവിടം രേഖപ്പെടുത്തുകയും മറുപടികൾക്ക് ആ മാപ്പിംഗ് ഉപയോഗിക്കുകയും ചെയ്യുന്നു. അപ്പോൾ മൊബൈൽ ലിങ്കിന്റെ പുനർനമ്പറിംഗ് അടുത്ത ഹാൻഡ്ഷേക്ക് അല്ലാതെ ഒന്നും ചെലവാക്കുന്നില്ല, നിങ്ങൾക്ക് ഇനി ആവശ്യമില്ലാത്ത ഓരോ ഘടകവും മാറ്റത്തിനിടയിൽ പരാജയപ്പെടാൻ കഴിയാത്ത ഒന്നാണ്. ഈ ഗുണം ആസൂത്രിത മാറ്റത്തിനിടയിൽ പരീക്ഷിക്കാൻ യോഗ്യമാണ്, സംഭവത്തിനിടയിൽ അല്ല. ആർക്കെങ്കിലും രണ്ട് അറ്റങ്ങളും ഒരേസമയം കാണാൻ കഴിയുമ്പോൾ ഇത് ചെയ്യുക.

പുനർനമ്പറിംഗ് അതിജീവിക്കുന്ന കോൺഫിഗറേഷൻ ശാഖയ്ക്ക് നൽകുക

എൻഡ്പോയിന്റും keepalive-ഉം ശാഖയിൽ സൂക്ഷിക്കുക, ഹബ്ബിന്റെ പിയർ എൻട്രി കഠിനമായി കോഡ് ചെയ്ത വിലാസമില്ലാതെ സൂക്ഷിക്കുക. keepalive വിവർത്തനം ചെയ്ത മാപ്പിംഗ് ഹബ്ബിന് നിഷ്ക്രിയ കാലയളവിന് ശേഷം ആവശ്യപ്പെടാത്ത ട്രാഫിക് അയയ്ക്കാൻ മതിയായ കാലം തുറന്ന് സൂക്ഷിക്കുന്നു.

[Peer]
PublicKey = HUB_PUBLIC_KEY_BASE64
Endpoint = hub.example.net:51820
AllowedIPs = 10.60.0.0/24, 10.60.10.0/24
PersistentKeepalive = 25

ഇരുപത്തിയഞ്ച് സെക്കൻഡ് NAT മാപ്പിംഗ് ജീവനോടെ സൂക്ഷിക്കാൻ പലപ്പോഴും ഉദ്ധരിക്കപ്പെടുന്ന ഉദാഹരണമാണ്, ഓരോ പിയറിനും നിർബന്ധമല്ല. നിങ്ങൾ യഥാർത്ഥത്തിൽ നിരീക്ഷിക്കുന്ന മാപ്പിംഗ് ടൈംഔട്ടിന് അനുസരിച്ച് അത് സജ്ജമാക്കുക, ഇന്റർഫേസ് ഓണായിരിക്കുന്നിടത്തോളം ഡാറ്റാ പരിധിയുള്ള ലിങ്കിൽ ഇത് ട്രാഫിക് സൃഷ്ടിക്കുന്നു എന്ന് ഓർക്കുക.

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

മാപ്പിംഗും ഫെയിൽഓവറും പരിശോധിക്കുക

ഹാൻഡ്ഷേക്ക് പൂർത്തിയാകുന്നു, ഹബ്ബ് ശാഖയുടെ നിലവിലെ എൻഡ്പോയിന്റ് ലിസ്റ്റ് ചെയ്യുന്നു, ടണലിലൂടെ ശാഖയുടെ ആന്തരിക വിലാസങ്ങൾ എത്തിച്ചേരാവുന്നതാണ് എന്ന് ഉറപ്പാക്കുക. ഇതാണ് അടിസ്ഥാന രേഖ, ആരും മൊബൈൽ ലിങ്കിൽ തൊടുന്നതിന് മുമ്പ് ഇത് രേഖപ്പെടുത്തണം. രണ്ട് വരി ഔട്ട്പുട്ട് മതി. ടൈംസ്റ്റാമ്പിനൊപ്പം അവ ടിക്കറ്റിൽ സൂക്ഷിക്കുക.

wg show wg0
wg show wg0 latest-handshakes
ip route show default
ping -c 3 10.60.10.1

എന്നിട്ട് ഈ രൂപകൽപ്പന ഉള്ള പരാജയം പരീക്ഷിക്കുക. പ്രാഥമിക WAN വലിച്ചെടുക്കുക, ഹബ്ബിലേക്കുള്ള ശാഖയുടെ അടിസ്ഥാന റൂട്ട് ഇപ്പോൾ മൊബൈൽ ഇന്റർഫേസിലൂടെ പുറത്തുപോകുന്നു എന്ന് ഉറപ്പാക്കുക. ടണലിന് തകർന്ന ഭൗതിക പാത നന്നാക്കാൻ കഴിയില്ല, അതിനാൽ മരിച്ച മുകൾ ലിങ്കിലേക്ക് ഇപ്പോഴും ചൂണ്ടിക്കാണിക്കുന്ന പുറം റൂട്ട് ഹാൻഡ്ഷേക്ക് ടൈംഔട്ട് സൃഷ്ടിക്കുന്നു, അത് ഹബ്ബിന്റെ പ്രശ്നം പോലെ തന്നെ കാണപ്പെടുന്നു.

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

ഈ രൂപകൽപ്പന എന്താണ് പരിഹരിക്കാത്തത്

ഇവിടെ ഒന്നും ശാഖയിലേക്കുള്ള ഇൻബൗണ്ട് കണക്ഷൻ അനുവദിക്കുന്നില്ല. ആസ്ഥാനത്തുള്ള എന്തെങ്കിലും മൊബൈൽ സൈറ്റിലേക്ക് ഡയൽ ചെയ്യേണ്ടതുണ്ടെങ്കിൽ, ആ ആവശ്യത്തിന് ടണലിന്റെ ദിശ തെറ്റാണ്, ഡൈനാമിക് DNS ഒരു പേര് മാത്രം പുതുക്കുന്നു. പ്രൊവൈഡർ വിവർത്തനം, ഇൻബൗണ്ട് നയം, ക്ലയന്റിന്റെ എൻഡ്പോയിന്റ് പുതുക്കൽ എന്നിവയെല്ലാം വഴിയിൽ തുടരുന്നു, മാറിയ രേഖയ്ക്ക് കാരിയർ-ഗ്രേഡ് NAT തുറക്കാനാകില്ല.

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

റൺബുക്കിൽ നാല് കാര്യങ്ങൾ എഴുതുക: ആരാണ് ആരംഭിക്കുന്നത്, ഏത് പ്രിഫിക്സുകളാണ് അനുവദനീയം, keepalive എത്ര ദൈർഘ്യമുള്ളതാണ്, പ്രാഥമിക ലിങ്ക് വീഴുമ്പോൾ എന്ത് സംഭവിക്കുന്നു. ഭാവിയിലെ ഓപ്പറേറ്റർക്ക് രാത്രി മൂന്ന് മണിക്ക് യഥാർത്ഥത്തിൽ ആവശ്യമുള്ളത് ആ വരികളാണ്.