მუდმივი მარშრუტები Mac VPN-ისთვის: networksetup თუ დაკავშირების hook?
მარშრუტი, რომელსაც ყოველი ხელახალი დაკავშირების შემდეგ აკრეფთ, პოლიტიკა არ არის. გადაწყვიტეთ, პრეფიქსი VPN სერვისს, დროებით ტესტს თუ hook-ს ეკუთვნის მისამართებისთვის, რომლებიც მხოლოდ მოლაპარაკების შემდეგ ხდება ცნობილი.
მარშრუტი, რომელსაც ყოველი კავშირის შემდეგ აკრეფთ, წყვეტს წუთს და არა კვირას. macOS-ზე მდგრადი არჩევანი ჩვეულებრივ VPN სერვისთან შენახული პრეფიქსია, რადგან სერვისი მას ყოველ კავშირზე ხელახლა აყენებს და შლის, როცა სერვისი გამორთულია. ალტერნატივებია დროებითი route add ტესტირებისთვის და დაკავშირების hook მისამართებისთვის, რომლებიც მხოლოდ მოლაპარაკების შემდეგ ხდება ცნობილი.
გადაწყვიტეთ, მარშრუტი სერვისს ეკუთვნის თუ სესიას
იკითხეთ, რაზეა დამოკიდებული პრეფიქსი. თუ ეს ფიქსირებული კერძო ქსელია მშობლიური VPN სერვისის უკან, მარშრუტი იმ სერვისს ეკუთვნის. თუ ის დამოკიდებულია პარტნიორის მისამართზე, რომელიც ყოველ კავშირზე იცვლება, hook ან მდგომარეობით მართული ამოცანა შეიძლება უკეთესი მფლობელი იყოს. თუ მხოლოდ გზას ამოწმებთ მომდევნო ხუთი წუთისთვის, დროებითი მარშრუტი საკმარისია.
სერვისზე მიბმულ მარშრუტს ყველაზე სუფთა სასიცოცხლო ციკლი აქვს. ის სერვისთან ერთად ჩნდება და ქრება, როცა სერვისი დაკავშირებული არ არის, ამიტომ ვერ იცოცხლებს იმ გვირაბზე მეტხანს, რომელზეც მიუთითებს. ეს თვისება უფრო ღირებულია, ვიდრე ერთსტრიქონიანი ბრძანების მოხერხებულობა.
სესიაზე მიბმული მარშრუტი ინტერფეისს ეკუთვნის და ეს ნომერი შეტყობინების გარეშე იცვლება. ხელახალმა დაკავშირებამ შეიძლება გვირაბს სხვა utun სახელი მისცეს, ვიდრე წინა სესიამ გამოიყენა, რაც ხისტად კოდირებულ ბრძანებას აქცევს მარშრუტად, რომელიც არსად ან, უარესი, სხვა გვირაბზე მიუთითებს.
წაიკითხეთ მიმდინარე მარშრუტისა და სერვისის მდგომარეობა
დაიწყეთ იმ სახელებით, რომლებსაც სისტემა რეალურად იყენებს. ქსელის პარამეტრებში სერვისის სახელი ქვემოთ მოცემული ბრძანებების იდენტიფიკატორია, ხოლო მიმდინარე მარშრუტების ცხრილი გვიჩვენებს, რა დააყენა დაკავშირებულმა კლიენტმა. წაიკითხეთ ორივე, სანამ გვირაბი ჩართულია.
scutil --nc list
networksetup -listnetworkserviceorder
netstat -rn | head -30
route get 10.20.5.5
ეს ძიება გვიჩვენებს, რომელ კარიბჭესა და ინტერფეისს აირჩევდა ბირთვი ამ მისამართისთვის ამ მომენტში. თუ ის უკვე ირჩევს გვირაბს, პრეფიქსი დაფარულია და ახალი მარშრუტი ზედმეტი იქნებოდა. თუ ის ირჩევს ლოკალურ როუტერს, გვირაბს ეს პრეფიქსი აკლია.
დაკავშირებულ ხანდაზე დააფიქსირეთ პარტნიორის მისამართი. ის ხდება კარიბჭის მნიშვნელობა სერვისზე მიბმულ მარშრუტში და ჩვეულებრივ არის დანიშნულება, რომელიც ნაჩვენებია გვირაბის ნაგულისხმევი მარშრუტისთვის netstat -rn-ში.
შეინახეთ პრეფიქსი networksetup-ით
networksetup ინსტრუმენტი ქსელურ სერვისს დამატებით მარშრუტებს ურთავს. OfficeVPN სახელის სერვისისთვის და გვირაბის პარტნიორის გავლით მისაწვდომი კერძო პრეფიქსისთვის ფორმა ასეთია:
sudo networksetup -setadditionalroutes OfficeVPN 10.20.0.0 255.255.0.0 10.8.0.6
networksetup -getadditionalroutes OfficeVPN
სერვისის სახელის შემდეგ ყოველი სამეული იძლევა დანიშნულებას, მის ქსელურ ნიღაბს და გვირაბის პარტნიორს კარიბჭედ. ერთი გამოძახება შეიძლება რამდენიმე პრეფიქსს ატარებდეს, ხოლო ცარიელი გამოძახება შენახულ სიას ასუფთავებს. წამკითხველი შემოწმების ნაბიჯია; თუ სია ცარიელია, პარამეტრი არ გავრცელდა იმ სერვისზე, რომელსაც ფიქრობთ.
კარიბჭე უნდა იყოს გვირაბის პარტნიორი და არა ფიზიკური როუტერი. მარშრუტი, რომელიც ლოკალურ კარიბჭეს ასახელებს, კერძო პრეფიქსს ფიზიკური ინტერფეისიდან გარეთ აგზავნის, რაც საწყისი მარცხია დამატებითი ნაბიჯებით. მოძველებული პარტნიორი ყველაზე გავრცელებული მიზეზია იმისა, რომ სწორად მოჩვენებული მარშრუტი ტრაფიკს არასოდეს ატარებს. ხელახლა წაიკითხეთ პარტნიორი დაკავშირებული მდგომარეობიდან, ნაცვლად ძველი ჩანაწერიდან მისამართის კოპირებისა.
გამოიყენეთ route add მხოლოდ ტესტისთვის
პირდაპირი მარშრუტი სასარგებლოა იმის დასამტკიცებლად, რომ პრეფიქსი მუშაობს, სანამ მას მუდმივს გახდით. ინტერფეისის ფორმა კარიბჭის ძიებას თავიდან ირიდებს:
sudo route -n add -net 10.20.0.0/16 -interface utun4
მარშრუტი ქრება შემდეგ ხელახალ დაკავშირებაზე და დამოკიდებულია ინტერფეისის ნომერზე, რომელიც დღეს არსებობს. ეს მას დიაგნოსტიკად აქცევს და არა განლაგებად. თუ ტესტი მუშაობს, ხოლო სერვისზე მიბმული მარშრუტი არა, პირველად შეადარეთ კარიბჭის მნიშვნელობა; ეს არის ველი, რომელიც ყველაზე ხშირად არასწორია.
ფრთხილად იყავით რჩევებთან, რომლებიც VPN-ის ნაგულისხმევ მარშრუტს ცვლის გაყოფის იძულებისთვის. სრულ გვირაბს რომ ახორციელებს, კლიენტმა შეიძლება ხელახალი დაკავშირების ან პოლიტიკის განახლების შემდეგ თავისი მარშრუტები ხელახლა დააყენოს, ამიტომ ხელით ცვლილება ჩუმად უქმდება. რამდენიმე კერძო პრეფიქსი მარშრუტიზაციის პრობლემაა; მთელი ინტერნეტ ტრაფიკის ლოკალურად შენახვა სრული გვირაბის პოლიტიკის წინააღმდეგ გადაწყვეტილებაა სერვერის მხარეს.
აირჩიეთ hook მხოლოდ მაშინ, როცა მისამართზე მოლაპარაკება მიმდინარეობს
PPP-ზე დაფუძნებული ბმულებისთვის, მაგალითად L2TP, macOS ასრულებს /etc/ppp/ip-up-ს ბმულის დამყარებისთანავე. სკრიპტი იღებს ინტერფეისის სახელს და შეთანხმებულ ლოკალურ და დისტანციურ მისამართებს, ამიტომ მას შეუძლია დაამატოს მარშრუტი, რომელიც დამოკიდებულია სერვერის მიერ მინიჭებულ პარტნიორზე. სწორედ ესაა შემთხვევა, რომელსაც ფიქსირებული სერვისის მარშრუტი ვერ გამოხატავს.
შესაძლოა IKEv2 და მწარმოებლების კლიენტები საერთოდ არ იყენებდნენ ამ PPP გზას, რაც ნიშნავს, რომ სკრიპტი შეიძლება მთელი სესიის განმავლობაში ჩუმად იყოს. როცა ეს ხდება, launchd ამოცანა, რომელიც scutil --nc status-ს იკითხავს და მდგომარეობის ცვლილებაზე რეაგირებს, ეკვივალენტური მექანიზმია მცირე დაყოვნებით.
რომელი hook-იც არ უნდა გამოიყენოთ, გახადეთ ის იდემპოტენტური და დაუშვით მხოლოდ მის მიერ შექმნილი მარშრუტების წაშლა. სკრიპტი, რომელიც ყველა იმ მარშრუტს შლის, სადაც გვირაბი მოიხსენიება, საბოლოოდ წაშლის იმ მარშრუტსაც, რომელიც VPN სერვერს ხელმისაწვდომად ინახავს, და კავშირი ჩავარდება, როგორც კი წარმატდება.
დაასრულეთ კერძო დანიშნულების, ჩვეულებრივი დათვალიერების და ხელახალი დაკავშირების ან ძილის ციკლის შემოწმებით. შემდეგ შეამოწმეთ scutil --dns, რადგან სახელების გადაწყვეტა ცალკე პოლიტიკაა და მოქმედი მარშრუტი არ ამტკიცებს, რომ კერძო სახელები წყდება.