აპლიკაციაზე დაფუძნებული vs დანიშნულებაზე დაფუძნებული split tunneling: რომელი აირჩიოთ

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

ორი წესი სხვადასხვა დონეზე მოქმედებს

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

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

აპის წესები ერგება მობილურ კლიენტებსა და მართულ აგენტებს

Android არჩევანს პირდაპირ აჩვენებს: VpnService.Builder.addAllowedApplication() და addDisallowedApplication() პაკეტების სახელებს იღებენ და გადაწყვეტილებას თითოეული UID-ისთვის აღასრულებენ, როგორც Android-ის VPN დეველოპერის სახელმძღვანელოშიაა აღწერილი. iOS-ს ანალოგი აქვს bundle იდენტიფიკატორებზე დაფუძნებული აპლიკაციისეული VPN წესებით, რომლებიც ჩვეულებრივ MDM პროფილით მოდის და არა ხელით იწერება.

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

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

დანიშნულების წესები ერგება ქვექსელების სიებსა და საიტების ხელმისაწვდომობას

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

OpenVPN იმავე ადგილს აღწევს გადაგზავნილი მარშრუტიზაციის ცხრილით. route-nopull სერვერს მარშრუტების კარნახს უჩერებს, რის შემდეგ კლიენტის მხარეს route 10.20.0.0 255.255.0.0 vpn_gateway ზუსტად ოფისის პრეფიქსს ფარავს. IPv6 ცალკე დებულებაა თითოეულ ამ კლიენტში, და მისი დავიწყება სწორად მოჩვენებული IPv4 გაყოფის გარშემო გაჟონვის ყველაზე გავრცელებული გზაა.

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

სად იმტვრევა ორივე მოდელი: დამხმარეები, საერთო სერვისები, გამხსნელები

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

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

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

მოქმედების გეგმა: არჩევა, გამოყენება, შემოწმება

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

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

ip route get 10.20.30.40
ip -6 route get 2001:db8:10::40
wg show wg0 allowed-ips
Get-NetRoute -DestinationPrefix 10.20.0.0/16
Find-NetRoute -RemoteIPAddress 10.20.30.40

პირველი ორი ხაზი ასახელებს ინტერფეისს, რომელსაც რეალური დანიშნულება გამოიყენებდა; wg show ბეჭდავს კონფიგურირებულ პრეფიქსების სიას; Windows-ზე Find-NetRoute პასუხობს იმავე კითხვას, რომელსაც სტეკი უპასუხებს პაკეტის გაგზავნისას. თუ ინტერფეისი გვირაბია, წესი დაემთხვა.

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