Wi-Fi-დან მობილურ ქსელზე გადასვლის შემდეგ kill-switch: რა იშლება

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

ეკრანზე ვერაფერი გამოყოფს ამ სამ მდგომარეობას, ამიტომ იკითხეთ, რომელ იდენტიფიკატორებზე იყო წესები მიმაგრებული და არა რა ფერს აჩვენებს მაჩვენებელი. Linux-ზე წესს შეუძლია დაასახელოს ინტერფეისი ან მისგან შევსებული ipset; Android-ზე VpnService-ს შეიძლება ეთქვას, რომელ ქვედა ქსელებს მიჰყვეს setUnderlyingNetworks-ით. ყოველი მიბმა მიუთითებს რგოლზე, რომელიც სულ მალე შეიცვლება, და თითოეული უნდა გადაფასდეს შემდეგ.

რას გადაწერს გადასვლა სინამდვილეში

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

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

გარე გვირაბის ხელახლა აშენება ხვრელის გაუყრელად

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

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

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

ip route get 1.1.1.1
ip -6 route get 2606:4700:4700::1111

როცა ახალი რგოლი IPv6-ს მოიტანს და წესები არა

მობილური და სტუმრის ქსელები ხშირად გლობალურ IPv6 პრეფიქსს აძლევენ, მაშინაც კი როცა ოფისის სადენიან LAN-ს ეს არასდროს გაუკეთებია. მხოლოდ IPv4 წესებად დაწერილი პოლიტიკა — ხელით შექმნილი iptables და nftables რეცეპტების უმეტესობის ნაგულისხმევი ფორმა — აქედან ვერაფერს ფარავს. გვირაბი დაკავშირებული რჩება, IPv6-ზე წვდომის მქონე აპლიკაციები მის გარეთ გადიან, და მაჩვენებელი ვერ აჩვენებს სხვაობას, რადგან გვირაბი ნამდვილად აწეულია. სარკისებური შემთხვევაც ისეთივე გავრცელებულია: მხოლოდ IPv6-ისთვის განკუთვნილი წესების ნაკრები არაფერს აკეთებს ქსელში, რომელიც v6-ს არ სთავაზობს.

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

ip -4 route show default
ip -6 route show default
sudo nft list ruleset | grep -c 'ip6 '

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

გადამწყვეტი სესიის შუაში ხელს იცვლის

თანამედროვე სისტემებში გადამწყვეტები რგოლებზეა მიბმული, ამიტომ ახალი რგოლი ახალი გადამწყვეტების ნაკრებით და შესაძლოა განსხვავებული split-DNS ხედვით მოდის. systemd-resolved თითო scope-ს ინახავს რგოლზე და მათ შორის მარშრუტის მიხედვით ირჩევს, ხოლო macOS scoped გადამწყვეტებს დინამიკური საცავიდან კითხულობს და ინტერფეისების რიგს პატივს სცემს. კლიენტი, რომელიც საკუთარ გადამწყვეტს აყენებს, რგოლისათან კონკურენციას აწარმოებს, და გამარჯვებას გადაწყვეტს პრიორიტეტის წესები, რომლებსაც არავინ აკვირდება. მაშინ სახელების გადაწყვეტა შეიძლება გატყდეს, მაშინ როცა პაკეტების ფილტრაცია ზუსტად იმას აკეთებს, რისთვისაც დაიწერა.

წაიკითხეთ გადამწყვეტი, რომელიც აქტიურია და არა ის, რომელიც კონფიგურირებულია. systemd ჰოსტზე status ქვებრძანება აჩვენებს, რომელი რგოლიდან მოვიდა თითოეული scope და მოქმედებს თუ არა private-DNS სახელი:

resolvectl status --no-pager
resolvectl query intranet.example.com

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

ივარჯიშეთ გადასვლაზე და შეინახეთ ჩანაწერი

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

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

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