Split tunnelling განმარტებით: VPN-ის წესები აპლიკაციებისა და მარშრუტების მიხედვით

Split tunnelling ნიშნავს, რომ შენი ტრაფიკის ნაწილს VPN-ით აგზავნი, დანარჩენს კი პირდაპირ შენი ჩვეულებრივი კავშირით. წესი, რომელიც ამას წყვეტს, შეიძლება ეფუძნებოდეს აპლიკაციას (ეს ბრაუზერი tunnel-ით, ის თამაში პირდაპირ), დანიშნულების მისამართს (ყველაფერი tunnel-ით, ჩემი სახლის ქსელის გარდა), ან, proxy კლიენტებში, როგორიცაა Xray-ის ოჯახი, დომენის სახელს (ადგილობრივი ბანკის საიტები პირდაპირ, დანარჩენი ყველაფერი tunnel-ით). ყველაზე გავრცელებული გამოყენება, და ის, რაც თითქმის ყველას სჭირდება, უმარტივესია: ლოკალური ქსელის მისამართები tunnel-ს გარეთ დატოვე, რომ პრინტერმა, NAS-მა და ტელევიზორმა ჩართული VPN-ის დროსაც იმუშაონ. ამის მიღმა ყოველი წესი, რომელსაც დაამატებ, შეგნებული ხვრელია, და ტრაფიკი, რომელსაც პირდაპირ აგზავნი, ზუსტად ისევე ხილულია, როგორც VPN-ის საერთოდ არარსებობის შემთხვევაში.

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

სრული tunnel, split tunnel და შებრუნებული split#

სრული tunnel ყველაფერს VPN-ით აგზავნის. მოწყობილობაზე ეს არის მარშრუტი მთელი მისამართების სივრცისთვის - 0.0.0.0/0 IPv4-ისთვის და ::/0 IPv6-ისთვის - რომელიც VPN ინტერფეისზე მიუთითებს, პლუს გამონაკლისი თავად VPN სერვერის მისამართისთვის, რომ tunnel-ის პაკეტებმა მას მიაღწიონ.

Split tunnel ამ ყოვლისმომცველ მარშრუტს უფრო ვიწრო ნაკრებით ანაცვლებს. ამის ჩამოყალიბების ორი გზა არსებობს:

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

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

მარშრუტებზე დაფუძნებული გაყოფა#

უძველესი ფორმა მარშრუტიზაციის ცხრილზე მუშაობს. ყოველი პაკეტის დანიშნულების მისამართი მარშრუტებს ედარება, და ყველაზე კონკრეტული მარშრუტი იმარჯვებს. VPN, რომელიც 10.20.0.0/16-ს tunnel-ით ამატებს და ნაგულისხმევ მარშრუტს ხელს არ ახლებს, VPN-ით მხოლოდ კომპანიის ამ ქსელს აგზავნის; ის, რომელიც 0.0.0.0/0-ს ამატებს, ყველაფერს აგზავნის.

WireGuard-ში ეს არის AllowedIPs. კლიენტზე ის ორ რამეს ერთდროულად ნიშნავს: რომელი დანიშნულების ადგილები მარშრუტიზდება tunnel-ში, და რომელი წყაროს მისამართები მიიღება peer-ისგან.

[Peer]AllowedIPs = 0.0.0.0/0, ::/0

[Peer]AllowedIPs = 10.20.0.0/16

WireGuard-ში "ყველაფერი, გარდა" სინტაქსი არ არსებობს; ლოკალური ქსელის სრული tunnel-იდან გამორიცხვა ნიშნავს კერძო დიაპაზონების დამატების ჩამოთვლას, რასაც ონლაინ კალკულატორები პრეფიქსების გრძელ სიად აგენერირებენ. ოფიციალური Windows კლიენტის ოფცია "Block untunneled traffic (kill-switch)" მხოლოდ მაშინ მოქმედებს, როცა დაშვებული სია სრული ყოვლისმომცველია, და ამის ცოდნა ღირს, სანამ მის შემცირებას დაიწყებ.

OpenVPN იგივეს სერვერის მიერ გადმოცემული მარშრუტებით აკეთებს, რომლებზეც კლიენტს შეუძლია უარის თქმა და მათი ჩანაცვლება:

route-nopullroute 10.20.0.0 255.255.0.0route 192.168.1.0 255.255.255.0 net_gateway

route-nopull უგულებელყოფს სერვერის მიერ გადმოცემულ მარშრუტებს, შემდეგი ხაზი ერთ ქსელს tunnel-ით აგზავნის, ხოლო net_gateway ქსელს ამის ნაცვლად შენი ჩვეულებრივი gateway-ით აგზავნის.

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

აპლიკაციების მიხედვით გაყოფა#

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

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

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

დომენებსა და წესებზე დაფუძნებული გაყოფა Xray კლიენტებში#

proxy კლიენტები, როგორიცაა Xray-ისა და sing-box-ის ოჯახი, მისამართებზე მეტს ხედავენ: ისინი ხედავენ თითოეული კავშირის ჰოსტის სახელს, ან თავად მოთხოვნიდან, ან TLS handshake-ის "sniffing"-ით. ეს საშუალებას იძლევა, წესები დომენის მიხედვით დაწერო, ასევე დომენებისა და IP დიაპაზონების შერჩეული სიების მიხედვით, რომლებიც ქვეყნების ან კატეგორიების მიხედვითაა დაჯგუფებული.

შიგნით Xray-ის მარშრუტიზაციის სექცია ასე გამოიყურება:

{  "routing": {    "domainStrategy": "IPIfNonMatch",    "rules": [      { "type": "field", "ip": ["geoip:private"], "outboundTag": "direct" },      { "type": "field", "domain": ["domain:mybank.example"], "outboundTag": "direct" },      { "type": "field", "network": "tcp,udp", "outboundTag": "proxy" }    ]  }}

წესები თანმიმდევრობით იკითხება და პირველი დამთხვევა იმარჯვებს. geoip:private კერძო და ლოკალური დიაპაზონების ჩაშენებული სიაა. domain: ემთხვევა დომენს და მის ყველა ქვედომენს. domainStrategy აკონტროლებს, გაიხსნება თუ არა დომენი, რომელიც არცერთ დომენის წესს არ დაემთხვა, რომ IP წესები სცადოს: AsIs არასდროს ხსნის, IPIfNonMatch ხსნის მხოლოდ მაშინ, როცა არცერთი დომენის წესი არ დაემთხვა, IPOnDemand ხსნის, როგორც კი IP წესამდე მიდის.

ამ JSON-ს იშვიათად წერ ხელით. v2rayNG-ს აქვს მარშრუტიზაციის პარამეტრები, სადაც დომენებსა და IP-ებს direct, proxy ან block სიებში ამატებ, Hiddify გთავაზობს წესებს, რომლებიც არჩეული ქვეყნის საიტებს პირდაპირ აგზავნიან, ხოლო Shadowrocket-ს აქვს წესების რეჟიმი ისეთი ხაზებით, როგორიცაა DOMAIN-SUFFIX,mybank.example,DIRECT, და ყოვლისმომცველი FINAL,PROXY. იდეები ყველგან ერთნაირია: დამთხვევების სია, მოქმედება თითოეულისთვის და ნაგულისხმევი ბოლოს.

ლოკალური მისამართები, რომელთა გამორიცხვაც ღირს#

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

მათი გამორიცხვა სწორედ ისაა, რაც Chromecast-ს, AirPlay-ს, ქსელურ პრინტერებს, NAS-სა და როუტერის ადმინისტრირების გვერდს ჩართული VPN-ით მუშაობის საშუალებას აძლევს. კლიენტების უმეტესობას ამისთვის ერთი ოფცია აქვს, და Xray-ის geoip:private სია ამას ფარავს. CGNAT დიაპაზონი გადაწყვეტილების საკითხია: ზოგი მობილური და პროვაიდერის ქსელი მას შიდა სერვისებისთვის იყენებს, ზოგი overlay ქსელი კი, როგორიცაა Tailscale, საკუთარი მისამართებისთვის.

როდის ღირს გაყოფა#

• ადგილობრივი საიტები, რომლებიც უცხოურ მისამართებს უარყოფენ. ბანკები, სახელმწიფო პორტალები და ზოგი სტრიმინგ სერვისი ბლოკავს ან დამატებით ამოწმებს შესვლას საზღვარგარეთის მონაცემთა ცენტრების მისამართებიდან. ამ დომენების პირდაპირ გაგზავნა მათ მუშა მდგომარეობაში ინარჩუნებს.
• დიდი ლოკალური გადაცემები. backup-ები NAS-ზე, თამაშების ჩამოტვირთვა ახლომდებარე CDN-იდან, ვიდეოზარები იმავე ქალაქის ადამიანებთან. მათი სხვა ქვეყნის სერვერზე შემოვლით გატარება დროსა და რესურსს ხარჯავს უსარგებლოდ.
• თამაშები. ახლოს მდგარ თამაშის სერვერს, როგორც წესი, ყველაზე სწრაფად პირდაპირ მიწვდები; იხილე ამცირებს თუ არა VPN ping-ს თამაშებში, რომ გაიგო, როდის ეხმარება tunnel და როდის აზიანებს.
• სამუშაო ხელსაწყოები. კორპორატიული VPN, რომელსაც პირად VPN-თან თანაარსებობა სჭირდება, აპლიკაციების ნაცვლად მარშრუტების გამოყენების კლასიკური შემთხვევაა.

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

შეცდომები, რომლებიც გაყოფას გაჟონვად აქცევს#

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

დომენის წესები DNS-ის წესების გარეშე. კავშირი tunnel-ით მიდის; მოთხოვნა კი ჯერ სასტუმროს resolver-თან წავიდა.

WebRTC და UDP მხოლოდ proxy რეჟიმებში. სისტემური proxy-ით მარშრუტიზებულ ბრაუზერს მაინც შეუძლია WebRTC ტრაფიკი პირდაპირ გააგზავნოს, რადგან ის UDP-ა და proxy-ს უგულებელყოფს.

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

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

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

როგორ შეამოწმო, რომელი გზით მიდის ტრაფიკი#

Split tunnel იმდენად კარგია, რამდენადაც კარგად იცი, სად ხვდება სინამდვილეში ტრაფიკის თითოეული სახე. სამი შემოწმება ამას ფარავს.

აპლიკაციიდან თითოეულ მხარეს. გახსენი "what is my IP" გვერდი ბრაუზერში, რომელიც tunnel-ით უნდა მიდიოდეს, და ისეთში, რომელიც არ უნდა მიდიოდეს (ან გამორიცხული აპლიკაციიდან, რომელსაც ჩაშენებული ბრაუზერი აქვს). ერთმა VPN სერვერის მისამართი უნდა აჩვენოს, მეორემ - შენი საკუთარი.

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

Windows:  Find-NetRoute -RemoteIPAddress 10.20.1.5Linux:    ip route get 10.20.1.5macOS:    route -n get 10.20.1.5

გამოტანა ასახელებს ინტერფეისსა და gateway-ს. დანიშნულებამ, რომლის tunnel-ით გაგზავნაც გინდოდა, VPN ინტერფეისი უნდა აჩვენოს; ლოკალურმა პრინტერმა - შენი ჩვეულებრივი ადაპტერი.

კლიენტის log-იდან. Xray-ის ოჯახის კლიენტებს შეუძლიათ თითოეული კავშირის log-ში ჩაწერა იმ წესით, რომელსაც დაემთხვა, და outbound-ით, რომელიც გამოიყენა - proxy, direct ან block. log-ის დონის რამდენიმე წუთით აწევა, სანამ შესაბამის საიტებს ხსნი, ყველაზე სწრაფი გზაა იპოვო წესი, რომელიც ისე არ ემთხვევა, როგორც გეგონა, განსაკუთრებით დომენის წესებში, სადაც კლიენტმა შეიძლება სახელის ნაცვლად IP მისამართი დაინახოს.

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

Split tunnelling კერძო სერვერთან#

RE:NODE-ზე კერძო VPN ხაზი Xray-ს იყენებს VLESS-ითა და Reality-ით, ხოლო ზემოთ აღწერილი მარშრუტიზაციის წესები შენს კლიენტში ცხოვრობს და არა სერვერზე. სერვერი უბრალოდ ატარებს იმას, რასაც კლიენტი უგზავნის: საკუთარი მისამართი და გასაღები, მასზე სხვა არავინაა, ტრაფიკის ლიმიტი არ არის. Android-ზე v2rayNG და Hiddify გაძლევს აპლიკაციებისა და მარშრუტიზაციის პარამეტრებს; iPhone-ზე Shadowrocket-ის წესების რეჟიმი ყველაზე მოქნილია; Windows-ზე Renode VPN აპლიკაცია სერვერის მიერ დაბეჭდილი ბმულით უკავშირდება სრული tunnel-ისთვის, ხოლო ზოგადი კლიენტი, როგორიცაა Hiddify, იმავე ბმულით შეიძლება გამოიყენო, თუ დეტალური წესები გინდა. რადგან სერვერი გერმანიაშია, ახლომდებარე ლოკალური ტრაფიკის პირდაპირ გაგზავნა სიჩქარეზე ხშირად შესამჩნევ გავლენას ახდენს. ზოგ ქვეყანაში VPN-ის გამოყენება შეზღუდულია, ამიტომ შეამოწმე კანონი იქ, სადაც ხარ, ხოლო კლიენტის დაყენების გზამკვლევში თითოეულ აპლიკაციაში ბმულის შემოტანის ნაბიჯებია.

FAQ#

Split tunnelling სრულ tunnel-ზე ნაკლებად უსაფრთხოა?

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

რატომ წყვეტს ჩემი პრინტერი მუშაობას, როცა VPN ჩართულია?

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

შემიძლია VPN-ით მხოლოდ ერთი აპლიკაცია გავუშვა?

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

ანელებს მარშრუტიზაციის წესები კავშირს?

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

თამაშები VPN-ით უნდა წავიდეს თუ პირდაპირ?

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