VPN თითო აპზე თუ split tunnel? რა შეიძლება გადაწყვიტოს Mac-ის მარშრუტმა

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

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

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

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

რას იძლევა ჩვეულებრივი split tunnel სინამდვილეში

Split tunnel კერძო პრეფიქსებისთვის მარშრუტებს ამონტაჟებს და დანარჩენს ფიზიკურ გზაზე ტოვებს. ჩვეულებრივ ეს არის მოთხოვნის მნიშვნელობა: ოფისის სერვერზე გვირაბით მისვლა, საჯარო დათვალიერების პირდაპირ დატოვება. მარტივია, ყველა ჩვეულებრივი კლიენტი მხარს უჭერს და ის ნებისმიერი სხვა მარშრუტის მსგავსი მექანიზმით სრულდება. შეამოწმეთ კონკრეტული დანიშნულება route -n get-ით, ნაგულისხმევი მარშრუტის წაკითხვის ნაცვლად, რადგან split tunnel ხშირად ნაგულისხმევ მარშრუტს ხელუხლებლად ტოვებს.

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

რას მოითხოვს აპის VPN macOS-ზე

macOS-ზე ნამდვილი აპის VPN არის Network Extension-ის ფუნქცია, რომელსაც კონფიგურაციის პროფილი მართავს. მართვის დატვირთვა შერჩეულ აპლიკაციებს VPN კონფიგურაციას უკავშირებს და სისტემა შემდეგ ამ აპლიკაციების ტრაფიკს შესაბამისად მარშრუტიზაციას უკეთებს. ეს მართული განლაგებაა, რაც ნიშნავს MDM-ს, ხელმოწერილ პროფილს და ადმინისტრატორს, რომელიც ორივეს ფლობს.

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

MDM-ის გარეშე აპის მიხედვით გამოყოფის სამი გზა

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

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

დაწერეთ მოთხოვნა ისე, რომ პასუხი ცალსახა იყოს

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

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