რატომ კლავს თქვენი Windows-ის VPN ლოკალურ პრინტერს და როგორ შეაჩეროთ ეს

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

ჯერ წაიკითხეთ მარშრუტების ცხრილი

სანამ რამეს შეცვლიდეთ, აიღეთ IPv4 ცხრილი route print -4-ით და შეინახეთ გამოსავალი. დაუკავშირდით, კვლავ აიღეთ და შეადარეთ 0.0.0.0 ხაზები: აქტიური ნაგულისხმევი მარშრუტი ასახელებს ინტერფეისს და თუ ეს ინტერფეისი გვირაბია, ლოკალური ბეჭდვა და დათვალიერება პირველად ოფისში იგზავნება.

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

წაშალეთ ნაგულისხმევი მარშრუტი, სამი გზით

ჩაშენებულ Windows პროფილში კონტროლი არის მოსანიშნი უჯრა. გახსენით კავშირის თვისებები, IPv4, შემდეგ დამატებითი და მოხსენით Use default gateway on remote network ნიშანი; უფრო ახალი პარამეტრების აპი იმავე დიალოგს ერთი ფენით ღრმად მალავს. აწეული ბრძანების სტრიქონიდან იგივე ცვლილება ერთი cmdlet-ია:

Set-VpnConnection -Name "Corp" -SplitTunneling $true

OpenVPN პროფილი სხვანაირად მუშაობს, ამიტომ მისი ქცევა აბნევს მათ, ვინც მოსანიშნ უჯრას მოელის. მისი redirect-gateway def1 დირექტივა საერთოდ არ ცვლის ნაგულისხმევ მარშრუტს; ის აყენებს ორ ნახევარ-დიაპაზონის მარშრუტს, 0.0.0.0/1 და 128.0.0.0/1, რომლებიც ერთად ამარცხებენ ნაგულისხმევს მისი წაშლის გარეშე. რადგან თავდაპირველი ნაგულისხმევი რჩება, net_gateway-ზე მიმართული პრეფიქსის დამატება მხოლოდ იმ პრეფიქსს აბრუნებს ლოკალურ როუტერთან. ეს დეტალი ხსნის, რატომ არის def1 პროფილის შესწორება პრეფიქსის მარშრუტი და არა მოსანიშნი უჯრა, რომელსაც ვერავინ იპოვის.

დააბრუნეთ მხოლოდ ის, რაც სამუშაოს ეკუთვნის

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

Add-VpnConnectionRoute -ConnectionName "Corp" -DestinationPrefix 172.20.0.0/16

ძველი მიდგომა ჯერ კიდევ მუშაობს და ჯერ კიდევ ყველა საკონტროლო სიაშია: route -p add 172.20.0.0 mask 255.255.0.0 172.20.0.1 if 14, გვირაბის საკუთარი ინტერფეისის ინდექსით და კარიბჭის მისამართით. ის გადაურჩება გადატვირთვებს, რაც არის მიზანი და ასევე საშიშროება, რადგან ინდექსი შემდეგ ჩართვაზე შეიძლება სხვა რამეს ეკუთვნოდეს.

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

როცა სერვერი თქვენ ნაცვლად წყვეტს

კლიენტი, რომელიც თქვენს მოსანიშნ უჯრას უგულებელყოფს, ჩვეულებრივ პოლიტიკას ემორჩილება. Cisco-ს პროფილებს აქვს Allow Local LAN Access პარამეტრი და headend-ს შეუძლია გამოგზავნოს tunnel-all პოლიტიკა, რომელიც აუქმებს იმას, რაც კლიენტს ერჩივნა; სავალდებულო გვირაბის განლაგებაში ლოკალური გადამრთველი არ არსებობს. წაიკითხეთ კლიენტის ჟურნალი გამოგზავნილი მარშრუტებისა და პოლიტიკის ხაზებისთვის, იმავე დიალოგის ხელახლა შემოწმების ნაცვლად.

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

გადაფარვები სხვა პრობლემაა

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

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