Linux-ലെ Tailscale ക്ലയന്റ് പ്രഖ്യാപിത സബ്നെറ്റ് റൂട്ടുകൾ അവഗണിക്കുന്നത് എന്തുകൊണ്ട്

പട്ടിക 52 സൂചനയാണ്: Linux-ലെ Tailscale ക്ലയന്റ് പ്രഖ്യാപിത സബ്നെറ്റ് റൂട്ട് --accept-routes-ന് ശേഷം മാത്രം ഇൻസ്റ്റാൾ ചെയ്യുന്നു, ഉപകരണാനുമതി വേറെ കവാടമാണ്.

നിങ്ങൾ Linux ലാപ്ടോപ്പിലാണ്, tailscale status മറ്റ് മെഷീനുകൾ പട്ടികപ്പെടുത്തുന്നു, 10.80.0.25-ലെ NAS ഇപ്പോഴും സമയപരിധി കഴിയുന്നു. tailnet ആരോഗ്യകരമാണ്, സബ്നെറ്റ് റൗട്ടർ ഓൺലൈനാണ്, ക്ലയന്റിന്റെ ഔട്ട്പുട്ടിൽ അതിനു പിന്നിലെ LAN എത്താൻ കഴിയാത്തതിന്റെ കാരണം ഒന്നും പറയുന്നില്ല. താഴെയുള്ള വിവരണം ആ ലക്ഷണത്തിൽ നിന്ന് പുറത്തേക്ക് നീങ്ങുന്നു: ഈ ക്ലയന്റിലെ ഫ്ലാഗ്, പിന്നെ റൗട്ടറിലെ പ്രഖ്യാപനം, പിന്നെ അനുമതി, പിന്നെ നയം, പിന്നെ മാത്രം ലക്ഷ്യം തന്നെ. ഓരോ കവാടവും അതേ സമയപരിധിയിൽ പരാജയപ്പെടുന്നു, അതിനാൽ ക്രമം കമാൻഡുകളേക്കാൾ പ്രധാനമാണ്.

Linux ക്ലയന്റ് ഇൻസ്റ്റാൾ ചെയ്യാൻ വിസമ്മതിക്കുന്നത്

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

ഇവിടെ രണ്ട് വ്യത്യസ്ത കാര്യങ്ങളെ റൂട്ടിംഗ് എന്ന് വിളിക്കുന്നു, അവയിൽ ഒന്ന് മാത്രം നിങ്ങളുടേതാണ്. റൗട്ടർ tailnet-ലേക്ക് ഒരു പ്രിഫിക്സ് പ്രഖ്യാപിക്കുന്നു; നിങ്ങളുടെ മെഷീൻ അത് ഇൻസ്റ്റാൾ ചെയ്യണോ എന്ന് തീരുമാനിക്കുന്നു. ഏതെങ്കിലും ഒന്നിൽ പരാജയം അതേ സമയപരിധി നൽകുന്നു, അതിനാൽ ഊഹിക്കൽ ഒരു ഉച്ചയ്ക്ക് ശേഷം പാഴാക്കുന്നു. എന്തെങ്കിലും തിരുത്തുന്നതിന് മുമ്പ് ഏത് വശം വിസമ്മതിക്കുന്നു എന്ന് കണ്ടെത്തുക.

ഈ മെഷീനിൽ റൂട്ട് സ്വീകരണം ഓണാക്കുക

ക്ലയന്റിൽ മുൻഗണന ക്രമീകരിക്കുക, എന്നിട്ട് കമാൻഡ് പ്രാബല്യത്തിൽ വന്നു എന്ന് കരുതുന്നതിന് പകരം എന്ത് മാറി എന്ന് നോക്കുക. നിലവിലെ രൂപം ലോഗിൻ പ്രവാഹം ആവർത്തിക്കാതെ ക്രമീകരണം പ്രയോഗിക്കുന്നു, സെഷന്റെ നടുവിലായിരിക്കുമ്പോൾ അത് പ്രധാനമാണ്.

sudo tailscale set --accept-routes
tailscale status
ip route show table 52

Tailscale Linux-ൽ സ്വീകരിച്ച റൂട്ടുകൾ അതിന്റെ സ്വന്തം പട്ടികയിൽ ഇൻസ്റ്റാൾ ചെയ്യുന്നു, അതിനാൽ പട്ടിക 52-ൽ ഒരു പ്രിഫിക്സ് കാണുന്നത് ഈ ക്ലയന്റ് പ്രഖ്യാപനം ഇൻസ്റ്റാൾ ചെയ്തതിന്റെ നേരിട്ടുള്ള തെളിവാണ്. നിങ്ങളുടെ ശ്രേണി ആ പട്ടികയിൽ ഇല്ലെങ്കിൽ നിർത്തുക: പ്രശ്നം പ്രാദേശികമാണ്, റൗട്ടറിൽ എത്ര ജോലി ചെയ്താലും അത് മാറില്ല.

പഴയ ക്ലയന്റുകൾ അതേ മുൻഗണന ലോഗിൻ കമാൻഡിന്റെ ഫ്ലാഗായി നൽകുന്നു, അതിനാൽ tailscale set ഇല്ലാത്തപ്പോൾ sudo tailscale up --accept-routes ബദലാണ്. റൂട്ടുകൾ കൈകൊണ്ട് തിരുത്തുന്നതിന് പകരം അത് ഉപയോഗിക്കുക, കാരണം ഡീമൺ അതിന്റെ സ്വന്തം പട്ടിക മാറ്റിയെഴുതുന്നു, അടുത്ത വീണ്ടും ബന്ധിപ്പിക്കലിൽ നിങ്ങളുടെ തിരുത്തൽ അപ്രത്യക്ഷമാകും. പഴയ പോസ്റ്റിൽ നിന്ന് കമാൻഡ് പകർത്തുന്നതിന് മുമ്പ് പതിപ്പ് പരിശോധിക്കുക.

പ്രഖ്യാപനവും അനുമതിയും വെവ്വേറെ പരിശോധിക്കുക

സബ്നെറ്റ് റൗട്ടറിൽ പ്രിഫിക്സ് പ്രഖ്യാപിക്കണം, കെർണൽ ഇന്റർഫേസുകൾക്കിടയിൽ പാക്കറ്റുകൾ ഫോർവേഡ് ചെയ്യണം. ഫോർവേഡിംഗ് ഇല്ലാതെയുള്ള പ്രഖ്യാപനം ട്രാഫിക് നിശ്ശബ്ദമായി ഉപേക്ഷിക്കുന്ന അംഗീകൃത റൂട്ട് നൽകുന്നു, അതാണ് ഏറ്റവും സാധാരണമായ പകുതി പൂർത്തിയായ ക്രമീകരണം.

sudo tailscale up --advertise-routes=10.80.0.0/24
sysctl net.ipv4.ip_forward
ip -br addr

പ്രഖ്യാപിത പ്രിഫിക്സിനെ നിങ്ങൾ യഥാർത്ഥത്തിൽ എത്താൻ ശ്രമിക്കുന്ന വിലാസവുമായി അക്ഷരം തോറും താരതമ്യം ചെയ്യുക. 10.70.0.0/24 പ്രഖ്യാപിക്കുന്ന റൗട്ടർ 10.80.0.25-ലെ NAS-നെക്കുറിച്ച് ഒന്നും പറയുന്നില്ല, രണ്ട് സംഖ്യകളും ഒരുപോലെ വിശ്വസനീയമായി തോന്നുന്നതിനാൽ ഈ പൊരുത്തക്കേട് ഏത് സ്റ്റാറ്റസ് ഔട്ട്പുട്ടിലും കാണാനാകില്ല. കേടായ റൂട്ടിന്റെ മിക്ക റിപ്പോർട്ടുകളും ഇവിടെ അവസാനിക്കുന്നു. താഴെയുള്ള ഒന്നും സ്പർശിക്കുന്നതിന് മുമ്പ് പ്രഖ്യാപനം ശരിയാക്കുക.

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

ഹോസ്റ്റ്നെയിമിന് മുമ്പ് സ്വകാര്യ വിലാസം പരിശോധിക്കുക

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

tailscale ping 10.80.0.1
ping -c 2 10.80.0.25
nc -vz 10.80.0.25 445
getent hosts nas.internal.example

വിലാസം പ്രതികരിക്കുകയും ഹോസ്റ്റ്നെയിം പ്രതികരിക്കാതിരിക്കുകയും ചെയ്താൽ നിങ്ങൾക്ക് നാമവിശകലന പ്രശ്നമുണ്ട്, അതിനെ റൂട്ട് പ്രശ്നമായി കാണുന്നത് നിർത്തുക. രണ്ടും പ്രതികരിക്കുന്നില്ലെങ്കിൽ ഒരു വിഭാഗം പിന്നോട്ട് പോയി പ്രഖ്യാപനം വിലാസം ഉൾക്കൊള്ളുന്നു എന്ന് സ്ഥിരീകരിക്കുക. രണ്ട് പരാജയങ്ങളും അപ്ലിക്കേഷനിൽ നിന്ന് ഒരുപോലെ തോന്നുന്നു, വ്യത്യസ്ത സ്ഥലങ്ങളിൽ പരിഹരിക്കുന്നു.

tailnet-നെ കുറ്റപ്പെടുത്തുന്നതിന് മുമ്പ് ഒരു പ്രാദേശിക പരിശോധന ഉചിതമാണ്. നിങ്ങളുടെ നിലവിലെ LAN വിദൂര സബ്നെറ്റിന് സമാനമായ പ്രിഫിക്സ് ഉപയോഗിക്കുമ്പോൾ, കെർണൽ നേരിട്ട് ബന്ധിപ്പിച്ച റൂട്ടിന് മുൻഗണന നൽകുന്നു, ട്രാഫിക് ഒരിക്കലും മെഷീൻ വിട്ടുപോകുന്നില്ല; വീടും ഓഫീസും രണ്ടും 192.168.1.0/24 തിരഞ്ഞെടുക്കുമ്പോൾ സംഭവിക്കുന്നത് അതാണ്.

ക്ലയന്റ് ഫ്ലാഗ് റൗട്ടർ ക്രമീകരണം ആകാത്തത് എന്തുകൊണ്ട്

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

സബ്നെറ്റ് റൗട്ടർ ഡോക്യുമെന്റേഷൻ ഒരു പ്രിഫിക്സ് പ്രഖ്യാപിക്കുന്ന അധിക റൗട്ടറുകളിൽ റൂട്ട് സ്വീകരണം ഓണാക്കരുതെന്ന് മുന്നറിയിപ്പ് നൽകുന്നു, കാരണം സ്റ്റാൻഡ്ബൈ നോഡിന് ഇതിനകം പ്രാദേശികമായ ട്രാഫിക് സജീവ നോഡിലൂടെ പുറത്തേക്ക് തള്ളാനാകും. HA ജോടി നടത്തുകയാണെങ്കിൽ അതിനെ അടിക്കുറിപ്പല്ല, ഡിസൈൻ നിയന്ത്രണമായി കാണുക, രണ്ടിലും അനുമതി നൽകുന്നതിന് മുമ്പ് പ്രിഫിക്സ് ഏത് നോഡിന്റേതാണെന്ന് തീരുമാനിക്കുക. ഒറ്റ റൗട്ടറിൽ അതേ മുന്നറിയിപ്പ് സ്വീകരണം ക്ലയന്റുകളുടേതാണ്, പ്രഖ്യാപിക്കുന്ന മെഷീന്റേതല്ല എന്ന് ഓർമ്മിപ്പിക്കുന്നു. ഏത് കവാടം അടച്ചിരുന്നു എന്ന് എഴുതിവയ്ക്കുക.

സാധാരണ ക്ലയന്റിന് ക്രമം തുടക്കത്തിൽ പരാജയപ്പെട്ട അപ്ലിക്കേഷൻ പരിശോധനയിൽ അവസാനിക്കുന്നു. റൗട്ടറിന് ഫോർവേഡിംഗ്, പ്രഖ്യാപനം, അനുമതി, ഫയർവാൾ എന്ന ക്രമത്തിൽ പരിശോധിക്കുക, കാരണം ആദ്യം ഇല്ലാത്തത് നിങ്ങൾ തുടങ്ങിയ അതേ സമയപരിധി തന്നെ സൃഷ്ടിക്കുന്നു.

അനുബന്ധ ലേഖനങ്ങൾ