ცალმხრივი ტრაფიკი Tailscale-ის ქვექსელის SNAT-ის გამორთვის შემდეგ

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

რას მალავდა SNAT

ჩართული SNAT-ის დროს როუტერი ქვექსელში გადაგზავნამდე წყაროს მისამართს საკუთარ LAN მისამართად გადაწერს, ამიტომ დანიშნულება პასუხობს ჰოსტს, რომელზეც უკვე იცის როგორ მოხვდეს, და მეტი არაფერია საყენებელი. მისი გამორთვა ინარჩუნებს თავდაპირველ წყაროს, და დანიშნულება შემდეგ ხედავს მისამართს overlay-ის დიაპაზონში, და არა მეზობელს საკუთარ მავთულზე. ეს მისამართი რეალურია და მარშრუტიზებადია tailnet-ის გასწვრივ, თუმცა LAN-იდან ნაგულისხმევი კარიბჭის გავლით მიუწვდომელია. დოკუმენტირებული გადამრთველია --snat-subnet-routes=false, რომელიც გამოიყენება თავად Linux-ის ქვექსელის როუტერზე.

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

სად შეიძლება იყოს დაბრუნების გზა

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

ip route add 100.64.0.0/10 via 192.168.1.10
ip route get 100.64.0.5

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

ხარვეზის წაკითხვა როგორც ცალმხრივი ტრაფიკი

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

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

sudo tcpdump -ni any host 100.64.0.5
ip route get 100.64.0.5

ღირს თუ არა ნამდვილი მისამართი მარშრუტად

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

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

Firewall, ჟურნალირება და ორმაგი როლი

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

sudo nft list ruleset | grep -n '100\.64'
sudo iptables-save | grep -n '100\.64'

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