ഒരു WireGuard പിയർ എത്താൻ കഴിയാതെ മറ്റൊന്ന് പ്രവർത്തിക്കുമ്പോൾ: ചെക്ക്ലിസ്റ്റ്

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

ഘട്ടം 1: പാക്കറ്റ് സ്വീകരിക്കേണ്ട പാത എഴുതുക

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

പ്രതീക്ഷിക്കുന്ന പാത എവിടെ നോക്കണമെന്നും പറയുന്നു. പാക്കറ്റ് ഹബ് കടക്കേണ്ടതാണെങ്കിൽ പരാജയപ്പെടുന്ന ഹോപ്പ് അയച്ചയാളുടെ AllowedIPs, ഹബ്ബിന്റെ ഫോർവേഡിംഗ് അല്ലെങ്കിൽ സ്വീകരിക്കുന്നയാളുടെ AllowedIPs എന്നിവയിലൊന്നാണ്. നേരിട്ട് പോകേണ്ടതാണെങ്കിൽ ഹബ് അപ്രസക്തമാണ്, രണ്ട് പിയറുകളുടെയും എൻഡ്പോയിന്റ് ഫീൽഡുകളാണ് പ്രധാനം.

ഘട്ടം 2: AllowedIPs ഇരുവശത്തും താരതമ്യം ചെയ്യുക, ഒരു വശത്ത് മാത്രമല്ല

WireGuard AllowedIPs ഒരേസമയം റൗട്ടിംഗ് പട്ടികയായും ആക്സസ് ലിസ്റ്റായും ഉപയോഗിക്കുന്നു. അയയ്ക്കുമ്പോൾ ടണൽ തിരഞ്ഞെടുക്കാൻ ലക്ഷ്യ വിലാസം പിയറിന്റെ AllowedIPs-ൽ തിരയുന്നു; സ്വീകരിക്കുമ്പോൾ ആന്തരിക സ്രോതസ്സ് വിലാസം അയയ്ക്കുന്ന പിയറിന്റെ AllowedIPs-നുള്ളിൽ വീണിരിക്കണം, അല്ലെങ്കിൽ പാക്കറ്റ് ഉപേക്ഷിക്കപ്പെടും. ഏതെങ്കിലും വശത്ത് ഒരു ശ്രേണി കാണാതിരുന്നാൽ അതേ ലക്ഷണം തന്നെ: ഗതാഗതം പ്രവർത്തിക്കുന്നു, പേലോഡ് അപ്രത്യക്ഷമാകുന്നു.

ഫയലിന് പകരം ലൈവ് നില വായിക്കുക, കാരണം വീണ്ടും ലോഡ് ചെയ്യൽ നിശബ്ദമായി പരാജയപ്പെട്ടിരിക്കാം: sudo wg show wg0 allowed-ips. സെർവറിൽ പരാജയപ്പെട്ട പിയറിന്റെ എൻട്രിയിൽ അതിന്റെ ടണൽ വിലാസം ഉണ്ടായിരിക്കണം, ഉദാഹരണത്തിന് 10.90.0.3/32. ക്ലയന്റിൽ സെർവർ പിയറിന്റെ എൻട്രിയിൽ നിങ്ങൾ പരിശോധിക്കുന്ന ലക്ഷ്യം ഉണ്ടായിരിക്കണം, അത് ഹബ്ബിന്റെ ടണൽ വിലാസമോ ദൂരെയുള്ള സബ്നെറ്റോ ആകട്ടെ. ഓവർലാപ്പ് ചെയ്യുന്ന ശ്രേണികൾ തിരയൽ അവ്യക്തമാക്കുകയും നിങ്ങൾ ഉദ്ദേശിക്കാത്ത പിയർ തിരഞ്ഞെടുക്കുകയും ചെയ്യാം, അതിനാൽ അവ വേർതിരിച്ച് സൂക്ഷിക്കുക.

ഘട്ടം 3: ആന്തരിക സ്രോതസ്സ് വിലാസം പരിശോധിക്കുക

10.90.0.3 wg0 വഴി റൗട്ട് ചെയ്ത് പാക്കറ്റുകൾ സ്വന്തം Wi-Fi വിലാസത്തിൽ നിന്ന് അയയ്ക്കുന്ന ക്ലയന്റിനെ സ്വീകരിക്കുന്നയാൾ നിരസിക്കും, കാരണം സ്രോതസ്സ് പിയറിന്റെ AllowedIPs-മായി പൊരുത്തപ്പെടുന്നില്ല. കെർണൽ യഥാർത്ഥത്തിൽ എന്താണ് തിരഞ്ഞെടുക്കുന്നതെന്ന് ip route get 10.90.0.3 from 10.90.0.2 ഉപയോഗിച്ചും ടണൽ ഇന്റർഫേസിന് നൽകിയ വിലാസം ip -brief addr show wg0 ഉപയോഗിച്ചും സ്ഥിരീകരിക്കുക.

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

ഘട്ടം 4: ഹബ്ബിന്റെ ഫോർവേഡിംഗും തിരിച്ചുള്ള പാതയും അവലോകനം ചെയ്യുക

ഹബ്ബ് പിയറുകൾക്കിടയിൽ ഫോർവേഡ് ചെയ്യേണ്ടതുണ്ടെങ്കിൽ കെർണലിന് net.ipv4.ip_forward=1 ആവശ്യമാണ്, ഫയർവാൾ ഫോർവേഡ് ചെയ്യുന്ന പ്രവാഹം സ്വീകരിക്കണം: wg0-ൽ അകത്തേക്ക്, wg0-ൽ നിന്ന് പുറത്തേക്ക്, അയയ്ക്കുന്നയാളുടെ ടണൽ വിലാസത്തിൽ നിന്ന് സ്വീകരിക്കുന്നയാളുടെ വിലാസത്തിലേക്ക്. സാധാരണ പരാജയം UDP 51820 സ്വീകരിക്കുന്ന ഇൻപുട്ട് നിയമം ഉണ്ടെങ്കിലും ഫോർവേഡ് നിയമം ഇല്ലാതിരിക്കുകയാണ്], അപ്പോൾ ഹാൻഡ്ഷേക്ക് വിജയിക്കുകയും പേലോഡ് മരിക്കുകയും ചെയ്യുന്നു. ഫലപ്രദമായ നിയമങ്ങൾ sudo nft list ruleset അല്ലെങ്കിൽ നിങ്ങളുടെ ഫയർവാൾ മാനേജറുടെ തത്തുല്യമായ കമാൻഡ് ഉപയോഗിച്ച് ലിസ്റ്റ് ചെയ്യുക.

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

അവസാനം, ഹാൻഡ്ഷേക്ക് ഡാറ്റയിൽ നിന്ന് വേർതിരിക്കുക. ഹാൻഡ്ഷേക്ക് പൂർത്തിയാക്കി വലിയ കൈമാറ്റങ്ങളിൽ കുടുങ്ങുന്ന പിയറിന് സാധാരണയായി അതേ പാതയിൽ MTU അല്ലെങ്കിൽ MSS പ്രശ്നമാണ്, AllowedIPs പ്രശ്നമല്ല. ആദ്യം ചെറിയ പിംഗ് ഉപയോഗിച്ച്, പിന്നീട് പൂർണ്ണ വലിപ്പത്തിലുള്ള പിംഗ് ഉപയോഗിച്ച് പരിശോധിച്ച് രണ്ട് പിയറുകളും താരതമ്യം ചെയ്യുക.

ഘട്ടം 5: ഒരു കാര്യം മാറ്റി പ്രവർത്തിക്കുന്ന പിയർ അതേപടി നിലനിർത്തുക

പരാജയപ്പെടുന്ന പാതയിൽ ഒരു മാറ്റം മാത്രം വരുത്തി രണ്ട് പിയറുകളും വീണ്ടും പരിശോധിക്കുക. ഓരോ പിയറിന്റെയും AllowedIPs 0.0.0.0/0 ഉപയോഗിച്ച് മാറ്റിസ്ഥാപിക്കുന്നത് മുമ്പേ പ്രവർത്തിച്ചിരുന്ന പിയറിനെ തകർക്കാനുള്ള വേഗമേറിയ വഴിയാണ്, കാരണം അത് ആ ഇന്റർഫേസിലെ മുഴുവൻ ട്രാഫിക്കിന്റെയും റൗട്ടിംഗ് തീരുമാനം മാറ്റുന്നു. ആ ഒരു എൻട്രി മാത്രം എഡിറ്റ് ചെയ്ത്, വീണ്ടും ലോഡ് ചെയ്ത്, ലൈവ് നില വീണ്ടും വായിക്കുക.

ഏത് പാത വിജയിച്ചു, ഏത് പരാജയപ്പെട്ടു, ഓരോന്നിന്റെയും കൃത്യമായ കമാൻഡ് ഔട്ട്പുട്ട് എന്നിവ രേഖപ്പെടുത്തുക. VPN കേടായി എന്ന പൊതുവായ റിപ്പോർട്ടിനേക്കാൾ ആ താരതമ്യത്തിന് മൂല്യമുണ്ട്, അടുത്ത വ്യക്തി ആദ്യം ചോദിക്കുന്നത് അതായിരിക്കും.