કેમ મંજૂર થયેલ 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 ખોલવું એ રીતે સાંકડી વિનંતી પહોળી મંજૂરી બની જાય છે જે પછી કોઈ દૂર કરવાની હિંમત કરતું નથી.

જો ધ્યેય ખાનગી સબનેટ નહીં પણ ઇન્ટરનેટ ઇગ્રેસ હતો, તો યોગ્ય ઘટક એ એક્ઝિટ નોડ છે, સબનેટ રાઉટર નહીં, અને પોલિસી તથા રાઉટિંગ તે મુજબ અલગ પડે છે. મંજૂરી પહોળી કરતા પહેલા તે નિર્ણય તપાસો. એક્ઝિટ નોડ ડિફોલ્ટ રૂટ બદલે છે; સબનેટ રાઉટર ફક્ત પ્રીફિક્સની જાહેરાત કરે છે.