അംഗീകരിച്ച Tailscale സബ്നെറ്റ് റൂട്ട് ഇപ്പോഴും സമയപരിധി കവിയുന്നത് എന്തുകൊണ്ട്

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

നാല് ഘട്ടങ്ങൾ, ഒരു പരാജയം

റൂട്ടർ പ്രിഫിക്സ് പ്രഖ്യാപിക്കുന്നു, tailnet ആ പ്രഖ്യാപനം അംഗീകരിക്കുന്നു, ക്ലൈന്റ് ലഭിച്ച റൂട്ട് സ്വീകരിക്കുന്നു, ആക്സസ് നയം പ്രത്യേക കണക്ഷൻ അനുവദിക്കുന്നു. ഇവ മൂന്ന് വ്യത്യസ്ത ഘടകങ്ങൾ എടുക്കുന്ന നാല് വേറിട്ട തീരുമാനങ്ങളാണ്. അതിനാൽ അംഗീകരിച്ച റൂട്ട്, നെറ്റ്വർക്ക് ഇപ്പോൾ tailnet-ന്റെ റൂട്ടിംഗ് പട്ടികയുടെ ഭാഗമാണെന്ന് മാത്രം പറയുന്നു.

നാലാം ഘട്ടമാണ് ഏറ്റവും കൂടുതൽ ഒഴിവാക്കപ്പെടുന്നത്, കാരണം ആദ്യ മൂന്നെണ്ണം ദൃശ്യമായ അവസ്ഥ സൃഷ്ടിക്കുന്നു. റൂട്ടറിന്റെ സ്വന്തം tailnet വിലാസം ഉൾക്കൊള്ളുന്ന അനുമതി അതിനു പിന്നിലുള്ള സ്വകാര്യ സബ്നെറ്റിനെ യാന്ത്രികമായി ഉൾക്കൊള്ളുന്നില്ല. ഇവ വ്യത്യസ്ത ലക്ഷ്യസ്ഥാനങ്ങളാണ്, നയം ഓരോ ലക്ഷ്യസ്ഥാനത്തിനും വെവ്വേറെ വിലയിരുത്തുന്നു.

Linux-ൽ മൂന്നാം ഘട്ടത്തിന് ആളുകളെ അത്ഭുതപ്പെടുത്തുന്ന ഒരു ഡിഫോൾട്ടുമുണ്ട്: സബ്നെറ്റ് റൂട്ടുകൾ സ്വീകരിക്കുന്നത് ഐച്ഛികമാണ്. പല GUI ക്ലൈന്റുകളും പ്രഖ്യാപിച്ച റൂട്ടുകൾ ഡിഫോൾട്ടായി സ്വീകരിക്കുന്നു, അതിനാൽ മിശ്രിത ഫ്ലീറ്റിൽ ഒരു യന്ത്രം പരാജയപ്പെട്ടതായി കാണാം, ബാക്കിയുള്ളവ പ്രവർത്തിക്കുമ്പോൾ.

പ്ലാറ്റ്ഫോം അനുമാനിക്കുന്നതിനു പകരം പരാജയപ്പെടുന്ന യന്ത്രത്തിൽ ക്രമീകരണം സ്ഥിരീകരിക്കുക. പ്രവർത്തിക്കുന്ന യന്ത്രങ്ങളിൽ റൂട്ട് ഒരിക്കലും കാണാത്ത ഭാഗമായിരുന്നില്ല, അതിനാൽ tailnet വശം ആരോഗ്യകരമാണെന്ന് അവ തെളിയിക്കട്ടെ. Tailscale-ന്റെ സബ്നെറ്റ് റൂട്ടർ ഡോക്യുമെന്റേഷൻ അംഗീകാരം, ക്ലൈന്റിന്റെ റൂട്ട് സ്വീകരണം, നയ ഘട്ടം എന്നിവ ഉൾക്കൊള്ളുന്നു.

ക്ലൈന്റ് പ്രവർത്തിക്കുന്നിടത്ത് റൂട്ട് പരിശോധിക്കുക

റൂട്ടറിൽ നിന്നല്ല, പരാജയപ്പെടുന്ന ക്ലൈന്റിൽ നിന്ന് തുടങ്ങുക. റൂട്ട് നിലവിലുണ്ടെന്നും ക്ലൈന്റ് ക്രമീകരണം റൂട്ടുകൾ സ്വീകരിക്കാൻ അനുവദിക്കുന്നുവെന്നും സ്ഥിരീകരിക്കുക.

tailscale status
tailscale debug prefs | grep -i route
ip route get 10.20.0.42

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

Linux-ൽ റൂട്ടുകൾ സ്വീകരിക്കാൻ, ഫ്ലാഗ് സെറ്റ് ചെയ്തതായി അനുമാനിക്കുന്നതിനു പകരം അതോടെ വീണ്ടും കണക്ട് ചെയ്യുക: tailscale up --accept-routes. മറ്റ് ഫ്ലാഗുകളോടെ ചേർന്ന ക്ലൈന്റ് അവ മാറ്റുന്നതുവരെ സൂക്ഷിക്കുന്നു, അതിനാൽ മറ്റൊന്ന് ചേർക്കുന്നതിനു മുൻപ് നിലവിലെ ക്രമീകരണം പരിശോധിക്കുക. മാറ്റത്തിനുശേഷം ആദ്യ കമാൻഡ് വീണ്ടും പ്രവർത്തിപ്പിച്ചാൽ റൂട്ട് പട്ടികയിൽ കാണണം.

ഫോർവേഡിംഗും തിരിച്ചുവരവ് പാതയും തെളിയിക്കുക

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

sysctl net.ipv4.ip_forward
iptables -t nat -L POSTROUTING -n -v
tcpdump -ni any host 10.20.0.42 and port 443

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

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

റിസോഴ്സിനുള്ള ആക്സസ് നിയമം വായിക്കുക

റൂട്ട് നിലവിലുണ്ടെന്നും ഫോർവേഡിംഗ് തെളിയിച്ചതെന്നും ഉറപ്പായാൽ, ബാക്കിയുള്ള സംശയാസ്പദം നയമാണ്. കണക്ഷൻ അനുവദിക്കേണ്ട അനുമതി വായിച്ച് അതിന്റെ ലക്ഷ്യസ്ഥാനം പരിശോധിക്കുക, ഉറവിടം മാത്രമല്ല. ക്ലൈന്റിന്റെ സ്വന്തം ഐഡന്റിറ്റിയും നയ സെലക്ടറുമായി ഒത്തുപോകണം, അതിനാൽ അത് പരാജയപ്പെടുന്ന അതേ യന്ത്രത്തിൽ നിന്ന് രേഖപ്പെടുത്തുക.

tailscale status --json | head -40
tailscale ping <router-name-or-tailnet-ip>
ping -c 3 10.20.0.42

സ്റ്റാറ്റസ് ഔട്ട്പുട്ട് ക്ലൈന്റിന്റെ സ്വന്തം വിലാസങ്ങളും അത് കാണുന്ന പിയർമാരും തിരിച്ചറിയുന്നു, നയത്തിന്റെ ഉറവിട സെലക്ടർ ഇവയുമായി ഒത്തുപോകണം. tailscale ping സബ്നെറ്റ് റൂട്ടറിലേക്കുള്ള tailnet പാത തെളിയിക്കുന്നു; അത് പിയർ പേരുകളും tailnet വിലാസങ്ങളും പരിഹരിക്കുന്നു, പ്രഖ്യാപിച്ച സബ്നെറ്റിനുള്ളിലെ ഹോസ്റ്റുകളല്ല. മൂന്നാം കമാൻഡ് സബ്നെറ്റ് റൂട്ടിലൂടെ സാധാരണ ICMP എക്കോ അയയ്ക്കുന്നു, അതിനാൽ അതിന്റെ ഫലം റൂട്ടറിനെയല്ല, ലക്ഷ്യസ്ഥാനത്തെ വിവരിക്കുന്നു. tailnet തലത്തിലുള്ള നിരസനം സാധാരണയായി നിരസനമായി തിരിച്ചുവരും, പുറത്തുപോയി ഒരിക്കലും തിരിച്ചുവരാത്ത പാക്കറ്റ് സമയപരിധി കവിയും.

പരാജയപ്പെടുന്ന പേര് പരാജയപ്പെടുന്ന വിലാസത്തിൽ നിന്ന് വ്യത്യസ്തമായ ചോദ്യമാണ്; റൂട്ടിനെ കുറ്റപ്പെടുത്തുന്നതിനു മുൻപ് ഹോസ്റ്റ് നേരിട്ട് പരിഹരിക്കുക. അനുമതി മുഴുവൻ സബ്നെറ്റിനു പകരം റിസോഴ്സിന്റെ യഥാർത്ഥ ആവശ്യത്തിനനുസരിച്ച് എഴുതുക. ഒരു അപ്ലിക്കേഷൻ പ്രവർത്തിക്കാൻ മുഴുവൻ /24 തുറക്കുന്നതാണ്, ഇടുങ്ങിയ അഭ്യർത്ഥന പിന്നീട് ആരും നീക്കാൻ മടിക്കുന്ന വിശാല അനുമതിയാകുന്ന വഴി.

ലക്ഷ്യം സ്വകാര്യ സബ്നെറ്റല്ല, ഇന്റർനെറ്റ് എഗ്രെസ് ആയിരുന്നുവെങ്കിൽ, ശരിയായ ഘടകം എക്സിറ്റ് നോഡാണ്, സബ്നെറ്റ് റൂട്ടറല്ല, നയവും റൂട്ടിംഗും അതനുസരിച്ച് വ്യത്യാസപ്പെടുന്നു. അനുമതി വിശാലമാക്കുന്നതിനു മുൻപ് ആ തീരുമാനം പരിശോധിക്കുക. എക്സിറ്റ് നോഡ് ഡിഫോൾട്ട് റൂട്ട് മാറ്റുന്നു; സബ്നെറ്റ് റൂട്ടർ ഒരു പ്രിഫിക്സ് മാത്രം പ്രഖ്യാപിക്കുന്നു.