WireGuard-ൽ ഹോസ്റ്റ് പ്രിഫിക്സ്: ഒരു വിലാസം എന്തുകൊണ്ട് പ്രവർത്തിക്കുന്നു, ബാക്കിയുള്ളവയും ഇല്ല

ടണൽ പ്രവർത്തിക്കുന്നു, handshake ഓരോ രണ്ട് മിനിറ്റിലും സംഭവിക്കുന്നു, മറുവശത്ത് കൃത്യമായി ഒരു വിലാസം പ്രതികരിക്കുന്നു. പിയറിന്റെ ടണൽ വിലാസത്തിലേക്കുള്ള ping പ്രവർത്തിക്കുന്നു; അതിന് പിന്നിൽ ഒന്നും പ്രവർത്തിക്കുന്നില്ല. ആരോ ഇന്റർഫേസ് കോൺഫിഗറേഷൻ വായിച്ച്, ഹോസ്റ്റ് പ്രിഫിക്സ് കണ്ട്, മാസ്ക് തെറ്റാണെന്ന് തീരുമാനിക്കുന്നു. അത് /24 ആക്കി വിപുലീകരിക്കുന്നത് ping അൽപ്പസമയം ശരിയാക്കി പിന്നീട് മറ്റെന്തെങ്കിലും തകർക്കുന്നു. പ്രിഫിക്സ് ഒരിക്കലും കാരണമായിരുന്നില്ല, കാണാതായ റൂട്ട് മാസ്ക് നിയന്ത്രിക്കുന്ന റൂട്ടല്ല.

ഇന്റർഫേസ് പ്രിഫിക്സ് യഥാർത്ഥത്തിൽ എന്താണ് സൃഷ്ടിക്കുന്നത്

Linux-ൽ ഒരു ഇന്റർഫേസിന് വിലാസം നൽകുന്നത് ആ പ്രിഫിക്സിന് ബന്ധിപ്പിച്ച റൂട്ട് സൃഷ്ടിക്കുന്നു. ഹോസ്റ്റ് പ്രിഫിക്സ് നൽകിയാൽ ബന്ധിപ്പിച്ച റൂട്ട് ഒരു വിലാസം മാത്രം ഉൾക്കൊള്ളുന്നു. /24 നൽകിയാൽ അത് 256 ഉൾക്കൊള്ളുന്നു, അവയിലൊന്നും ഇപ്പോൾ ആ ലിങ്കിലൂടെ എത്താവുന്നതായി കണക്കാക്കപ്പെടുന്നു.

ip -4 addr show dev wg0
ip -4 route show dev wg0
ip route get 10.80.7.1

പോയിന്റ്-ടു-പോയിന്റ് ടണലിന് ഹോസ്റ്റ് പ്രിഫിക്സ് പൂർണ്ണമായും സാധാരണമായ തിരഞ്ഞെടുപ്പാണ്, കാരണം മറുവശത്ത് കൃത്യമായി ഒരു പിയർ ഉണ്ട്. മൂന്നാമത്തെ കമാൻഡാണ് ഉപയോക്താവിന്റെ ചോദ്യത്തിന് ഉത്തരം നൽകുന്നത്: കെർണൽ ആ ലക്ഷ്യത്തിന് ഏത് ഇന്റർഫേസ് ഉപയോഗിക്കുമെന്ന് പറയുന്നു, ഒരു റൂട്ടും ഒത്തുപോകുന്നില്ലെങ്കിൽ ഉപയോഗപ്രദമായ ഒന്നും കാണിക്കില്ല.

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

AllowedIPs ഒരു പേരിന് കീഴിൽ രണ്ട് നിയമങ്ങളാണ്

WireGuard-ന്റെ ഓരോ പിയറിനുമുള്ള അനുവദിച്ച പട്ടിക ഒരേസമയം രണ്ട് ജോലികൾ ചെയ്യുന്നു, കോൺഫിഗറേഷന്റെ വാക്യഘടന അവയെ ഒന്നുപോലെ കാണിക്കുന്നു. അകത്തേക്ക് വരുമ്പോൾ ഏത് ഉറവിട വിലാസങ്ങൾ പിയറിന് അവതരിപ്പിക്കാം എന്ന് അനുവദിക്കുന്നു. പുറത്തേക്ക് പോകുമ്പോൾ പാക്കറ്റ് ഏത് പിയറിന് അയക്കണം എന്ന് തിരഞ്ഞെടുക്കുന്നു, ഏറ്റവും നിർദ്ദിഷ്ടമായ ഒത്തുചേരൽ കണ്ടെത്തി.

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

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

റൂട്ട് എവിടെ നിന്ന് വരുന്നു

നിങ്ങൾ wg-quick ഉപയോഗിക്കുന്നുവെങ്കിൽ, റൂട്ടുകൾ നിങ്ങൾക്കായി ഓരോ പിയറിന്റെയും അനുവദിച്ച പട്ടികയിൽ നിന്ന് സൃഷ്ടിക്കപ്പെടുന്നു, നിങ്ങൾ Table = off സെറ്റ് ചെയ്ത് നിയന്ത്രണം സ്വയം ഏറ്റെടുക്കുന്നില്ലെങ്കിൽ. ഇതാണ് ഉപകരണത്തിന്റെ രേഖപ്പെടുത്തിയ സ്വഭാവം, അതുകൊണ്ടാണ് വ്യക്തമായ റൂട്ട് നിർദ്ദേശങ്ങളില്ലാതെയും കോൺഫിഗറേഷൻ പ്രവർത്തിക്കുന്നത്.

sudo wg show wg0 allowed-ips
ip route show | grep wg0
sudo wg-quick strip wg0

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

നിങ്ങൾ അത് കൈകൊണ്ട് കൈകാര്യം ചെയ്യുമ്പോൾ, റൂട്ട് ഒരു വരിയാണ്, അതിന്റെ രൂപം വ്യക്തമാണ്: ലക്ഷ്യം ഇന്റർഫേസിലൂടെ, ഗേറ്റ്വേ ഇല്ലാതെ കാരണം ലിങ്ക് പോയിന്റ്-ടു-പോയിന്റാണ്. അത് ചേർക്കുന്നത് മോശം പ്രിഫിക്സിനുള്ള പരിഹാരമല്ല; റൗട്ടിംഗ് സ്വയം ഏറ്റെടുത്ത ഒരു രൂപകൽപ്പനയുടെ കാണാതായ പകുതിയാണ്.

വിശാലമായ പ്രിഫിക്സ് പിയർ എൻട്രി ചേർക്കുന്നില്ല

ആകർഷകമായ തിരുത്ത് വിലാസം /24 ആക്കി മാറ്റുന്നതാണ്, അപ്പോൾ ബന്ധിപ്പിച്ച റൂട്ട് സെർവറിന്റെ പ്രാദേശിക നെറ്റ്വർക്ക് ഉൾക്കൊള്ളും. അത് പ്രവർത്തിക്കുന്നതായി തോന്നുന്നു, പ്രവർത്തിക്കുന്നതായി തോന്നാനുള്ള കാരണം ബന്ധിപ്പിച്ച റൂട്ട് ഇപ്പോൾ ഒത്തുപോകുന്നു എന്നതാണ്, WireGuard പുതിയതായി എന്തെങ്കിലും പഠിച്ചു എന്നല്ല.

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

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

എന്തെങ്കിലും മാറ്റുന്നതിന് മുമ്പ് രണ്ട് ദിശകളും സ്ഥിരീകരിക്കുക

രണ്ട് അറ്റങ്ങളും വെവ്വേറെ പരിശോധിച്ച് ഓരോന്നും എന്ത് പറയുന്നു എന്ന് എഴുതുക. ക്ലയന്റിൽ റൂട്ടും പിയർ എൻട്രിയും; സെർവറിൽ കണ്ണാടി പ്രതിബിംബവും അതിന്റെ സ്വന്തം തിരികെയുള്ള പാതയും:

ip route get 192.168.70.20
sudo wg show wg0 allowed-ips
sudo wg show wg0 latest-handshakes
sudo tcpdump -ni wg0 -c 10

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

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