ლოკალური ქსელი მიუწვდომელია VPN-ის ჩართვისას? ოთხი შემოწმება

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

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

გახსენით კლიენტის მარშრუტების ცხრილი, სანამ VPN ჩართულია. Linux-ზე გამოიყენეთ ip route, Windows-ზე — route print ან Get-NetRoute, ხოლო macOS-ზე — netstat -rn. თქვენ ეძებთ გვირაბის გავლით მიმავალ ნაგულისხმევ მარშრუტს და იმას, რაც ფიზიკურ ნაგულისხმევს დაემართა.

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

თუ გვირაბი უნდა დარჩეს ნაგულისხმევად, მაშინ ჩაამაგრეთ ლოკალური ქვექსელი. Linux-ზე მარშრუტი ასახელებს ფიზიკურ ინტერფეისს და კარიბჭეს; Windows-ზე დაამატეთ -p, რომ მუდმივი გახდეს, და ინტერფეისის ნომერი წაიკითხეთ route print-იდან, ნუ გამოიცნობთ:

sudo ip route add 192.168.1.0/24 via 192.168.1.1 dev wlan0
route add -p 192.168.1.0 MASK 255.255.255.0 192.168.1.1 METRIC 1 IF 12

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

მეორე: დაადასტურეთ, რომ მისამართი თავიდანვე ლოკალური იყო

თუ დანიშნულება ჩართული ქვექსელის შიგნითაა, გვირაბის ნაგულისხმევი არასოდეს მოქმედებს და VPN მიზეზი არ არის. 192.168.1.40-ზე მდგარი პრინტერი 192.168.1.0/24 ქსელის კლიენტზე იყენებს ჩართულ მარშრუტს; თუ ეს მისამართი ვერ მუშაობს, ნახეთ მოწყობილობა, კომუტატორი ან კლიენტის firewall და არა VPN.

ხალხს ატყუებს შემთხვევა, როცა ლოკალურ სერვერს საჯარო მისამართი აქვს. LAN-ის შიგნიდან როუტერის WAN მისამართზე მისვლა და უკან დაბრუნება მოითხოვს hairpin NAT-ს, და ბევრი როუტერი უბრალოდ არ ახორციელებს მას port forwarding-ისთვის. გამოსცადეთ პირადი მისამართი საჯაროს გვერდით. თუ პირადი მუშაობს, საჯარო კი არა, VPN-მა მხოლოდ გამოააშკარავა NAT-ის შეზღუდვა, რომელიც უკვე არსებობდა.

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

მესამე: ნახეთ, ვინ პასუხობს ახლა სახელებს

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

Linux-ზე resolvectl query nas.local გიჩვენებთ, რომელი გადამწყვეტი უპასუხა. Windows-ზე nslookup nas.local ასახელებს სერვერს, ხოლო ipconfig /all გიჩვენებთ გადამწყვეტების რიგს. თუ ლოკალურ სუფიქსს ახლა კორპორატიული გადამწყვეტი ემსახურება, ან დააბრუნეთ ეს სუფიქსი ლოკალურ გადამწყვეტთან, ან მოწყობილობისთვის გამოიყენეთ IP მისამართი.

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

მეოთხე: შეამოწმეთ, VPN-ზეა თუ არა მეორე მანქანაც

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

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

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

გამოიყენეთ შეკეთება, რომელიც შეესაბამება ჩავარდნილ შემოწმებას

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

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

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