Tailscale-ის ერთი ჰოსტი მიუწვდომელია: ქვექსელის მარშრუტიზატორი თუ გასასვლელი კვანძი?

ერთი Tailscale ჰოსტი პასუხობს, მეორე კი ბნელში რჩება, ან ყველაფერი მუშაობს მანამ, სანამ საჯარო ვებსაიტები არასწორ ქვეყანას დაიწყებენ მოხსენებას. ორივე საჩივარი მოდის ფორმით „Tailscale გატეხილია“, და ორივე ჩვეულებრივ არასწორი კონსტრუქციაა ჩართული არასწორი დანიშნულებისთვის. ქვექსელის მარშრუტიზატორი კერძო ქსელს ხსნის tailnet-ის წინაშე, ხოლო გასასვლელი კვანძი ცვლის, საიდან გადის ინტერნეტის ტრაფიკი. ჯერ წარუმატებელი დანიშნულება დაალაგე, შემდეგ აირჩიე ის როლი, რომელიც მას ფარავს.

დაიწყე იმ დანიშნულებიდან, რომელიც ვერ შესრულდა

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

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

მიაღწიე მოწყობილობას, რომელიც არასდროს უშვებს Tailscale-ს

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

tailscale up --advertise-routes=10.40.0.0/24 --advertise-exit-node=false
ip route get 10.40.0.55
tailscale status

გამოცხადება მხოლოდ პირველია სამი პირობიდან. მარშრუტი უნდა დამტკიცდეს tailnet-ისთვის, კლიენტმა უნდა მიიღოს გამოცხადებული მარშრუტები, და წვდომის წესმა უნდა დაუშვას კავშირი. სწორედ ამ ჯაჭვის გამო სიმპტომი ხშირად ის არის, რომ მარშრუტიზატორი მუშაობს, NAS კი არა. ხელმისაწვდომი მარშრუტიზატორი ამტკიცებს, რომ გვირაბი მუშაობს; ის არაფერს ამტკიცებს დამტკიცების, კლიენტის თანხმობის ან პოლიტიკის შესახებ.

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

საჯარო ტრაფიკი სხვა მანქანით გაიყვანე გარეთ

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

tailscale up --advertise-exit-node
tailscale up --exit-node=100.101.102.103 --exit-node-allow-lan-access=false
tailscale status --json | grep -i exitnode

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

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

წაიკითხე სამმხრივი გაყოფა, როცა მხოლოდ ერთი ჰოსტი ვარდება

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

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

დაადასტურე გზა, რომელიც გგონია, რომ ააშენე

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

ip route get 10.40.0.55
ip -6 route show default
tailscale ping 10.40.0.55

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