നെറ്റ്‌വർക്ക് നേയിംസ്‌പേസിലെ WireGuard: സോക്കറ്റ് എന്തുകൊണ്ട് പിന്നിലായി

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

രോഗലക്ഷണം: ശരിയായ നേയിംസ്‌പേസ്, പക്ഷേ പാക്കറ്റുകളില്ല

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

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

ഇത് നീക്കത്തിലെ ഒരു തകറാറല്ല, പിയറിന്റെ തെറ്റായ കോൺഫിഗറേഷനുമല്ല. കർണൽ നടപ്പാക്കൽ ഇങ്ങനെയാണ് പ്രവർത്തിക്കുന്നത്, WireGuard-ന്റെ നേയിംസ്‌പേസ് രേഖകൾ സൃഷ്ടി നിയമം നേരിട്ട് വിവരിക്കുന്നു.

സോക്കറ്റിന് ഒരു ജന്മസ്ഥലം ഉള്ളത് എന്തുകൊണ്ട്

WireGuard ഉപകരണത്തിന് അതിന്റെ എന്‌ക്രിപ്റ്റ് ചെയ്ത കൈമാറ്റത്തിനായി ഒരു UDP സോക്കറ്റ് ഉണ്ട്, ആ സോക്കറ്റ് ഉപകരണം സൃഷ്ടിക്കുന്ന നേയിംസ്‌പേസിൽ തന്നെ തുറക്കുന്നു. ലിങ്ക് കമാൻഡിലൂടെ ഇന്റ്റർഫേസ് നീക്കിയാൽ കാണുന്ന ഉപകരണം നീങ്ങും, പക്ഷേ കൈമാറ്റം ആരംഭിച്ചിടത്തിൽ തന്നെ നില്ക്കും. അപ്പോൾ രണ്ട് വസ്തുക്കള്ക് വ്യത്യസ്ത ഉടമകാരായിരിക്കും.

പരിണിതി വിട്ടുപോകാൻ എളുപ്പമാണ്, കാരണം രണ്ട് പകുതികളും വ്യത്യസ്ത സ്ഥലങ്ങളിൽ പരിശോധിക്കുന്നു. അപ്ലിക്കേഷൻ പ്രവർത്തിക്കുന്ന നേയിംസ്‌പേസിലാണ് ഉള്ളിലെ റൂട്ട് തീരുമാനിക്കുന്നത്, സോക്കറ്റ് ഉള്ളിടത്താണ് പുറത്തെ റൂട്ട് തീരുമാനിക്കുന്നത്. ഒന്ന് മാത്രം പരിശോധിച്ചാൽ ആത്മവിശ്വാസമുള്ള പക്ഷേ തെറ്റായ നിഗമനം ലഭിക്കും. രണ്ടും പരിശോധിച്ചാൽ സാധാരണയായി ഒരു റൗണ്ഡിൽ അന്വേഷണം തീരും.

സോക്കറ്റ് വേണ്ടിടത്ത് തന്നെ അത് സൃഷ്ടിക്കുക

പരിഹാരം, ഉപകരണം പുറത്ത് സൃഷ്ടിച്ച് നീക്കുന്നതിനുപകരം ലക്ഷ്യ നേയിംസ്‌പേസിനുള്ളിൽ സൃഷ്ടിക്കുക എന്നതാണ്. അംഗീകൃത നേയിംസ്‌പേസ് ഇതിനകം ഉണ്ടെന്നും പേര് ഉപയോഗത്തില്ലെന്നും കരുതുക:

ip netns exec vpn-apps ip link add wg-demo type wireguard
ip netns exec vpn-apps wg show

ഇപ്പോൾ ഇന്റ്റർഫേസും അതിന്റെ സോക്കറ്റും ആ സന്ദർഭത്തിന്റേതാണ്, അതിനാൽ അണ്ടർലേ റൂട്ടും ബാധകമായ ഫിൽട്ടർ നിയമങ്ങളും അവിടെ കോൺഫിഗറ് ചെയ്തവയാണ്. രൂപകൽപനയ്ക്ക് വ്യക്തമായ ഭാഗം മറ്റെവിടെയെങ്കിൽ വേണമെങ്കിൽ, ആദ്യം അടിസ്ഥാന ഇന്റ്റർഫേസ് നേയിംസ്‌പേസിലേക്ക് ഇടുക, പിന്നീട് ടണൽ സൃഷ്ടിക്കുക. ക്രമം രൂപകൽപനയുടെ ഭാഗമാണ്, നടപ്പാക്കലിന്റെ വിശദാംശമല്ല.

ഇവയെ നെറ്റ്‌വർക്ക് ഭരണ കമാൻഡുകളായി കാണുക, പാചകക്കുറിപ്പായല്ല. അവ ഉപകരണം സൃഷ്ടിച്ച് അവസ്ഥ കാണിക്കുന്നു; കീകളും പിയറുകളും വിലാസങ്ങളും റൂട്ടുകളും ഇപ്പോഴും അംഗീകൃത കോൺഫിഗറേഷനിൽ നിന്നും വരണം, നിലവിൽലെ ഉത്പാദന ഇന്റ്റർഫേസ് ഒരിക്കലും ഉദാഹരണത്തിൽ പകരം വയ്ക്കരുതും.

പാതയുടെ രണ്ട് വശങ്ങളും വായിക്കുക

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

ip netns exec vpn-apps ip route get 10.30.0.9
ip netns exec vpn-apps wg show
tcpdump -ni any udp port 51820

ഉള്ളിലെ തിരയും ടണലിലൂടെ പരിഹരിക്കപ്പെടുകയും പുറത്തെ ക്യാപ്ചർ എന്‌ക്രിപ്റ്റ് ചെയ്ത കൈമാറ്റം കാണിക്കുന്നുവെങ്കിൽ, രണ്ട് പകുതികളും ഒത്തുപോകുന്നു. ക്യാപ്ചർ ശൂന്യമാണെങ്കിൽ, സോക്കറ്റ് ഇപ്പോഴും മറ്റെവിടെയാണ്, അല്ലെങ്കിൽ അതിന്റെ നേയിംസ്‌പേസിലെ അണ്ടർലേ റൂട്ട് അന്തിമ ബിന്ദുവിൽ എത്തുന്നില്ല.

ഒരു പരിശോധന കൂടി രേഖയിൽ ഉണ്ടായിരിക്കണം: പുനരാരംഭത്തിന് ശേഷം ഉപകരണം എങ്ങനെ സൃഷ്ടിക്കപ്പെടുന്നു. വ്യത്യസ്ത സൃഷ്ടി സന്ദർഭത്തോടെ ഇന്റ്റർഫേസ് വീണ്ടും സൃഷ്ടിക്കുന്ന മാനേജർ സോക്കറ്റിന്റെ ജന്മസ്ഥലം മാറ്റുന്നു. ഒരിക്കൽ വിജയിച്ച കൈകൊണ്ടുള്ള നീക്കം നിയന്ത്രിത പാതയെക്കുറിച്ചുള്ള തെളിവല്ല.