લિનક્સ પરનો Tailscale ક્લાયન્ટ જાહેર કરેલા સબનેટ રૂટને કેમ અવગણે છે

તમે લિનક્સ લેપટોપ પર છો, tailscale status બીજા મશીનોની યાદી બતાવે છે, અને 10.80.0.25 પરનું NAS હજી સમય સમાપ્ત થાય છે. tailnet સ્વસ્થ છે, સબનેટ રાઉટર ઓનલાઇન છે, અને ક્લાયન્ટના આઉટપુટમાં કંઈ જ કહેતું નથી કે તેની પાછળનું LAN કેમ પહોંચનાર નથી. નીચેની મુસાફરી તે લક્ષણથી બહાર તરફ જાય છે: આ ક્લાયન્ટ પરનો ફ્લેગ, પછી રાઉટર પરની જાહેરાત, પછી મંજૂરી, પછી નીતિ, અને પછી જ ગંતવ્ય પોતે. દરેક દરવાજો એ જ સમય સમાપ્તિથી નિષ્ફળ જાય છે, તેથી ક્રમ આદેશોથી વધુ મહત્ત્વનો છે.

લિનક્સ ક્લાયન્ટ શું ઇન્સ્ટોલ કરવાનો ઇનકાર કરે છે

લિનક્સ પરના Tailscale ક્લાયન્ટ્સ જાહેર કરેલા સબનેટ રૂટ સ્વીકારતા નથી જ્યાં સુધી તમે તેમને કહો નહીં. તે સેટિંગ વિના ક્લાયન્ટ tailnetમાં જોડાય છે અને પીઅર સરનામાં સુધી પહોંચે છે, જ્યારે રાઉટર જે દરેક પ્રીફિક્સ જાહેર કરે છે તે વણવપરાયેલું રહે છે. મૂળભૂત મૂલ્ય જાણી જોઈને છે, અને તેથી જ લક્ષણ સ્થાનિક નિર્ણયને બદલે તૂટેલા રાઉટર જેવું લાગે છે.

અહીં બે અલગ વસ્તુઓને રૂટિંગ કહેવાય છે, અને તેમાંથી ફક્ત એક તમારી છે. રાઉટર tailnetમાં પ્રીફિક્સ જાહેર કરે છે; તમારું મશીન તેને ઇન્સ્ટોલ કરવું કે નહીં તે નક્કી કરે છે. બંનેમાંથી કોઈપણમાં નિષ્ફળતા એ જ સમય સમાપ્તિ આપે છે, તેથી અનુમાન એક બપોર બગાડે છે. કંઈપણ સંપાદિત કરતા પહેલાં શોધો કે કઈ બાજુ ઇનકાર કરે છે.

આ મશીન માટે રૂટ સ્વીકૃતિ ચાલુ કરો

ક્લાયન્ટ પર પસંદગી સેટ કરો, પછી આદેશ લાગુ થયો એમ માનવાને બદલે શું બદલાયું તે જુઓ. વર્તમાન સ્વરૂપ લોગિન પ્રવાહને પુનરાવર્તિત કર્યા વિના સેટિંગ લાગુ કરે છે, જે સત્રની વચ્ચે હોવ ત્યારે મહત્ત્વનું છે.

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

Tailscale લિનક્સ પર સ્વીકૃત રૂટ તેના પોતાના કોષ્ટકમાં ઇન્સ્ટોલ કરે છે, તેથી કોષ્ટક 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 જોડી ચલાવો છો, તો તેને પાદટીપ નહીં પણ ડિઝાઇન મર્યાદા ગણો, અને બંને પર મંજૂરી આપતા પહેલાં નક્કી કરો કે કયો નોડ પ્રીફિક્સનો માલિક છે. એકલા રાઉટર પર એ જ ચેતવણી યાદ કરાવે છે કે સ્વીકૃતિ ક્લાયન્ટ્સની છે, જાહેરાત કરતા મશીનની નહીં. કયો દરવાજો બંધ હતો તે લખો.

સામાન્ય ક્લાયન્ટ માટે ક્રમ શરૂઆતમાં નિષ્ફળ ગયેલી એપ્લિકેશન પરીક્ષણ સાથે પૂરો થાય છે. રાઉટર માટે ફોરવર્ડિંગ, જાહેરાત, મંજૂરી અને ફાયરવોલ આ ક્રમમાં સમીક્ષા કરો, કારણ કે પ્રથમ ખૂટતું તત્ત્વ બરાબર તે જ સમય સમાપ્તિ ઉત્પન્ન કરે છે જેની સાથે તમે શરૂ કર્યું હતું.