VPN ბლოკავს ლოკალურ LAN-ს Windows-ზე: მარშრუტი თუ კლიენტის პოლიტიკა?
Windows-ზე ლოკალურ LAN-ზე წვდომა ორი განსხვავებული მიზეზით ირღვევა: აკლია მარშრუტი, ან gateway-ის პოლიტიკა, რომელიც subnet-ს ყრის. სამი შემოწმება ამბობს, რომელი.
თქვენსავე მაგიდაზე მდგარი პრინტერი, NAS ან განვითარების მანქანა წყვეტს პასუხს იმ წამს, როცა სამუშაო VPN უკავშირდება. ზოგჯერ ერთი მარშრუტის ბრძანება ასწორებს ამას წამებში; ზოგჯერ იგივე მარშრუტი სწორია და პაკეტები მაინც ქრება, რაც ნიშნავს, რომ ხედავთ სხვა პრობლემას მსგავსი სიმპტომით. გადაწყვეტილება სამ კითხვამდე მიდის, და მათი არასწორი თანმიმდევრობით დასმა არის მიზეზი, რატომ ატარებენ ადამიანები მთელ საღამოს მარშრუტების წაშლასა და ხელახლა დამატებაში.
სამი კითხვა ნებისმიერ ბრძანებამდე
პირველი: არსებობს ჩანაწერი ლოკალური პრეფიქსისთვის და მიუთითებს ის ფიზიკურ ადაპტერზე? მეორე: კავშირის დროს კლიენტი gateway-ისგან იღებს ლოკალური ქსელის ნებართვას თუ უარყოფას? მესამე: გჭირდებათ მხოლოდ გამავალი წვდომა LAN-ზე, თუ ინტერნეტში რაღაცამაც უნდა მიაღწიოს თქვენს მანქანაზე მომუშავე სერვისს?
პირველი კითხვა გამოყოფს მარშრუტიზაციის ხარვეზს ფილტრაციის ხარვეზისგან. მეორე ამბობს, საერთოდ ნებადართულია თუ არა მარშრუტის შესწორების მუშაობა. მესამე ცვლის შეკეთებას: მარშრუტი ასწორებს გამავალ ტრაფიკს, ხოლო მიუწვდომელი შემავალი სერვისი ჩვეულებრივ მსმენელის მიბმისა და დაბრუნების გზის პრობლემაა, რომელსაც მარშრუტი აუარესებს.
| What you see | What it points at |
|---|---|
| No local prefix in the table | Missing route |
| Correct prefix, no reply | Client filter or gateway policy |
| Works by IP, fails by name | Resolver changed by the tunnel |
| Inbound service dies, outbound fine | Return path or listener binding |
კითხვა პირველი: მარშრუტი, ფილტრი თუ სახელი
წაიკითხეთ ცხრილი, სანამ რამეს დაამატებთ. ინტერფეისის ინდექსს მნიშვნელობა აქვს, რადგან ქვემოთ მოცემული ყოველი მარშრუტის ბრძანება მასზეა მიმაგრებული:
route print -4
Get-NetRoute -DestinationPrefix 192.168.1.0/24 | Format-Table InterfaceIndex,NextHop,RouteMetricპირდაპირ დაკავშირებული subnet-ი ჩვეულებრივ ინარჩუნებს on-link მარშრუტს მაშინაც, როცა გვირაბი აქტიურია, ამიტომ ჩანაწერი შეიძლება არსებობდეს და ტრაფიკი მაინც ჩავარდეს. ეს კომბინაცია მარშრუტიზაციის შემდეგ მომუშავე ფილტრის ხელწერაა, და ეს არის ის შემთხვევა, როცა მეორე, უფრო კონკრეტული მარშრუტი საერთოდ არაფერს ცვლის.
სცადეთ ცალკე მისამართით და სახელით. თუ ping 192.168.1.50 პასუხობს, ხოლო net view 192.168.1.50 არა, მარშრუტიზაციის ცხრილი არასდროს ყოფილა პრობლემა: გვირაბმა შეცვალა resolver-ი და ლოკალური სახელი აღარ წყდება. ამისთვის მარშრუტის დამატება ფუჭი შრომაა.
კითხვა მეორე: უშვებს gateway ლოკალურ LAN-ზე წვდომას?
კომერციული კლიენტი მეტს აყენებს, ვიდრე მარშრუტებს. ის კავშირის დროს იღებს პოლიტიკას, და ეს პოლიტიკა შეიძლება შეიცავდეს ლოკალური ქსელის ცხად ნებართვას. Cisco IPsec-ის განლაგებებში ჯგუფური პოლიტიკა ატარებს split-tunneling-ის პარამეტრს და ცალკე დროშას ლოკალურ LAN-ზე წვდომისთვის; კლიენტში არსებული მოსანიშნი უჯრა მოთხოვნაა, რომელიც gateway-მა შეიძლება უარყოს. AnyConnect-ში პროფილი მართავს split-ის ჩართვისა და გამორიცხვის სიებს და იმავე ნებართვას. Windows RRAS-ზე ეკვივალენტებია პროფილის ნაგულისხმევი gateway-ის პარამეტრი და სერვერის მიერ მინიჭებული სტატიკური მარშრუტები.
როცა დროშა გამორთულია, დოკუმენტირებული ქცევაა, რომ კლიენტი ბლოკავს ტრაფიკს პირდაპირ დაკავშირებულ subnet-ზე, მიუხედავად იმისა, რომ არსებობს სწორი, უფრო კონკრეტული მარშრუტი. ამიტომაც შეიძლება კლიენტის საკუთრებაში არსებული მარშრუტები გაქრეს დამატებიდან წამებში: კლიენტი ხელახლა აშენებს იმ მდგომარეობას, რომლის აშენებაც უბრძანეს, და თქვენ არ ებრძვის.
კლიენტის ჟურნალი კავშირის დროს იწერს გადაწყვეტილებას, და მისი წაკითხვა უფრო სწრაფია, ვიდრე ნებისმიერი ექსპერიმენტი მანქანაზე. თუ ჟურნალი ამბობს, რომ ლოკალური წვდომა დაბლოკილია, გაჩერდით: ბრძანების ხაზის არც ერთი შესწორება ამას არ გადაურჩება, და დარჩენილი გზებია პოლიტიკის შეცვლა, რესურსზე გვირაბით მიღწევა, ან კლიენტის ვირტუალურ მანქანაში ჩასმა და ჰოსტის ლოკალურ ქსელში დატოვება.
კითხვა მესამე: რომელი მიმართულება გჭირდებათ?
გამავალი ტრაფიკი ახლომდებარე მოწყობილობამდე მარშრუტიზაციის კითხვაა. მიმართეთ LAN-ის პრეფიქსი ლოკალურ gateway-ს იმდენად დაბალი მეტრიკით, რომ დაამარცხოს გვირაბის ნაგულისხმევი მარშრუტი:
route add 192.168.1.0 mask 255.255.255.0 192.168.1.1 metric 1 if 12
route add 192.168.1.50 mask 255.255.255.255 192.168.1.1 -pმეორე ფორმა ამაგრებს ერთ მოწყობილობას, და ეს არის ის, რაც გინდათ, როცა ერთი მისამართია მთელი მოთხოვნა. netsh-ის ეკვივალენტი იმავე გადაწყვეტილებას ინტერფეისის სახელით იწერს, არა ინდექსით:
netsh interface ipv4 add route prefix=192.168.1.0/24 interface=12 nexthop=192.168.1.1 store=persistentმარშრუტის ბრძანებები ვარდება პარამეტრი არასწორია-თი, როცა მისამართი და ნიღაბი არ ემთხვევა, მაგალითად ჰოსტის მისამართი /24 ნიღაბით. subnet-ის მარშრუტისთვის გამოიყენეთ ქსელის მისამართი, ხოლო ერთი ჰოსტისთვის ჰოსტის ნიღაბი.
შემავალი განსხვავებულია. იმავე მანქანაზე არსებული VNC ან SSH სერვერი ხდება მიუწვდომელი, როცა შემავალი კავშირის პასუხები VPN gateway-ით გადის და არასდროს ბრუნდება. სანამ მარშრუტებს შეეხებით, შეამოწმეთ რას უსმენს სერვისი:
netstat -ano | findstr :5900ერთ კონკრეტულ მისამართზე მიბმული მსმენელი არ უპასუხებს მეორე ინტერფეისზე. მისი ყველა ინტერფეისზე მიბმა განზრახ გადაწყვეტილებაა, მიღებული იმ ქსელზე შეზღუდული firewall-ის წესთან ერთად, რომელსაც ენდობით. მხოლოდ ამის შემდეგ აღადგენს მარშრუტის შეკეთება დაბრუნების გზას.
გამოიყენეთ ყველაზე პატარა შესაბამისი ცვლილება
სხვა გავრცელებული ნაბიჯია IPv4-ის დამატებით თვისებებში „გამოიყენე ნაგულისხმევი gateway დისტანციურ ქსელში“-ის მონიშვნის მოხსნა. ეს ინტერნეტ ტრაფიკს ლოკალურად ტოვებს, მაგრამ ორ რამეს ერთდროულად აკეთებს: VPN წყვეტს ნაგულისხმევი გზის ყოფნას, და კლიენტი წყვეტს დისტანციური ქსელის მარშრუტების მიღებას, multicast-ის ჩათვლით. მოხსენით მონიშვნა და დისტანციური LAN გაქრება, თუ სერვერი არ უბიძგებს თითოეულ კლიენტს საჭირო კონკრეტულ დისტანციურ პრეფიქსებს.
ეს ასიმეტრია განსაზღვრავს სამუშაოს რიგს. თუ დისტანციური მხარე სრულად მისაწვდომი უნდა დარჩეს, სერვერიდან გაუშვით დისტანციური subnet-ები და ლოკალურ ნაგულისხმევს ხელი არ ახლოთ. თუ სერვერს ვერ შეცვლით, დაამატეთ მუდმივი მარშრუტი დისტანციურ პრეფიქსზე გვირაბის მინიჭებული მისამართით, და route print-ით შეამოწმეთ, რომ პრეფიქსი VPN ინტერფეისს მიუთითებს, ხოლო ნაგულისხმევი კვლავ ფიზიკურ gateway-ს.
შემდეგ დაადასტურეთ, რომ შეკეთება გადაურჩება ხელახალ კავშირს, რადგან არამუდმივი მარშრუტები ადაპტერთან ერთად კვდებიან, და ყოველი კავშირის შემდეგ გაშვებული სკრიპტი მათთვის პატიოსანი ადგილია. იმავე სესიაში სცადეთ ერთი ლოკალური მოწყობილობა და ერთი დისტანციური რესურსი, გათიშეთ, ხელახლა დაუკავშირდით და ისევ სცადეთ. თუ ლოკალური მოწყობილობა კვლავ ვარდება, სანამ მარშრუტი სწორად გამოიყურება, დაბრუნდით მეორე კითხვაზე: კლიენტი ფილტრავს, და პასუხი პოლიტიკის შეცვლაა და არა მეორე კონკურენტი მარშრუტი.