მხოლოდ ჩართვის ან მხოლოდ გამორიცხვის სპლიტ-ტუნელირება: რომელი ნაგულისხმევი ავირჩიოთ?
აირჩიე ნაგულისხმევი სიის აწყობამდე: გაატარე მხოლოდ ის, რასაც დაასახელებ, ან გაატარე ყველაფერი და ამოიღე გამონაკლისები. შემდეგ გამოსცადე ის აპლიკაცია, რომელიც არავის ჩაუწერია სიაში.
გახსენი VPN კლიენტის მარშრუტიზაციის განყოფილება და დაინახავ ორ სხვადასხვა ფორმის კონტროლს, რომლებსაც ხშირად ერთი და იგივე წარწერა აქვთ. ერთი გთხოვს ჩამოთვალო ის დანიშნულებები, რომლებიც ტუნელში უნდა მოხვდეს, დანარჩენი კი ადგილობრივ ქსელს იყენებს. მეორე ვარაუდობს, რომ ყველაფერი ტუნელშია და გეკითხება, რა უნდა ამოიჭრას უკან. ორივე პირველივე ტესტზე მუშა ტუნელს გაძლევს და ორივე სიაში ხაზების დამატებით ინარჩუნებს, ამიტომ განსხვავება უხილავი რჩება მანამ, სანამ ვინმე რამე ახალს დააყენებს.
ეს არჩევანი ნაგულისხმევია და არა ფუნქცია. გადაწყვიტე სანამ სიაში ოცი ჩანაწერი იქნება.
ნაგულისხმევი წაიკითხე კლიენტიდან და არა ბროშურიდან
WireGuard-ში ეს გადაწყვეტილება უჩვეულოდ თვალსაჩინოა, რადგან AllowedIPs მხოლოდ ჩართვის სიაა და მეტი არაფერი. პირი, რომელსაც 0.0.0.0/0, ::/0 აქვს, ყველაფერს ტუნელში ატარებს, ხოლო პირი, რომელსაც 10.20.0.0/16 აქვს, მხოლოდ ამ ქსელს. გამორიცხვის სინტაქსი არ არსებობს, ამიტომ თუ ერთი ქვექსელის გარეთ დატოვება გინდა, ან ყველა სხვა პრეფიქსი უნდა ჩამოთვალო, ან ინტერფეისის გარეთ პოლისური მარშრუტიზაცია დაამატო.
OpenVPN იმავე ადგილს საპირისპირო მიმართულებით აღწევს: redirect-gateway def1 სრულ ტუნელს ამყარებს, ხოლო ცალკეული route დირექტივები კონკრეტულ პრეფიქსებს ამატებს ან გადაფარავს. კომერციული კლიენტები ჩვეულებრივ ორივეს ჩამოსაშლელი ველისა და დანიშნულებათა ცხრილის უკან მალავს, ამიტომ სანამ წარწერას დაეყრდნობი, წაიკითხე, რომელს რედაქტირებს სინამდვილეში ცხრილი.
საკითხავი არ არის, რა ჰქვია ჩამოსაშლელ ველს. საკითხავია, რა დაემართება პაკეტს, რომლის დანიშნულება არც ერთ სიაში არ ფიგურირებს. ჩაწერე პასუხი და დანარჩენი კონფიგურაცია სწორედ აქედან გამომდინარეობს. გამოტოვე ეს კითხვა და პირველ გაუგებარ ჩავარდნას ის გადაწყვეტს, ვინც იმ დღეს კლიენტთან ყველაზე ახლოსაა.
თვალი ადევნე აპლიკაციას, რომელიც არავის ჩაუწერია
მხოლოდ ჩართვის სქემაში ეს აპლიკაცია პირდაპირ გადის, ადგილობრივ ქსელსა და ადგილობრივ DNS-ს იყენებს. მხოლოდ გამორიცხვის სქემაში ის ტუნელით გადის, იმის ფარგლებში, რასაც სერვერი უშვებს, და სწორედ ეს განსხვავება წყვეტს ხშირად, ახალი SaaS ინსტრუმენტი პირველივე დღეს იმუშავებს თუ ბილეთი გაიხსნება, რომ VPN-მა ის გატეხა.
არც ერთი ნაგულისხმევი თავისთავად უფრო უსაფრთხო არ არის. მხოლოდ ჩართვის ვარიანტი ავიწროებს იმას, რასაც ტუნელი ატარებს და ადგილობრივ ქსელს უმცირესი წინააღმდეგობის გზად აქცევს, ხოლო მხოლოდ გამორიცხვის ვარიანტი ტუნელს ნორმალურ გზად მიიჩნევს და გამონაკლისებს გამონაკლისებად ეპყრობა, რაც უფრო ახლოსაა იმასთან, რასაც კორპორატიული პოლიტიკა სინამდვილში გულისხმობს.
| Question | Include-only | Exclude-only |
|---|---|---|
| Unlisted new app | goes direct | goes through the tunnel |
| A site that breaks over the VPN | add it to the list | carve it out |
| Internal names still resolve | only if routed and served | usually, until split DNS says otherwise |
| Upkeep | one entry per internal service | one entry per misbehaving public service |
ყურადღება მიაქციე, როგორი ობიექტების ჩამონათვალს გვაძლევს პლატფორმა
Android-ის VpnService.Builder დაშვებული აპლიკაციების სიასა და აკრძალული აპლიკაციების სიას ორ ცალკე მოდელად აჩვენებს, და აპლიკაციაზე დაფუძნებული წესები დანიშნულებით კი არა, პაკეტით ირჩევს. ასეთ სიაში მოთავსებული ბრაუზერი ყველა დანიშნულებას თან მიჰყვება, რაც მარშრუტების ცხრილისგან განსხვავებული სიზუსტეა და ვერ გამოასწორებს ერთ გატეხილ საიტს მუშა აპლიკაციის შიგნით.
დესკტოპის კლიენტები ჩვეულებრივ ორივე ტიპს ერთ ინტერფეისში ურევს, ამიტომ შეამოწმე, ხაზი, რომელსაც ამატებ, პაკეტია, ჰოსტის სახელი თუ პრეფიქსი. ისინი სხვადასხვაგვარად ფარდება და სხვადასხვა ადგილას წყდება. ჰოსტის სახელის ხაზი ჩვეულებრივ მარშრუტად და სახელად იქცევა, პაკეტის ხაზი კი კლიენტის შიგნით პოლიტიკურ გადაწყვეტილებად. ჩაწერე, რომელი დაამატე, რადგან მოგვიანებით გამმართველი მეორეს ივარაუდებს.
შეამოწმე წარუმატებლობის მდგომარეობა და არა მხოლოდ კარგი გზა
ტუნელიდან გამორიცხული აპლიკაცია ავტომატურად არ იღებს სუფთა პირდაპირ წვდომას. თუ კლიენტი ასევე ავალდებულებს წესს ტუნელის გარეშე დაბლოკვის შესახებ, გამორიცხული ტრაფიკი შეიძლება საერთოდ ჩამოვარდეს, რაც გატეხილ აპლიკაციას ჰგავს და არა მარშრუტიზაციის გადაწყვეტილებას. გამოსცადე ეს შემთხვევა განზრახ და არა მომხმარებლის ანგარიშიდან აღმოაჩინე.
შემდეგ DNS და IPv6 ცალკეულ პუნქტებად შეამოწმე. ტუნელი, რომელიც მხოლოდ IPv4-ს ატარებს, v6-ის უნარის მქონე აპლიკაციას გვერდის ავლის გზას უტოვებს, ხოლო split DNS წყვეტს, გადაწყდება თუ არა შიდა სახელები იმ ტრაფიკისთვის, რომელიც საერთოდ არ არის ტუნელში. გაუშვი სიაში მყოფი აპლიკაცია, სიაში არმყოფი აპლიკაცია, სახელის ძებნა და ერთი ხელახალი დაკავშირება, და შედეგები კონფიგურაციასთან ერთად შეინახე.
ჩაწერე ნაგულისხმევი იქ, სადაც შემდეგი ადამიანი იპოვის
შერჩეული ნაგულისხმევი, გამონაკლისები და მათი მფლობელები დააფიქსირე იმავე ადგილას, სადაც კლიენტის პროფილია, რადგან შემდეგი ადმინისტრატორი ჩანაწერს დაამატებს ამ მსჯელობის წაკითხვის გარეშე. მიუთითე თარიღი და ყოველი გამონაკლისის მიზეზი, რათა საიტისთვის მოძველებული ამოჭრა, რომელიც უკვე გამოსწორდა, დარწმუნებით წაიშალოს. მიზეზების გარეშე სია უსასრულოდ იზრდება.
როცა ვინმე ერთ გატეხილ დანიშნულებაზე იუწყება, შეცვალე გამონაკლისი და არა საფუძველი. ნაგულისხმევის გადაბრუნება ერთი საიტის გამოსასწორებლად ჩუმად გადაიტანს ყველა ჩამოუთვლელ აპლიკაციას ტუნელის მეორე მხარეს.