WireGuard വഴി ഒരു ആപ്പ്: ബൈൻഡിംഗ് റൂട്ടിംഗ് അല്ല

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

ഈ സംവിധാനത്തിന് രണ്ട് പകുതികളുണ്ട്: ടണലിന്റെ ട്രാഫിക് മാത്രം ഉപയോഗിക്കേണ്ട ഒരു റൂട്ടിംഗ് പട്ടിക, കൂടാതെ ചേരുന്ന സോഴ്സിനെ അങ്ങോട്ട് അയയ്ക്കുന്ന ഒരു നിയമം.

ബൈൻഡിംഗ് ഒരു സോഴ്സ് വിലാസം സജ്ജമാക്കുന്നു, അത്രമാത്രം

പോളിസി നിയമങ്ങൾക്ക് ആ തിരയൽ വഴിതിരിച്ചുവിടാനുള്ള അവസരം ലഭിച്ച ശേഷം, ലിനക്സ് ഒരു റൂട്ടിംഗ് പട്ടികയിൽ ലക്ഷ്യം തിരഞ്ഞ് പുറത്തുപോകുന്ന ഇന്റർഫേസ് തിരഞ്ഞെടുക്കുന്നു. സോഴ്സ് വിലാസം, ഫയർവാൾ മാർക്ക്, വരുന്ന ഇന്റർഫേസ്, UID, അല്ലെങ്കിൽ ഒരു പോർട്ട് എന്നിവയുടെ അടിസ്ഥാനത്തിൽ നിയമങ്ങൾക്ക് തിരഞ്ഞെടുക്കാം; ഓരോന്നും എല്ലാ ട്രാഫിക്കും പകരം ഈ ട്രാഫിക് എന്ന് പറയാനുള്ള മറ്റൊരു വഴിയാണ്. VPN ക്ലയന്റിന്റെ കോൺഫിഗറേഷൻ ടണലിന്റെ റൂട്ടുകളുള്ള പട്ടിക തിരഞ്ഞെടുക്കുന്നു; ഏത് ട്രാഫിക്കിന് അത് പരിശോധിക്കാമെന്ന് നിയമം തിരഞ്ഞെടുക്കുന്നു. ബൈൻഡിംഗ് മാത്രം രണ്ടും നൽകുന്നില്ല.

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

ടണലിന് അതിന്റേതായ പട്ടിക നൽകുക

wg-quick പ്രൊഫൈൽ പറയുന്നിടത്തെല്ലാം റൂട്ടുകൾ ഇൻസ്റ്റാൾ ചെയ്യുന്നു. [Interface]-ന് കീഴിൽ Table = 40 ചേർത്താൽ അവ പ്രധാന പട്ടികയ്ക്ക് പകരം പട്ടിക 40-ലേക്ക് പോകുന്നു. ഇന്റർഫേസ് ഉയർത്തി അവ എത്തിയെന്ന് ഉറപ്പാക്കുക: ip -4 route ls table 40 ടണലിന്റെ റൂട്ടുകൾ കാണിക്കണം, ip -4 route get 10.66.127.142 കേർണൽ ഇപ്പോൾ അവയിലൊന്ന് എങ്ങനെ പരിഹരിക്കുന്നു എന്ന് കാണിക്കുന്നു. റൂട്ടുകൾ അവയുടെ പട്ടികയിൽ ആയാൽ പ്രധാന പട്ടിക ബാക്കിയെല്ലാത്തിനും പ്രവർത്തിക്കുന്നു.

വീതിയേറിയ പ്രിഫിക്സ് ചേർക്കുന്നതിന് പകരം IPv6-നും ഇതുതന്നെ ചെയ്യുക. ip -6 rule add from fd00::2/128 lookup 40 ഒരു വിലാസം ഉറപ്പിക്കുന്നു; fc00::/8 ഹോസ്റ്റിലെ മറ്റ് ഇന്റർഫേസുകളുമായി കൂട്ടിയിടിച്ച് ഉദ്ദേശിച്ചതിലേറെ ചേരുന്ന ഒരു നിയമം സൃഷ്ടിക്കാം.

സോഴ്സ് നിയമം ചേർത്ത് കൗണ്ടറുകൾ നോക്കുക

തുടർന്ന് രണ്ട് പകുതികളും ബന്ധിപ്പിക്കുക: ip -4 rule add from 10.66.127.142/32 lookup 40, അതേ വിലാസം WireGuard ഇന്റർഫേസിൽ ചേർത്തുകൊണ്ട്. രണ്ട് നിയമങ്ങളും PostUp-ൽ ഇടുക, വീണ്ടും കണക്ട് ചെയ്യുമ്പോൾ അവ പുനഃസ്ഥാപിക്കപ്പെടും. ക്രമീകരണത്തിലല്ല, യഥാർത്ഥ അഭ്യർത്ഥനയിൽ പരിശോധിക്കുക: ip route get 1.1.1.1 from 10.66.127.142 ടണൽ ഉപകരണത്തിന്റെ പേര് പറയണം, curl --interface wg0 ifconfig.me വീട്ടിലെ വിലാസത്തിന് പകരം ടണലിന്റെ വിലാസം റിപ്പോർട്ട് ചെയ്യണം.

അപ്പോഴും പരാജയപ്പെട്ടാൽ ip -s rule വായിക്കുക. ഉള്ളതും എന്നും ചേരാത്തതുമായ ഒരു നിയമം പൂജ്യം കൗണ്ടറുകൾ കാണിക്കുന്നു, അതാണ് തെറ്റായ നിയമത്തെ നിയമമില്ലാത്തതിൽ നിന്ന് വേർതിരിക്കുന്നത്. ആ ഒരു കമാൻഡ് ആപ്പ് അതിന്റെ ഇന്റർഫേസ് ക്രമീകരണം അവഗണിച്ചോ എന്നതിനെക്കുറിച്ചുള്ള ധാരാളം ഊഹങ്ങൾ ലാഭിക്കുന്നു.

വിപരീത സാഹചര്യം: SSH ടണലിന് പുറത്ത് നിർത്തുക

വിപരീത പ്രശ്നവും അത്രതന്നെ സാധാരണമാണ്: wg-quick ഡിഫോൾട്ട് റൂട്ട് കൈവശം വയ്ക്കുന്നു, കൂടാതെ സെർവറിലേക്കുള്ള SSH സെഷൻ നടുവിൽ മരിക്കുന്നു. അതിന്റെ നിയമങ്ങൾ താഴ്ന്ന മുൻഗണനാ നമ്പറിലാണ്, അതിനാൽ ഒരു ഒഴിവ് അവയ്ക്ക് മുൻപ് വിലയിരുത്തണം. ip rule add dport 22 ipproto tcp table main priority 123 സമീപകാല iproute2-ൽ അത് ചെയ്യുന്നു; സെലക്ടർ ലഭ്യമല്ലാത്തിടത്ത് nftables-ൽ ഫ്ലോ അടയാളപ്പെടുത്തി പകരം മാർക്ക് ചേർക്കുക.

മടങ്ങിവരുന്ന വഴിയും പരിശോധിക്കുക. സ്ഥാപിതമായി പിന്നീട് നിശബ്ദമാകുന്ന SSH സെഷനിൽ സാധാരണയായി അസമമായ റൂട്ടിംഗ് ഉണ്ട്: ഒരു ദിശ ടണലിലൂടെയും മറ്റേത് ഭൗതിക ഇന്റർഫേസിലൂടെയും പുറത്തുപോകുന്നു. സെർവർ വിലാസത്തിനായി ip route get മറുപടി ഏത് വഴിക്ക് പോകുമെന്ന് പറയുന്നു.

പട്ടിക നമ്പർ, സോഴ്സ് നിയമം, ഒഴിവ് എന്നിവ പ്രൊഫൈലിൽ തന്നെ രേഖപ്പെടുത്തുക. മൂന്നും ഒരേ രൂപകൽപ്പനയുടേതാണ്, ഒരുമിച്ച് തിരുത്തപ്പെടും.