Tailscale സബ്നെറ്റ് SNAT പ്രവർത്തനരഹിതമാക്കിയതിന് ശേഷമുള്ള ഏകദിശ ട്രാഫിക്

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

SNAT എന്താണ് മറച്ചിരുന്നത്

SNAT സജീവമായിരിക്കുമ്പോൾ റൗട്ടർ സബ്നെറ്റിലേക്ക് നൽകുന്നതിന് മുമ്പ് സ്രോതസ്സ് വിലാസം സ്വന്തം LAN വിലാസമാക്കി മാറ്റിയെഴുതുന്നു, അതിനാൽ ലക്ഷ്യസ്ഥാനം ഇതിനകം എത്തിച്ചേരാൻ അറിയുന്ന ഹോസ്റ്റിനോട് പ്രതികരിക്കുന്നു, മറ്റൊന്നും കോൺഫിഗർ ചെയ്യേണ്ടതില്ല. ഇത് ഓഫ് ചെയ്യുമ്പോൾ യഥാർത്ഥ സ്രോതസ്സ് നിലനിൽക്കുന്നു, ലക്ഷ്യസ്ഥാനം സ്വന്തം വയറിലെ അയൽക്കാരനുപകരം ഓവർലേ പരിധിക്കുള്ളിലെ വിലാസം കാണുന്നു. ആ വിലാസം യഥാർത്ഥവും tailnet ഉടനീളം റൂട്ട് ചെയ്യാവുന്നതുമാണ്, പക്ഷേ ഡിഫോൾട്ട് ഗേറ്റ്വേ വഴി LAN-ൽ നിന്ന് അതിൽ എത്താൻ കഴിയില്ല. രേഖപ്പെടുത്തിയ സ്വിച്ച് --snat-subnet-routes=false ആണ്, ഇത് Linux സബ്നെറ്റ് റൗട്ടറിൽ തന്നെ പ്രയോഗിക്കുന്നു.

ഇത് ഓരോ പാക്കറ്റിനുമുള്ള ടോഗിൾ അല്ല, സ്ഥിരമായ ക്രമീകരണമാണ്, അതിനാൽ ആ റൗട്ടർ സേവനം നൽകുന്ന ഓരോ ലക്ഷ്യ ശൃംഖലയ്ക്കും തിരിച്ചുവരവ് പാത ഉണ്ടായിരിക്കണം. അതാണ് മാറ്റത്തെ ചെക്ക്ബോക്സിനുപകരം വിന്യാസ തീരുമാനമാക്കുന്നത്. ആ റൗട്ടർ സേവനം നൽകുന്ന എല്ലാം അതേ നിമിഷം ഈ ആവശ്യകത പാരമ്പര്യമായി പ്രാപിക്കുന്നു.

തിരിച്ചുവരവ് പാത എവിടെയാകാം

മൂന്ന് സ്ഥാനങ്ങൾ സാധാരണമാണ്, അവ കൃത്യതയിലല്ല, പരിധിയിൽ വ്യത്യസ്തമാണ്. ലക്ഷ്യ ഹോസ്റ്റിലെ സ്റ്റാറ്റിക് റൂട്ട് ഏറ്റവും നേരിട്ടുള്ളതും ഏറ്റവും കുറഞ്ഞ തോതിൽ വികസിപ്പിക്കാവുന്നതുമാണ്, ഓരോ ഉപകരണത്തിനും സ്വന്തം പകർപ്പ് വേണം. VPC-യിലെയോ സൈറ്റ് റൗട്ടറിലെയോ റൂട്ട് പട്ടിക ഒരു ശൃംഖല മുഴുവൻ ഒരുമിച്ച് ഉൾക്കൊള്ളുന്നു, ക്ലാസില്ലാത്ത സ്റ്റാറ്റിക് റൂട്ടുകൾ വഹിക്കുന്ന DHCP ഓപ്ഷൻ ക്ലയന്റുകളെ സ്വയമേവ എത്തുന്നു, പക്ഷേ അത് അവഗണിക്കുന്ന ഉപകരണങ്ങളിൽ നിശബ്ദമായി പരാജയപ്പെടുന്നു.

ip route add 100.64.0.0/10 via 192.168.1.10
ip route get 100.64.0.5

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

പരാജയത്തെ ഏകദിശ ട്രാഫിക്കായി വായിക്കുന്നത്

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

പകരം റൗട്ടറിൽ പിടിച്ചെടുക്കുക, കാരണം ഒരു കൈമാറ്റത്തിന്റെ രണ്ട് ദിശകളും അത് കാണുന്നു, ഉത്തരം ഒരിക്കലും വന്നോയെന്ന് കാണിക്കുന്നു. ഉത്തരം ലക്ഷ്യസ്ഥാനത്ത് പ്രത്യക്ഷപ്പെട്ട് റൗട്ടറിൽ ഒരിക്കലും പ്രത്യക്ഷപ്പെടുന്നില്ലെങ്കിൽ, ലക്ഷ്യഭാഗത്ത് റൂട്ട് കാണുന്നില്ല അല്ലെങ്കിൽ തെറ്റാണ്. അത് റൗട്ടറിൽ പ്രത്യക്ഷപ്പെട്ട് അവിടെ നിൽക്കുകയാണെങ്കിൽ, പ്രശ്നം കൂടുതൽ മുന്നിലാണ്, മറ്റൊരു അന്വേഷണത്തിന്റേതാണ്.

sudo tcpdump -ni any host 100.64.0.5
ip route get 100.64.0.5

യഥാർത്ഥ വിലാസം ഒരു റൂട്ടിന് അർഹമാണോ

ലക്ഷ്യ ശൃംഖല വീണ്ടും കോൺഫിഗർ ചെയ്യാൻ കഴിയാത്തപ്പോഴെല്ലാം SNAT നിലനിർത്തുന്നത് ലളിതമായ ഉത്തരമായി തുടരുന്നു, വിലയാകട്ടെ ഓരോ ക്ലയന്റും ലക്ഷ്യസ്ഥാനത്തിന്റെ ലോഗുകളിലും നയത്തിലും റൗട്ടറിനെപ്പോലെ കാണപ്പെടുന്നു എന്നതാണ്. ആപ്ലിക്കേഷന് യഥാർത്ഥ സ്രോതസ്സ് വിലാസം ആവശ്യമുള്ളപ്പോൾ അല്ലെങ്കിൽ ഒരു റൗട്ടർ പങ്കിടുന്ന ക്ലയന്റുകളെ ശൃംഖലാ നയം വേർതിരിക്കേണ്ടിവരുമ്പോൾ അത് ഓഫ് ചെയ്യുന്നത് ന്യായമാണ്. രണ്ടും സാധുവായ കാരണങ്ങളാണ്, ഒന്നും സൗജന്യമല്ല. ഓരോ ലക്ഷ്യ ശൃംഖലയിലും റൂട്ട് പരിപാലിക്കുന്നതിനും താഴെ വിവരിച്ചിരിക്കുന്ന ഫയർവാൾ അവലോകനത്തിനും ഈ നേട്ടം മതിയാകണം.

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

ഫയർവാൾ, ലോഗിംഗ്, ഇരട്ട പങ്ക്

റൗട്ടറിന്റെ LAN വിലാസവുമായി പൊരുത്തപ്പെട്ട ഓരോ നിയമവും ഇപ്പോൾ മറ്റൊരു സ്രോതസ്സുമായി പൊരുത്തപ്പെടുന്നു, അതിൽ അനുമതി നിയമങ്ങളും റൗട്ടറിനെ ക്ലയന്റായി രേഖപ്പെടുത്തിയ ഏത് ലോഗ് ഫീൽഡും ഉൾപ്പെടുന്നു. ആ നിയമങ്ങൾ ആദ്യ പരീക്ഷണത്തിന് മുമ്പ് വായിക്കുക, ആദ്യ പരാജയത്തിന് ശേഷമല്ല, കാരണം റൗട്ടറിന്റെ വിലാസത്തിന് മാത്രം അനുമതി നൽകുന്ന നിയമം പുതിയ സ്രോതസ്സിനെ പൂർണ്ണമായി തടയുന്നു. പകരം വയ്ക്കുന്നത് ആവശ്യമുള്ള ക്ലയന്റുകളിലേക്കും പോർട്ടുകളിലേക്കും ചുരുക്കുക, തുടർന്ന് അത് മുഴുവൻ tailnet-നെയും നിശബ്ദമായി അനുവദിക്കുന്നില്ലെന്ന് ഉറപ്പാക്കുക.

sudo nft list ruleset | grep -n '100\.64'
sudo iptables-save | grep -n '100\.64'

ഒരു നോഡ് ഒരേസമയം എക്സിറ്റ് നോഡും സബ്നെറ്റ് റൗട്ടറും ആയി സേവനം നൽകുന്നത് രേഖപ്പെടുത്തിയ സംയോജനമാണ്, സബ്നെറ്റ് SNAT പ്രവർത്തനരഹിതമാക്കിയാൽ അത് അപ്സ്ട്രീം ട്രാഫിക് വീഴ്ത്തിയേക്കാം. ആ പങ്കുകൾ വേറെ നോഡുകളിലേക്ക് വേർതിരിക്കുന്നത് ഈ മുൻകരുതൽ ഒഴിവാക്കുകയും ഓരോ റൂട്ടിനും ഫയർവാൾ നയത്തിനും ഒരു ഉടമയെ നൽകുകയും ചെയ്യുന്നു. പങ്കുകൾ ഒരുമിച്ച് നിൽക്കേണ്ടിവന്നാൽ, ഈ പെരുമാറ്റം പ്രതീക്ഷിച്ച് ക്ലയന്റിനെ കുറ്റപ്പെടുത്തുന്നതിന് മുമ്പ് പരീക്ഷിക്കുക. റൂട്ട്, സ്വിച്ച് ക്രമീകരണം, പങ്ക് വിഭജനം എന്നിവ ഒരൊറ്റ കുറിപ്പിൽ സൂക്ഷിക്കുക, അടുത്ത കണക്ഷൻ പരാജയപ്പെടുമ്പോൾ അവ ഒരുമിച്ച് വായിക്കപ്പെടുന്നു.