რატომ უგულებელყოფს 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-ში გამოჩენილი პრეფიქსი პირდაპირი მტკიცებაა, რომ ამ კლიენტმა გამოცხადება დააყენა. თუ თქვენი დიაპაზონი ამ ცხრილში არ არის, გაჩერდით: პრობლემა ლოკალურია და როუტერზე არანაირი სამუშაო მას არ შეცვლის.

ძველი კლიენტები იმავე უპირატესობას შესვლის ბრძანების დროშად გვთავაზობენ, ამიტომ sudo tailscale up --accept-routes სარეზერვო ვარიანტია, როცა tailscale set აკლია. გამოიყენეთ ის მარშრუტების ხელით რედაქტირების ნაცვლად, რადგან დემონი საკუთარ ცხრილს გადაწერს და თქვენი ცვლილება შემდეგ დაკავშირებაზე ქრება. შეამოწმეთ ვერსია, სანამ ძველი პოსტიდან ბრძანებას დააკოპირებთ.

შეამოწმეთ გამოცხადება და დამტკიცება ცალ-ცალკე

ქვექსელურ როუტერზე პრეფიქსი უნდა გამოცხადდეს, და ბირთვმა პაკეტები ინტერფეისებს შორის უნდა გადააგზავნოს. გამოცხადება გადაგზავნის გარეშე გაძლევთ დამტკიცებულ მარშრუტს, რომელიც ტრაფიკს ჩუმად ყრის, და ეს ყველაზე გავრცელებული ნახევრად დასრულებული კონფიგურაციაა.

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-ზე, და შეუსაბამობა არცერთ სტატუსის გამოსავალში არ ჩანს, რადგან ორივე რიცხვი ერთნაირად დამაჯერებლად გამოიყურება. დაზიანებული მარშრუტის შესახებ მოხსენებების უმეტესობა აქ მთავრდება. გაასწორეთ გამოცხადება, სანამ ქვემოთ რამეს შეეხებით.

დამტკიცება შემდეგი ჭიშკარია, და ადვილია მისი გამოტოვება, როცა როუტერი shell-იდან კონფიგურირდა. გამოცხადება ამ მოწყობილობისთვის ადმინისტრაციის კონსოლში უნდა ჩაირთოს, სანამ სხვა მანქანები მას გამოიყენებენ. კლიენტზე მარშრუტების მიღება არაფერს ამტკიცებს და არცერთ წვდომის წესს არ უვლის გვერდს.

პირადი მისამართი ჰოსტის სახელზე ადრე შეამოწმეთ

როუტერის საკუთარ 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 მარყუჟს იძენს. მარშრუტების გამომცხადებელ მანქანას სჭირდება გადაგზავნა, გადაგზავნილი ტრაფიკის დაშვების firewall წესები და გადაწყვეტილება, რომელი პრეფიქსები გამოაცხადოს. აქედან არაფერი გამომდინარეობს --accept-routes-დან.

ქვექსელური როუტერების დოკუმენტაცია აფრთხილებს, არ ჩართოთ მარშრუტების მიღება ზედმეტ როუტერებზე, რომლებიც ერთ პრეფიქსს აცხადებენ, რადგან სარეზერვო კვანძმა შეიძლება უკვე ლოკალური ტრაფიკი აქტიური კვანძის გავლით გარეთ გამოდევნოს. თუ HA წყვილს ამუშავებთ, მოეპყარით ამას როგორც დიზაინის შეზღუდვას და არა სქოლიოს, და გადაწყვიტეთ, რომელი კვანძი ფლობს პრეფიქსს, სანამ ორივეზე დაამტკიცებთ. ერთ როუტერზე იგივე გაფრთხილება იკითხება როგორც შეხსენება, რომ მიღება კლიენტებს ეკუთვნით და არა გამომცხადებელ მანქანას. ჩაწერეთ, რომელი ჭიშკარი იყო დაკეტილი.

ჩვეულებრივი კლიენტისთვის თანმიმდევრობა მთავრდება იმ აპლიკაციის ტესტით, რომელიც დასაწყისში ჩავარდა. როუტერისთვის გადახედეთ გადაგზავნას, გამოცხადებას, დამტკიცებას და firewall-ს ამ თანმიმდევრობით, რადგან პირველი არსებული აწარმოებს ზუსტად იმ დროის ამოწურვას, რომლითაც დაიწყეთ.

დაკავშირებული სტატიები