Windows-ის აპლიკაციაზე დაფუძნებული VPN ტრიგერი და გაყოფილი გვირაბი: რა გამოჰყოფს
აპლიკაციით გაშვებული Windows VPN პროფილი მხოლოდ გვირაბს ხსნის. მარშრუტიზებული გაყოფილი გვირაბი წყვეტს, რა შედის მასში, და თითოეული ერთი აპლიკაციისთვის სხვადასხვანაირად ცდება.
ორი Windows კონფიგურაცია პარამეტრებში ერთნაირად გამოიყურება და სრულიად განსხვავებულად იქცევა. ერთი არის დაკოპირებული VPN პროფილი აპლიკაციის ტრიგერით, ამიტომ ერთი შესრულებადი ფაილის გაშვება გვირაბს ამაღლებს. მეორე არის გაყოფილი გვირაბის პროფილი, რომლის მარშრუტების სია შემთხვევით ფარავს იმას, რასთანაც ეს აპლიკაცია საუბრობს. პირველი პასუხობს, როდის არსებობს გვირაბი. მეორე პასუხობს, რომელი პაკეტები შედის მასში, და მხოლოდ მეორე ტოვებს დანარჩენ მანქანას ფიზიკურ ბმულზე, სანამ აპლიკაცია დაკავშირებული რჩება.
ტრიგერი სასიცოცხლო ციკლის წესია, არა მარშრუტიზაციის წესი
Add-VpnConnectionTriggerApplication აკავშირებს შესრულებადი ფაილის გზას პროფილის სახელთან. როდესაც ეს პროცესი იწყება, დისტანციური წვდომის კავშირების მენეჯერი რეკავს პროფილს, და როდესაც ტრიგერის პირობა მთავრდება, კავშირი შეიძლება ჩამოვარდეს. ამ გაცვლაში არაფერი ამოწმებს სოკეტებს. ბრძანებას სჭირდება ამაღლებული shell, ბინარულ ფაილამდე სრული გზა და -Force როდესაც ცვლით არსებულ ჩანაწერს. დაადასტურეთ, რომ ასოციაცია გადარჩა, ამით: Get-VpnConnectionTrigger მითითებულ მოთხოვნაზე დაყრდნობის ნაცვლად; Microsoft-ის Add-VpnConnectionTriggerApplication ცნობარი ჩამოთვლის პარამეტრებს და მაგალითებს.
ორი ზღვარი ხსნის „ტრიგერი არაფერს აკეთებს“ შეტყობინებების უმეტესობას. ტრიგერები აგებულია ყველა მომხმარებლის პროფილების გარშემო, ამიტომ პროფილის ფარგლები პირველი მოსაგვარებელი საკითხია, და აპლიკაციის გზა უნდა შეესაბამებოდეს რეალურად გაშვებულ ბინარულ ფაილს, და არა მალსახას ან გამშვებს, რომელიც მეორე პროცესს ქმნის. მეორე ზღვარი განზრახ არის: ქსელში, რომელსაც Windows სანდოდ ასახელებს, ტრიგერი უმოქმედო რჩება, რადგან პროფილი ოფისის გარეთ მუშაობისთვისაა განკუთვნილი.
Add-VpnConnectionTriggerApplication -Name "APP_VPN" -ApplicationID "C:\Program Files\Vendor\app.exe" -Force
Get-VpnConnectionTrigger -Name "APP_VPN" | Format-List *
Get-VpnConnection -Name "APP_VPN" | Format-List Name,ConnectionStatus,SplitTunneling,AllUserConnectionგაყოფილი გვირაბი წყვეტს, რა გადაკვეთს გვირაბს
გაყოფილი გვირაბის გამორთვისას Windows VPN ინტერფეისზე აყენებს კლასზე დაფუძნებულ ნაგულისხმევ მარშრუტს დაბალი მეტრიკით. ყველა სოკეტი მიჰყვება მას, ბრაუზერისა და განახლების სერვისის ჩათვლით, ამიტომ ამ კონფიგურაციაში ტრიგერი გადაადგილებს მთელ მანქანას, სანამ პროფილი დაკავშირებულია. ტრიგერი კვლავ მხოლოდ სასიცოცხლო ციკლის წესია; ზემოქმედების რადიუსი მარშრუტიდან მოვიდა.
გაყოფილი გვირაბის ჩართვისას პროფილი მხოლოდ იმ პრეფიქსებს ატარებს, რომლებსაც კარიბჭე უბიძგებს ან თქვენ ამატებთ VPN ინტერფეისს. დანარჩენი ყველაფერი კვლავ ფიზიკურ ნაგულისხმევ მარშრუტს იყენებს. ეს არის ის განლაგება, რომელსაც ადამიანები ჩვეულებრივ გულისხმობენ „ერთი აპლიკაცია ცალკე გასასვლელით“, და ეს თავიდან ბოლომდე მარშრუტიზაციის გადაწყვეტილებაა.
Set-VpnConnection -Name "APP_VPN" -SplitTunneling $true
Get-VpnConnection -Name "APP_VPN" | Select-Object SplitTunneling
Get-NetRoute -InterfaceAlias "APP_VPN" | Sort-Object DestinationPrefixსად წყვეტს მარშრუტიზებული გაყოფა თქვენი აპლიკაციის გამოყოფას
გავრცელებული წარუმატებლობა არის დანიშნულება, რომელიც არასოდეს ჩნდება გვირაბის მარშრუტების სიაში. აპლიკაცია, რომელიც ერთ მისამართზე შედის და შემდეგ CDN-იდან სტრიმავს, ან ხსნის ათეულ მბრუნავ ბოლო წერტილს, ზოგიერთ კავშირს VPN ინტერფეისზე დადებს, დანარჩენს კი Wi-Fi-ზე. IPv6 ცალკე ცხრილია, ამიტომ პროფილი, რომელიც მხოლოდ IPv4 პრეფიქსებს უბიძგებს, შეიძლება სწორად გამოიყურებოდეს, სანამ აპლიკაციის IPv6 ტრაფიკი ლოკალური რჩება.
ორი უფრო მცირე ეფექტი ისევე მნიშვნელოვანია. ყველაზე გრძელი პრეფიქსის დამთხვევა იმარჯვებს, ამიტომ უფრო კონკრეტულ on-link მარშრუტს, მართვის ჰოსტისთვის უბიძგებულ /32-ს ან მეორე ადაპტერის ქვექსელს შეუძლია გვირაბი დაამარცხოს ზუსტად იმ მისამართისთვის, რომელიც გაწუხებთ. სახელების გარჩევა მარშრუტიზაციამდეც ხდება: თუ პროფილის DNS სერვერები ან NRPT წესი სახელს არ ფარავს, აპლიკაციამ შეიძლება ფიზიკური ადაპტერით გადაჭრას და შემდეგ გამოიძახოს მისამართი, რომელიც არასოდეს ყოფილა გვირაბიზებულ პრეფიქსებში.
სამი ფორმა და რას იძენს თითოეული
ცხრილი ის ნაწილია, რომელსაც კედელზე დავაწებებდი, რადგან გადაწყვეტილება ზემოქმედების რადიუსს ეხება და არა ფუნქციებს. თუ აპლიკაციის დანიშნულებები სტაბილური პრეფიქსებია, რომელთა ჩამოთვლაც შეგიძლიათ, მარშრუტიზებული გაყოფა იძლევა იზოლაციას ყველაზე მცირე კვალით. თუ არა, ნაგულისხმევი მარშრუტის პროფილი VM-ის ან მეორე მოწყობილობის უკან ინარჩუნებს განცალკევებას პატიოსნად ერთზე მეტი პროცესის გადაადგილების ფასად.
| Shape | What starts the tunnel | What enters it | Pick it when |
|---|---|---|---|
| Trigger plus routed split | Process start | Only pushed or added prefixes | The app's endpoints are stable prefixes and the host should stay direct |
| Trigger plus default route | Process start | Everything, machine-wide | You need one exit for all traffic and accept the wider scope |
| Separate VM or device | Guest boot or login | Everything inside that guest | The app's destinations rotate, or the host must keep its own public address |
რასაც არცერთი მათგანი არ გვთავაზობს, არის სოკეტის დონეზე მიბმა ჰოსტზე. კლასიკურ Windows VPN კლიენტს არ აქვს წესი, რომ ეს პროცესი უნდა იყენებდეს იმ ადაპტერს; ტრიგერები და მარშრუტის ფილტრები სხვადასხვა შრეში ცხოვრობს, და ინტერფეისის ამომრჩევი შრე მარშრუტების ცხრილია. თუ გზამკვლევი ჰპირდება აპლიკაციაზე დაფუძნებულ აღსრულებას მხოლოდ დაკოპირებული პროფილიდან, ჰკითხეთ, რომელი მარშრუტი ან რომელი ფილტრი ასრულებს სამუშაოს.
გადაამოწმეთ წყვილი ერთი გავლით
გამოსცადეთ სასიცოცხლო ციკლი და მარშრუტიზაცია ცალკე, ამ თანმიმდევრობით. დახურეთ აპლიკაცია, დაადასტურეთ, რომ პროფილი იუწყება Disconnected, შემდეგ გაუშვით აპლიკაცია და შეამოწმეთ, შეიცვალა თუ არა მდგომარეობა. მხოლოდ მას შემდეგ, რაც გვირაბი ამაღლდება, უნდა ჰკითხოთ, სად მიდის კონკრეტული დანიშნულება, და უნდა გამოიყენოთ მისამართი, რომელსაც აპლიკაცია რეალურად იძახებს, და არა ვარაუდი.
$app = Get-Process app | Select-Object -First 1
Get-VpnConnection -Name "APP_VPN" | Select-Object ConnectionStatus
Get-NetTCPConnection -OwningProcess $app.Id -State Established | Select-Object RemoteAddress,RemotePort
Find-NetRoute -RemoteIPAddress 203.0.113.10Find-NetRoute ასახელებს ინტერფეისს და შემდეგ ნახტომს, რომელიც გადაიტანდა ამ დანიშნულებას. ფიზიკური ფსევდონიმი იქ ნიშნავს, რომ გვირაბი ამაღლებულია და ამ ნაკადისთვის უმნიშვნელოა: შეამოწმეთ უბიძგებული პრეფიქსები, შემდეგ უფრო კონკრეტული მარშრუტები, შემდეგ IPv6. თუ მდგომარეობა საერთოდ არ იცვლება, ტრიგერი არ ამოქმედდა, და შესრულებადი ფაილის გზა, პროფილის ფარგლები და VPN კლიენტის ოპერაციული ჟურნალი სამი ადგილია, საითაც უნდა ვიხედოთ.
გაასუფთავეთ სუფთად, რომ შემდეგი ტესტი პატიოსანი იყოს
ამოიღეთ იმის საპირისპირო თანმიმდევრობით, როგორც ააშენეთ: ჯერ აპლიკაციის ტრიგერი, შემდეგ პროფილი. პროფილის წაშლა ტრიგერის დატოვებისას ტოვებს ჩამოკიდებულ ასოციაციას, რომელიც შემდეგ ცდას დამაბნეველს ხდის, და Remove-VpnConnection -Force ყოველთვის არ ასუფთავებს სატელეფონო წიგნის ჩანაწერს, რომელიც ბრძანებების გარეთ შეიქმნა.
მომხმარებლის მიხედვით ჩანაწერები არის მომხმარებლის rasphone.pbk ფაილში Roaming პროფილის ქვეშ; ყველა მომხმარებლის ჩანაწერები ProgramData-ის ქვეშაა. შეამოწმეთ საცავი, რომელიც პროფილის ფარგლებს შეესაბამება, ხელახლა დააკავშირეთ შენახული პროფილი და დაადასტურეთ, რომ მისი მარშრუტები და DNS კვლავ მუშაობს, რომ შემდგომმა ტესტმა თქვენი ცვლილება გაზომოს და არა დარჩენილი მდგომარეობა.
- გვირაბი იწყება პროცესის გაშვებისას, და არა შესვლისას.
- VPN ინტერფეისზე მხოლოდ განზრახული პრეფიქსები ჩნდება.
- აპლიკაციის ნამდვილი დისტანციური მისამართი VPN ფსევდონიმზე იხსნება.
- პროფილის ამოღების შემდეგ ჩამოკიდებული ტრიგერი არ რჩება.