WireGuard ഹാൻഡ്ഷേക്ക് പ്രവർത്തിക്കുന്നു, പക്ഷേ ഓഫീസ് സബ്നെറ്റ് പ്രതികരിക്കുന്നില്ല
WireGuard പ്രവർത്തനക്ഷമമാണ്, സർവറിലേക്ക് പിംഗ് പോകുന്നു, എന്നാൽ അതിന്റെ LAN-ൽ ഒന്നും പ്രതികരിക്കുന്നില്ല. ക്ലയന്റ് പ്രിഫിക്സ്, സർവർ ഫോർവേഡിംഗ്, മറുപടിയുടെ പാത എന്നിവ പരിശോധിക്കുക.
ഹാൻഡ്ഷേക്ക് പൂർത്തിയാകുന്നു, wg show സമീപകാല കൈമാറ്റം റിപ്പോർട്ട് ചെയ്യുന്നു, സർവറിന്റെ ടണൽ വിലാസം പിംഗിന് പ്രതികരിക്കുന്നു. എന്നാൽ സർവറിന്റെ LAN-ലുള്ള ഒരു ഹോസ്റ്റ് പ്രതികരിക്കുന്നില്ല. മൂന്ന് വ്യവസ്ഥകൾ ഒരേസമയം പാലിക്കണം: ക്ലയന്റ് LAN പ്രിഫിക്സ് ടണലിലേക്ക് റൂട്ട് ചെയ്യണം, സർവർ പാക്കറ്റുകൾ ഫോർവേഡ് ചെയ്യണം, മറുപടിക്ക് തിരികെയുള്ള പാത വേണം. മൂന്നിൽ ഒന്ന് ഇല്ലെങ്കിൽ ലക്ഷണം അതുതന്നെയാണ്.
AllowedIPs ഒരേസമയം ആക്സസ് ലിസ്റ്റും റൂട്ടിംഗ് ടേബിളുമാണ്
ക്ലയന്റിൽ, AllowedIPs ലിസ്റ്റ് ആ പിയറിലേക്ക് എന്ത് അയക്കാമെന്നും WireGuard ഏത് റൂട്ടുകൾ ഇൻസ്റ്റാൾ ചെയ്യുന്നുവെന്നും തീരുമാനിക്കുന്നു. സർവറിന്റെ ടണൽ വിലാസം മാത്രം ലിസ്റ്റ് ചെയ്യുന്ന പിയർ എൻട്രി ഒരു ഹോസ്റ്റ് റൂട്ട് മാത്രം ഇൻസ്റ്റാൾ ചെയ്യുന്നു, അതിനാൽ LAN ലക്ഷ്യങ്ങൾ ഒരിക്കലും ടണലിൽ പ്രവേശിക്കുന്നില്ല. LAN പ്രിഫിക്സ് ചേർക്കുന്നതാണ് ആദ്യം പരിശോധിക്കേണ്ടത്, പകർത്തിയ കോൺഫിഗറേഷന് ശേഷം ഏറ്റവും കൂടുതൽ വിട്ടുപോകുന്ന മാറ്റവും അതുതന്നെ. ഡിഫോൾട്ട് റൂട്ടിലേക്ക് വിപുലീകരിച്ച പിയർ മറ്റൊരു രൂപകൽപ്പനയാണ്, അത് ക്ലയന്റിന്റെ ഇന്റർനെറ്റ് ട്രാഫിക്കും നീക്കും.
ഹോസ്റ്റ് റൂട്ടും LAN പ്രിഫിക്സും വെവ്വേറെ എൻട്രികളായി സൂക്ഷിക്കുക. ഓഫീസിൽ രണ്ട് സബ്നെറ്റുകളുണ്ടെങ്കിൽ രണ്ടും ലിസ്റ്റിൽ വരണം, വിട്ടുപോകുന്ന രണ്ടാമത്തെ പ്രിഫിക്സ് പൂർണ്ണമല്ലാത്ത, തിരഞ്ഞെടുത്തതായി തോന്നുന്ന പരാജയം ഉണ്ടാക്കുന്നു.
[Peer] PublicKey = <server public key> Endpoint = vpn.example.net:51820 AllowedIPs = 10.66.0.1/32, 192.168.50.0/24
ഫോർവേഡിംഗും വിവർത്തനവും സർവറിലാണ് വേണ്ടത്
സർവറിന് IP ഫോർവേഡിംഗ് പ്രവർത്തനക്ഷമമാക്കിയതും, ടണലിൽ നിന്ന് വരുന്ന ട്രാഫിക് സ്വീകരിക്കുന്ന ഫോർവേഡ് നിയമവും, അതിന്റെ LAN ഇന്റർഫേസിലേക്കുള്ള വിവർത്തന നിയമവും വേണം. ഓഫീസ് നെറ്റ്വർക്കിലെ ഓരോ ഹോസ്റ്റിനെയും തൊടാതെ രൂപകൽപ്പന പ്രവർത്തിക്കാൻ ഇടയാക്കുന്നത് ഈ വിവർത്തനമാണ്. അപ്പോൾ മറുപടികൾ LAN ഒരിക്കലും കേട്ടിട്ടില്ലാത്ത വിലാസത്തിലേക്കല്ല, സർവറിലേക്ക് മടങ്ങുന്നു. അതില്ലെങ്കിൽ ഓരോ ഹോസ്റ്റിനും ടണൽ സബ്നെറ്റിലേക്കുള്ള റൂട്ടും അത് അനുവദിക്കുന്ന ഫയർവാൾ നിയമവും വേണം, മറ്റൊരാൾ നിയന്ത്രിക്കുന്ന നെറ്റ്വർക്കിൽ അത് അപൂർവമായേ സ്വീകാര്യമാകൂ.
sysctl -w net.ipv4.ip_forward=1 iptables -A FORWARD -i wg0 -j ACCEPT iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
കൈകൊണ്ട് ചേർത്ത നിയമങ്ങൾ റീബൂട്ടിൽ അപ്രത്യക്ഷമാകുന്നു, അതിനാൽ സർവർ കോൺഫിഗറേഷനിലെ hook കമാൻഡുകളിലൂടെ അവ ഇന്റർഫേസുമായി ബന്ധിപ്പിക്കുക. തന്റെ ഇന്റർഫേസിനെക്കാൾ കൂടുതൽ കാലം നിലനിൽക്കുന്ന നിയമക്കൂട്ടം ഇനി നിലവിലില്ലാത്ത ടണലിനുവേണ്ടി യന്ത്രം ട്രാഫിക് വിവർത്തനം ചെയ്യാനിടയാക്കുന്നു.
LAN മാറിയപ്പോൾ നിയമം മാറിയില്ല
ഓഫീസ് സബ്നെറ്റ് പുനർനമ്പർ ചെയ്യുന്ന റൗട്ടർ മാറ്റിസ്ഥാപിക്കൽ ഈ പരാജയത്തിന്റെ ക്ലാസിക് രൂപമാണ്. ടണൽ ഓണായി തുടരുന്നു, ഹാൻഡ്ഷേക്ക് പുതുതായി തുടരുന്നു, സർവറിന് പിന്നിൽ ഒന്നും പ്രതികരിക്കുന്നില്ല, കാരണം വിവർത്തന നിയമം ഇപ്പോഴും പഴയ വിലാസം പറയുന്നു. ഇൻസ്റ്റാളർ സ്ക്രിപ്റ്റുകൾ സർവറിന്റെ LAN വിലാസം POSTROUTING നിയമത്തിൽ ഉൾപ്പെടുത്താറുണ്ട്, പുനർനമ്പറിംഗിന് ശേഷം ആ വിലാസം ഒരു ഇന്റർഫേസിലും ഉണ്ടാകില്ല. അപ്പോൾ പാക്കറ്റുകൾ പ്രതികരിക്കാൻ കഴിയാത്ത ലക്ഷ്യത്തിലേക്ക് വീണ്ടും എഴുതപ്പെടുന്നു.
iptables -t nat -n -L POSTROUTING ip -br addr show
രണ്ട് ഔട്ട്പുട്ടുകളും താരതമ്യം ചെയ്യുക. ഇന്റർഫേസ് ലിസ്റ്റിൽ കാണാത്ത വിവർത്തന ലക്ഷ്യമാണ് ബഗ്, ഒരിക്കൽ കണ്ടാൽ അത് പരിഹരിക്കുന്നത് ഒരു വരിയുടെ മാറ്റമാണ്. നിയമം WireGuard കോൺഫിഗറേഷനിലല്ല, സൃഷ്ടിച്ച unit-ൽ ആകാം, അതിനാൽ തിരുത്തിയ ശേഷം ആ unit വീണ്ടും ലോഡ് ചെയ്ത് അടുത്ത ബൂട്ട് നിങ്ങളുടെ മാറ്റം വീണ്ടും എഴുതുന്നില്ലെന്ന് ഉറപ്പാക്കുക.
NAT-ന് പിന്നിലുള്ള രണ്ട് സൈറ്റുകൾക്ക് കണ്ടുമുട്ടാനൊരിടം വേണം
ഏതൊരു വശവും ഇൻബൗണ്ട് കണക്ഷനുകൾ സ്വീകരിക്കാത്തപ്പോൾ, പ്രായോഗിക ഉത്തരം പൊതു വിലാസവും രണ്ട് WireGuard ഇന്റർഫേസുകളുമുള്ള ചെറിയ ഹോസ്റ്റാണ്. ഓരോ സൈറ്റും പുറത്തേക്ക് ബന്ധിപ്പിക്കുന്നു, മധ്യ ഹോസ്റ്റ് ഓരോ പിയറിന്റെയും LAN തന്റെ AllowedIPs, അതായത് സ്വന്തം ലിസ്റ്റിൽ, ലിസ്റ്റ് ചെയ്യുന്നു, ഫോർവേഡിംഗ് രണ്ട് ടണലുകൾക്കിടയിൽ പാക്കറ്റുകൾ കൊണ്ടുപോകുന്നു. ഏതൊരു സൈറ്റിന്റെയും ഫയർവാളിൽ ഒന്നും മാറ്റേണ്ടതില്ല, അതുകൊണ്ടാണ് ഈ രൂപകൽപ്പന എളുപ്പത്തിൽ പടരുന്നത്.
സൈറ്റുകൾക്കിടയിലുള്ള റൂട്ടിംഗ് യഥാർത്ഥ സ്രോതസ്സ് വിലാസങ്ങൾ നിലനിർത്തുന്നു, അതിനാൽ ഓരോ ഹോസ്റ്റിന്റെയും ലോഗിംഗ് അർത്ഥവത്തായി നിലനിർത്തുന്നു. രണ്ട് LAN കൂടിച്ചേരുമ്പോൾ മധ്യ ഹോസ്റ്റിൽ വിവർത്തനം ചെയ്യുന്നത് ലളിതമാണ്, പക്ഷേ ലോഗുകളിൽ സ്രോതസ്സ് ഐഡന്റിറ്റി നഷ്ടപ്പെടുന്ന ചെലവിൽ. തിരഞ്ഞെടുക്കുന്നതിന് മുമ്പ് ഏത് സ്വഭാവമാണ് പ്രധാനമെന്ന് തീരുമാനിക്കുക.
നാല് പരിശോധനകളാൽ പാളികൾ വേർതിരിക്കുക
മൂന്ന് കാര്യങ്ങൾ മാറ്റി പ്രതീക്ഷിക്കുന്നതിനുപകരം ഓരോ പാളിക്കും ഒരു പരിശോധന നടത്തുക. ആദ്യത്തേത് ഓരോ പിയറിന്റെയും ഹാൻഡ്ഷേക്ക് പ്രായവും കൗണ്ടറുകളും കാണിക്കുന്നു. രണ്ടാമത്തേത് ക്ലയന്റ് ആ ലക്ഷ്യം യഥാർത്ഥത്തിൽ ടണലിലേക്ക് റൂട്ട് ചെയ്യുന്നുണ്ടോ എന്ന് കാണിക്കുന്നു. മൂന്നാമത്തേതും നാലാമത്തേതും അഭ്യർത്ഥന എത്തിയോ, എത്തിയ ശേഷം ഏതെങ്കിലും നയം അത് ഉപേക്ഷിച്ചോ എന്ന് പറയുന്നു.
wg show ip route get 192.168.50.20 tcpdump -ni wg0 icmp iptables -vnL FORWARD --line-numbers
എത്തിയിട്ടും മറുപടി ലഭിക്കാത്ത അഭ്യർത്ഥന മറുപടിയുടെ പാതയെയോ LAN ഹോസ്റ്റിനെയോ സൂചിപ്പിക്കുന്നു. ഒരിക്കലും എത്താത്ത അഭ്യർത്ഥന AllowedIPs അല്ലെങ്കിൽ ക്ലയന്റിന്റെ റൂട്ടിനെ സൂചിപ്പിക്കുന്നു. ഈ രണ്ട് ഫലങ്ങൾക്ക് വ്യത്യസ്ത പരിഹാരങ്ങൾ വേണം, കാപ്ച്ചർ ആണ് അവയെ വേർതിരിക്കുന്നത്.