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

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